You might have heard this term before. “API” it will say somewhere. Maybe some company created a new API. Or they removed an old one. Whatever it may be, something happened and it’s probably big and important. Maybe. But what’s an API anyway?

An API is what sits between your computer and the thing it wants to get. But it’s not trying to prevent your computer from getting it, in fact it’s the opposite. An API is the part that helps your computer access the right information.

So how does the API help?

So the API is a part of the system that holds the information your computer needs. Within the system that holds the information there is no need for an API to get its own information. It has the information already and all it needs to do is go straight to it. But this system could change. Sometimes someone smart figures out that the information is being stored in a bad way and that they can fix it to make it better. So they change how the information is stored, while keeping the content the same, and update the system to work with this new way.

But your computer does not know this. Your computer doesn’t know how the other information is stored. All it needs to know is how to ask for it.

That’s where the API comes in. The API knows what your computer wants while at the same time knowing how the information is stored inside the system. This means that you can make a big change inside the system without changing anything for computers outside the system.

An Example

Now that you know why an API is good let’s use an example.

You go to the bank and you want your money. You tell the bankier that you want to withdraw. In this case the bankier is the API. You have a request, they have what you want, and the bankier knows how to talk to you and their system to get what you’re asking for. You don’t have to know how to open a bank vault, and they can store your money however they want, as long as you can get it out of there any time you want.

And, Uhh, That’s It Really

That’s all an API is. Really, it’s not much more complex than that. I mean there is more to learn about APIs but it’s all the same idea. But let’s go for a quick bonus round.

Bonus Round

— Application Programming Interface —

As with everything in this series I leave out a lot of details. I even straight up lied. Systems have tons of internal APIs. They don’t just exist between your computer and the system it wants information from. Almost always this first API is just the tip of the iceberg of a mountain of different APIs working together. Ones you can’t see.

This happens because the people creating the website you use themselves want to change how their tools work without changing how they interact with them. So they can make a change on a really small level without affecting the whole system. When they store information in a file on their computers even this is done using an API. They aren’t telling the harddrive (where files are stored, commonly mistakenly referred to as, and confused with, memory) how to put the file on it. They are telling their operating system (like Windows) to put their file on the harddrive. Likewise when they want that file again they tell their operating system to go get the file and wait for their operating system to come back to them with the file they want some time later.

That’s a lot of words. But don’t worry if this is technological, this is just the bonus round. If you understood this you’re probably already well versed in computers or spend a lot of time around someone who is.

The End

Thank you for reading. I hope “API” makes a bit more sense to you now.

What am I talking about?

When you browse around the internet and looking at pages there are currently 2 ways that the people who made the page can choose to deliver it to your eyes. Either they make it all on the server and send you the result, or they send you everything your browser needs to create the page itself.

Ok so what does that mean exactly. Server side? What is a page even?

Every time you type in an address your computer send a request to the computer that controls that address and starts sending you back what you will eventually see as the website you visit. Like this one you’re on right now, medium. Or every other website in the whole world!

And what it sends back is just a bunch of text that your browser understands how to display to you as a complete web page. Under the hood there’s all kinds of things and stuff going on but what we’re going to be talking about is what the title question implies for you when you’re browsing the web.

Server side rendering

This is the most common way to deliver a web page and it has been used since forever. What happens here that gives it its name is that when you make a request to the server you include all the information that server needs to know in order to send you the correct response. The server then gets to work and takes some kind of file that looks a bit like a finished web page but different. It has a bunch of weird things in it that don’t look anything like what your browser understand.

But the server does understand, and it starts replacing all those extra bits with what should actually be in there. Once it is done with all this it has created a finished web page and it begins sending it back to you as a response to your original request so that when the page arrives in your browser it is all ready to go. Your browser doesn’t need to do anything else and can safely display what it received as what you want to look at.

Client side rendering

But there’s a relatively new way to display web pages. One that has been possible for a long time, just not reasonable. What if we just sent you all those extra bits the server has and let your computer figure out the rest? It works, you’ve probably visited sites that do it, and it has quite some benefits too.

In this method the server simply sends you a bunch of crap. Stuff that doesn’t look like anything. If you were to just display it as it comes in to the browser it looks like nothing and doesn’t work at all. But your browser knows what to do with it and it gets to work taking all those bits that shouldn’t be there and replacing them with the functioning parts. Very quickly your browser will have a fully functioning web page ready for you to view and interact with.

What does this mean for me?

When the server renders your page this means that every time you go to another page of the website you need to send a new request to the server with all the new info the server needs to know. Every request has to contain every single piece of information about what the page should look like, if you’re logged in or not, or if you’re on page 2 or 3. It also causes the whole page to update as that’s what your browser receives. The page in full.

With client side rendering after your browser renders the page it no longer has to ask the server for what every new page looks like. All that information lives in your browser now letting it update only the parts of the page that need to be updated so that changing between page 2 and 3 goes as smoothly as it can be. It means you can go between a lot of pages that don’t require any new information from the server basically as fast as if you were running an app straight from your phone. Because, more or less, that’s what the page has become. And when the page does need new information from the server it just sends this request in the background and receives as a response only the information it needs to know.

Which one is best then?

Currently, despite client side rendering getting tons and tons of attention, server side rendering still remains king. Server side rendered pages load a lot faster, they work better on slow devices like phones, and the people who make the pages have more control over their servers than they do your device you’re using to browse the internet.

Why not both?

We do use both! Almost every single website does. But out of the ones who do the client side rendering is very simple and relegated to only a few duties. It’s the exact same idea but what we have now and call client side rendering is far more complex to the point of separating these 2 categories. The difference is only a matter of scale.

Where’s the line drawn? Hard to say exactly, and people are arguing constantly, but if you hear the words “Angular” or “React” chances are good there’s no fence sitting going on and that your browser is the one doing the heavy lifting. But we’re not here to argue nuances, I’m writing this to explain advanced concepts in what I hope is understandable to most people who don’t know why the internet works.

Is that all?

Far from it! There’s so much more to this topic and if you’d like to know more the first step is to understand what HTML is. After that you need to learn how JavaScript interacts with the HTML but that’s a much more complex topic.