You just bumped 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 that 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 before, and you know that Facebook is a website. You nod along, and the two of you part ways. Awkwardness avoided.
But sometimes, you meet “the other ones”—the back-end developers. Not knowing what you’re getting yourself into, you inquire about the 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 friend is talking about is a server. Maybe you’ve heard the term before but don’t really have any idea what it is. Today, we’re going to change that.
Down the rabbit hole
When we use an app, our experience as a consumer starts and ends there. It seems natural to think of that as the entire experience. But the truth is, the app is just the front-end. There is a lot more to it than that.
Let’s say you sent me a message on a messaging platform like WhatsApp. It appears as if the message goes instantly from your phone into 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 the server.
A server is a computer that is connected to the internet and runs all the time. It has two main roles: storing data and facilitating communication.
So, when you send a WhatsApp message, the app on your phone sends the message up to the server, where it is then stored. When my app checks in with the server, the server sends along any stored messages.
So, 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, back-end, and API are often used interchangeably.
A primary responsibility of a server is storing things. These include:
- Files: These are photos, videos, and documents, which are stored in a structured way, similar to folders on your computer.
- Information: All apps have bits of information that are important to how it 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 information. For example, if a user “likes” a restaurant on the app, the server remembers that relationship.
This lets us get answers to many questions, such as:
- How many people have liked this restaurant?
- What restaurants have 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/asked about the information. They then respond with information in individual bits or in bulk depending on what is 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, MongoDB, CouchDB, and Redis, they’re talking about a database.
A key responsibility of a server is communicating with the app and other servers.
Many activities on an app require this communication. For example, if the user searches for something, the search terms are sent 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.
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, processes that information, and gives outputs in the form of images on the screen.
A phone is a computer that talks to humans, so the inputs and outputs are human-friendly. A server, on the other hand, is a computer that only talks to other computers. While humans express meaning using things like font size, text color, and layout, these are not meaningful to a computer. So, server communications happen in formats that are easy for another computer to parse and understand.
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, and Node.js.
The API is the gateway to your server, and apps know to call there. While 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, adds and retrieves information from the database, and makes decisions. For example, when the app sends login information, the request comes in through the API, and the correct login information 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.
When someone says server, this is probably what pops into your mind: racks of blinking lights in a locked room, waiting for Tom Cruise to rappel down from the ceiling and hack it.
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, though, 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 back-end-as-a-service providers that let you create a simple back-end without writing a server application yourself.
Do all apps need a back-end?
Most apps you see probably have a back-end component to them. But there are definitely apps that don’t, like some productivity apps. An easy way to figure out if there’s some kind of back-end is to switch on airplane mode on your phone. If the app doesn’t work, there’s probably a back-end server involved.
Hopefully, you now have a better grasp of what the back-end of an app looks like. Maybe the next time you meet your friend, you might even casually drop JSON into the conversation.
culled : TechinAsia.com