Apps + Webservers

How mobile applications interact with their server counterparts is a question that continually surfaces for first-time programmers. Being a relatively new programmer, it took awhile for me to grasp the abstract concept of Webservers. But let us try and break that abstraction down.


Ignoring servers

Let us ignore servers for now and talk about our application’s code. Whether you are working with Obj-c for ios or Java for Andriod, our application’s code has a sole function. And that function is to receive data, manipulate it and present it to the user, hopefully in a magical way. If our application’s purpose is to present data (i.e. usernames, profile pictures, messages etc..) Where does the data come from? We could store data locally. However, storing vast amounts of data locally would be inefficient and pose headwinds for scalability as our application grows. Thus, we introduce our lovely friends: Webservers.


Our friends the Webservers

To receive information, our application makes a request to a Webserver. The server then sends back a response and our application parses/converts the response into data we can use.

These servers are owned and managed by Webservices companies such as Amazon Web Services, Heroku, Azure and Google App Engine. These companies are responsible for both the physical and software maintenance of the servers.

Lets look at a simple example and see how it works. We can think of this in two components. Firstly, we would need a “brain” to govern our servers logic. This “brain” is simply a computer/virtual machine which houses our backend code. And in turn our code governs what the “brain” does. When our application sends the server a request for specific pieces of information (i.e. a users profile), the virtual machine receives the request. Based on the logic we’ve implemented in our backend code, it then figures out what information was requested and goes into our database to find it.

Our second component, as you might have guessed, is a database. The database holds all our applications metadata such as our users information, passwords and e-mails etc… After retrieving the respective data ,the virtual machine formats it and prepares the data for a return response to our application.

We can think of the virtual machine as a “brain” because it controls the interaction between our application and the database. The virtual machine communicates with our application through HTTP requests. And it returns data in a format called JSON.


HTTP & JSON

In most cases, our application makes HTTP (Hypertext Transfer Protocol) requests and the server responds with JSON (JavaScript Object Notation) data.

HTTP as you might have guessed it, is exact same way communication is handled over the World Wide Web.

JSON is an easy way to exchange data in human-readable format. After our application parses the JSON data it would look something like this:

{
"firstName": "John",
"lastName": "Smith",
"isAlive": true,
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021-3100"
},
"phoneNumbers": [
{
"type": "home",
"number": "212 55-1234"
},
{
"type": "office",
"number": "646 555-4567"
}
],
"children": [],
"spouse": null
}

Does this look familiar? JSON is made up of arrays and dictionaries!

Bringing it all together

Lets say our user entered a profile view. Our application needs to retrieve the profile information and display it to the user.

Steps

  1. Our application sends a HTTP request to the sever, requesting the users profile information.
  2. The virtual server receives this request and proceeds to search the database.
  3. After retrieving data from the database. The virtual machine formats it for a response to our application.
  4. Our application receives the response in JSON format and parses it into useable data.
  5. The application takes the parsed data and displays it to the user
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.