Imagine this…
You’ve just been seated at a fine-dining restaurant.
In front of you sits a place setting—a large plate at the center, two forks on its left, a knife and spoon to its right; two glasses—one generally designated for water, the other, perhaps, for wine; a small bread plate and butter knife in the upper left.
You have everything you need to consume the best dinner of your life…except for the food itself.
Before you know it, a waitperson approaches your table, greets your party, pours water for everyone in their designated water glasses, and places down a basket of bread. Now we’re talking. You break off a piece, put it on your bread plate, and spread some butter on it using the designated butter knife.
A few more minutes go by, and you glance over the menu as you enjoy some bread.
Then it’s time to order appetizers. You place your order and a bit more time passes before the appetizers are brought out to your table.
But what happens between the time when your order the appetizers and when they’re delivered to you at your table?
Well, they’re prepared in the kitchen, of course. Or as it’s known in the restaurant business, the back-of-the-house.
Every time you make a new food request—be it for an salad, appetizer, or main course—that order is sent to the back-of-the-house, prepared with previously-established ingredients according to a previously-established set of instructions, and then delivered to you at your table in the restaurant’s dining room—known in the business as the front-of-the-house.
The cycle is always the same: someone—you, the customer—in the front-of-the-house makes a request, which is sent to the back-of-the-house. The request is handled and prepared in the back-of-the-house—crab prepared, steak grilled—and then returned back to you, in the front-of-the-house, as the wonderful Filet Oscar that you ordered.
While I do love imagining a fine-dining experience like this one, there is a point I’m getting at…
A web app functions just like a restaurant
Web apps are comprised of two parts—the front end and the back end—that are constantly working together to perform all necessary actions and deliver all desired results.
Just as a restaurant’s front-of-the-house is responsible for a presenting the user with an expected experience and results (the food), a web app’s front end is responsible for creating the pages a user sees within their web browser.
Just as all customer requests are handled in the front-of-the-house of a restaurant, a web app’s front end handles all user interactions and requests. In a restaurant you may be interacting with a waitperson, whereas in a web app you may be interacting with buttons, text boxes, or other controls.
In a restaurant, when an order is placed by a customer in the front-of-the-house, that order is sent to the back-of-the-house so the desired dish can be prepared. As we’ll see in just a minute, when a user makes a request in a web app, that request is sent to the application’s back end to be handled accordingly.
So just as a restaurant’s kitchen, or back-of-the-house, is responsible for preparing all of the food, a web app’s back end is responsible for doing all of the heavy lifting, fulfilling all user requests.
While a restaurant’s kitchen staff chops all of the necessary vegetables and grills all of the steaks, a web app’s back end retrieves data from the database, runs any necessary calculations, and returns that data in a meaningful state so that it can be displayed on the front end, just as you are delivered the main dish that you order in a restaurant.
An example: Interactions between Twitter’s front end and back end
Twitter is an example of a very popular web app. And just as with all other web apps, it’s comprised of a front end and back end, which interact with each other in the same ways described previously.
Let’s say, for example, you want to send a new Tweet. To do so may require the following steps:
- Visit your Twitter profile online.
- Click the “Compose new Tweet” button.
- Type in your Tweet’s text and click “Tweet”.
Simple enough.
Now let’s take a look at how the Twitter web app’s front end and back end function to make all of those above interactions possible.
1. Visit your Twitter profile online.
To visit your profile, you enter its URL in your web browser (in my case, https://twitter.com/alexpcoleman). Right off the bat—based on the URL we enter—we’re making a request to the Twitter web app: “Hey! I’d like to view my profile.”
The Twitter web app extracts your username from the URL (alexpcoleman, in my case), and sends it off to its back end.
Now, within the back end, the app says “Retrieve all of the tweets for this username and send them back to the front end.”
Once that information is received by the front end, it’s rendered onto the page you see within your browser, displaying your Twitter profile.
2. Click the “New Tweet” button.
This interaction is handled entirely by the front end.
When you click the “Compose new Tweet” button (currently in Twitter’s main menu bar), you’re presented with a dialog that lets your enter the text for your new Tweet.
3. Type in your Tweet’s text and click “Tweet”.
Once you enter your text and click the “Tweet” button within that dialog, the front end of the Twitter web app sends your Tweet text to the back end, along with your username.
The back end saves the Tweet text—associating it with your username—into a database and sends a response back to the front end telling it that the Tweet was successfully saved, at which point the dialog is closed and the front end adds your new Tweet to the top of your profile.
This pattern is, in essence, how all interactions within a web app (and restaurant) function.