Chapter 8: Frontend and Backend Web Development

Chapter 8: Frontend and Backend Web Development#

Instagram is a platform built on quickly scrolling through loads of photos. But have you ever wondered where those photos are stored? Is Instagram downloading those photos to your device, or maybe it's saving them somehow to the browser?

If you've ever seen the "Storage Almost Full" message on your phone, you know that photos devourer storage space. It's unlikely Instagram is downloading all the photos to your device. Additionally, it's no secret that downloading photos takes time, much more than it does for the next Instagram photo to show up as you scroll.

So how does Instagram do it? Instagram accomplishes this feat by storing all of the photos on remote servers (remember our cloud discussion in the Git Chapter), and requesting those photos as you scroll.

I have grossly oversimplified an impressive feat of engineering to describe "how" Instagram works. I have done this to help set up the following conversation about data storage and the transfer between the Frontend and Backend. With this goal in mind, I feel it is OK that I have left out the details. If you do desire more, I encourage you to subscribe to the Instagram Engineering blog, or read this dated but still helpful article written by Instagram engineers.

At the time of writing, there are over 40 billion photos on Instagram's servers; that's about 5 photos per person on earth!

Holding all of these photos means Instagram uses a whole heck-of-a-lot of servers. The number of servers Instagram uses is not public information, but Facebook - who owns Instagram and houses the Instagram servers - has been building server farms constantly since 2011. Each of Facebook's server farms houses tens-of-thousands of computers.

A server farm is a term used to describe the building holding servers (also called a Data Center). To help you understand just how massive these "farms" can be, here is a picture of a server farm in small-town Prineville, Oregon. Facebook is still adding square footage to this facility. Taking into account the plans for new construction, this server farm will eventually take up 3.2 million square feet. That's a lot of computers, storing a lot of data. This server farm is just one of many owned by Facebook.

Let's recap. As you merrily scroll through your Instagram feed, your phone or browser is making requests to a server farm, and the server farm is sending back photos. Photos are being downloaded and stored on your browser and device, but only the ones you have viewed, and a good chunk of that data is removed once you close the app.

Terminology: Frontend, Client-side, Backend, Server-side, UX, UI#

The reason we're discussing how Instagram delivers content is that this process for delivering images illuminates an important separation in Web Development between the Frontend and the Backend. It's worth noting that all the exercises and examples in the book so far have been of Frontend programming.

You'll sometimes see the Frontend spelled front-end or Front End. Similar spelling differences exist for the Backend. Ultimately, the spelling doesn't matter, but I think "front end" and "back end" conjure up different topics, not related to programming. I think formally the "correct" spelling is Front-End, but that's a little too formal for my taste.

Frontend#

The Frontend in the Instagram example is what the user interfaces with; all the HTML, CSS, and JavaScript you interact with to use Instagram. That includes the scrolling, any menu buttons you use, the ability to edit photos, etc. Additionally, the Frontend is responsible for the short-term storage of data. Instagram is downloading a minimal number of photos to your browser or device as you scroll, but all of this data is temporary.

Backend#

The Backend in our Instagram example are the servers, storing data, receiving requests, and responding to those requests. As well as all the code that manages the logic around returning the data and processing it.

When talking about Frontend vs. Backend development, you will also read or hear the term "client-side" and "server-side." These terms are so closely linked to Frontend and Backend that they are often talked about as if they were synonymous; client-side the same as Frontend and server-side the same as Backend.

But they are different. Client-side and server-side describe the where; Frontend and Backend describe the what. Let's take a closer look.

Client-side#

As discussed earlier, the Frontend is concerned with all things the user interacts with. The term client means your device. If you're playing Solitaire on your computer, your computer is the client. If you're on your browser Googling, the browser is the client. If you're scrolling through your Instagram feed on your phone, your phone is the client.

With that in mind, the term "Client-side" refers to everything that is displayed or any processes that happen on the client.

Take, for example, our Exercises with HTML, CSS, and JavaScript. For all of those examples, we relied on a browser to interpret and display our work. All of this is done on the client, i.e., the browser. Remember our event listeners in the JavaScript example? The client, i.e., the browser handled those event listeners. In all three of those chapters, we never once used a remote server to help us process the code. It was all done by the client. It was all Frontend development.

To recap, the term Frontend describes all the responsibilities and processes that run on the client. Client-side refers to where the Frontend runs its processes, e.g., the browser, smart-phone, computer, etc.

Before jumping into the Backend and server-side discussion, I want to take a small sidestep to review two crucial Frontend terms; UX and UI. Understanding these terms will also clarify what "responsibilities" the Frontend is concerned with.

User Experience (UX) and User Interface (UI)#

UX stands for User Experience, and UI stands for User Interface. You'll come to see that these terms are self-explanatory after working through some examples.

UX is how the user experiences the platform. If you find yourself frustrated at how Instagram feels as a platform, then you're having a bad UX. Let's use a non-computer example to expand on this concept. Think about the coffee mugs in your home. Do you have a coffee mug you always use? If yes, then for whatever reason - maybe it's sentimental, or you like how it holds heat - you have associated a positive UX with that mug.

UI, on the other hand, is about how you interact with the web page or app. For example, maybe you really dislike how Instagram uses the heart icon to indicate a like. You don't love the picture, you just like it, and you dislike that you are forced to either do nothing or express your love for a photo. That is bad UI - at least in your opinion. Or maybe you like your microwave because of that instant 1 minute button. It's an easy one-click action; your microwave has a good UI.

UX and UI are essential concepts for Frontend development. They both deal with how the user interacts with all things Frontend.

Server-side and Backend#

Given our earlier discussion on server farms, it shouldn't surprise you that "server-side" is paired with Backend. The term server-side clarifies the location of the Backend processes rather than defining what the Backend is responsible for.

The term server-side reinforce that the Backend code is running somewhere on a remote server, and not on the user's computer; not on the client. In our Instagram example, the server-side - the location - is the remote servers at Facebook's server farms.

In general, the Backend is responsible for logic. So for example, if you enter a discount code while checking out on Amazon, the processes that validate the discount code and recalculate the price should be done by the Backend - on remote servers, and not on the client.

The Backend is also generally responsible for managing data. For example, when someone signs up for an Instagram account, their login information, profile information, and photos are organized and managed by the Backend, all on remote servers.

No discussions yet