You bump into one of your software engineer colleagues. You didn’t mean to; she was heading to the foosball table, and you were getting a refill from the kombucha dispenser. But here the two of you are. Hoping to make conversation, you lead with a tentative,
“So… what is it you do, exactly?”
She starts to tell you, and you kind of get it. You know what a user interface is. You’ve used apps. Facebook’s a website. You get it. You nod along to her answer, and the two of you part ways. Awkwardness avoided.
But sometimes, you meet one of the… other ones. The server engineers. The backend developers. Not knowing what you’re getting yourself into, you enquire about the arcane ways of their kind.
Listening to these foreign words, a barrage of questions runs through your mind. “What is an API? When do we use databases? And who is Jason?”
What your engineer friend is talking about is a server. Maybe you’ve heard the term before, but don’t really have any idea what that is. Today, we change that.
Down the rabbit hole
When we use an app, all we see is the app. Our experience as a consumer starts and ends there. It seem natural to think of the entire experience as “the app”.
Truth is, the app is just what’s known as the front end. It makes up the entirety of the user experience. But that is not all there is to the functioning of an app.
Say you send me a message on a messaging platform, such as Whatsapp. It appears like the message goes from your phone to mine. But let’s take a closer look at this. Let’s say that you send the message when my phone is switched off. You then switch your phone off, and I switch mine on. I still get the message, even though our phones were never running at the same time!
Clearly, we’re missing something here.
The missing component is the back end, or server.
Servers
A server is a computer that is connected to the internet and runs all the time.
A server has two main roles: storing data, and facilitating communication.
So, when you sent that Whatsapp message, the app on your phone sends the message up to the server, where it is stored. When my app checks in with the server, the server sends along any stored messages.
A server is where an app “phones home” to.
When the app needs any information, it asks the server. When the app needs to talk to another user on the app, the server is what facilitates that connection.
The terms server, backend, and API are often used interchangeably.
Storage
A primary responsibility of a server is storing things.
These include files, such as photos, videos, and documents. The server stores them in a structured way, similar to folders on your computer, so that they can then be accessed by apps.
A server also stores information. All apps have bits of information that are important to how the app works.
You can think of this as a bunch of spreadsheets. For example, apps need to store user information, and their login details, so that they can be authenticated. Your app might be a restaurant directory, in which case the server would store information about each restaurant.
Along with information, a server also records the relationships between bits of info. For example, if a user “likes” a restaurant on the app, the server remembers that relationship between that user and that restaurant.
This lets us get answers to many questions, such as:
“How many people have liked this restaurant?”
“What restaurants has this user liked?”
“What cuisines do both of these users like in common?”
Information and the relationships between them are stored in databases. There are many different kinds of databases, but they all have a few core features:
- They can store information
- They can store the relationship between bits of information
- They can be queried about the information, whereupon they respond with individual bits of information, or information in bulk, depending on what we asked for
There are too many different types of databases for me to list, and they each have their own advantages and disadvantages. If you hear someone use terms like “SQL” (pronounced ‘Sequel’), “MongoDB”, “CouchDB”, “Redis”, they’re talking about a database.
Communication
A key responsibility of a server is communicating with the app and with other servers.
Many activities on an app require communication with the server. For example, if the user searches for something, the search terms are sent up to the server, which responds with the results. If the user sends a message to another user, the message goes up to the server. It is then sent to the other user’s app, often in the form of a push notification.
The interface that the server provides, so that apps can talk to them, is often referred to as an API. The individual functions on the interface can be referred to as endpoints.
These communications can look bizarre to the uninitiated. The two most common communication formats are JSON and XML.
XML on the left, JSON on the right
At first glance, these formats can seem really hard to read.
The thing to keep in mind is that a server is just a computer, like your laptop or your phone. An app on your phone takes in user inputs, in the form of touch or voice. It processes that information. It then gives outputs, in the form of images on the screen. A phone is a computer that talks to humans, and so the inputs and outputs are human friendly.
A server is a computer that only talks to other computers.
Humans express meaning using things like font size, text color, and layout. But these are not meaningful to a computer.
Server communications happen in formats that are easy for another computer to parse and understand.
Server application
Much in the same way you would write an app to run on your phone, you need an application running on the server. A server application is built using a server-side framework. Popular options include Ruby on Rails, PHP, ASP.NET, Java, Node.js.
The API is the gateway to your server, and apps know to call there. Your database stores all your information. Your server application is the “brain” that holds everything together.
It listens and responds to requests that come in on the API, it adds and retrieves information from the database, and it makes decisions. For example, when the app sends up login information, the request comes in through the API, and the correct login info is stored in the database. But it’s the server application’s job to compare the two, and respond appropriately to the app via the API.
Hardware
When someone says “server”, this might be what pops into your mind. Racks of blinking lights in a locked room, waiting for Tom Cruise to rappel down from the ceiling and steal from.
Many larger companies do own such servers. Facebook and Google have hundreds of servers all over the world. When you are running a huge service with millions of users, running your own servers can be cheaper and offer better performance.
Instead of running their own physical servers, many developers use some kind of cloud service. Services like Amazon Web Services, Azure and Digital Ocean can provide “virtual servers”. These services own and maintain the hardware, and the developer just uploads the server application.
There are even some Backend as a Service providers, letting you have a simple backend without writing a server application yourself.
Do all apps need a backend?
Most apps you see probably have a backend component to them. There are definitely apps that don’t, like certain productivity apps. An easy way to figure out if there’s some kind of backend:
If you switched to airplane mode, would the app still work?
If the answer is no, there’s probably a backend server involved somewhere.
Hopefully you now have a better grasp of what the backend of an app looks like. Maybe, the next time you meet your friend, you might even casually drop “JSON” into the conversation.
If you found this article useful, you can help me out by sharing it! You can also subscribe to my mailing list to be sure not to miss my next article.