It seems like I’m referencing the difference between a frontend and a backend in almost every single Technically post, so I figured it made sense to spend some time diving into what those *really* are, and most importantly, give you a real example of what goes into a frontend vs. what goes into a backend in a real life application. This distinction – [so important](https://www.youtube.com/watch?v=Di1of3R-z4M)! If I’ve done my job correctly, you’ll begin to see all software you use as frontends and backends of varying shapes and sizes. So without further ado… ## Frontends and backends: the restaurants of code If you’ve been reading Technically for a while, you know that an application – like the one you’re reading this post on – is made up of just two parts: a **frontend** and a **backend**. The best analogy I’ve thought of for frontends and backends is a **restaurant**. Say you’re having a lovely evening with the homies (after you’ve hugged and kissed them of course) and you stroll into your favorite upscale Brooklyn eatery. Your *experience* is interfacing with a few things: - A nice table with comfortable chairs - High quality food and drink brought to your table - Servers catering to your every whim Fantastic. Behind the scenes though, there’s tons of logistical work that goes into being able to provide you with said experience. In particular, there’s an entire kitchen staff that worries about: - What should be on the menu - How to cook everything consistently and perfectly - Where to source quality ingredients from - How to prepare and store those ingredients - What to do in situations where ingredients are missing or go bad As a patron, you don’t need to think or deal with any of this – you interface with the “frontend” of the restaurant, and the “backend” takes care of making sure the food that arrives on your table makes you want to leave a 5 star review. It’s not a perfect comparison, but this is pretty much how I think of application frontends and backends. The **frontend’s job** is to interface with the user and call upon the backend when it needs any sort of data to provide to the user. There’s a menu of things that the backend can do for the frontend – these are API endpoints – like sending a user’s profile information, creating a new user account, or accepting credit card information. As long as you’re accessing the frontend through your web browser, it can only be written in HTML, CSS, and JavaScript (the browser doesn’t support other languages). The **backend’s job** is to take care of all of the data and logistics behind the scenes. It’s consists of the [database](/posts/whats-a-relational-database), [API endpoints](/posts/whats-an-api) for interacting with that database, and any other workflow related things like scripts for billing users, data scrubbing for compliance, and other such highly interesting and obscure tasks.

The frontend and the backend of an app are not necessarily separated physically: they’ll often be deployed on the same single server, and even sit in the same master folder (or repository) of code. Literally, I’ve seen codebases with a `/frontend` folder and a `/backend` folder.

## Real world example: Spotify If you love music as much as me you’re probably using Spotify every hour, and are pretty familiar with the app. Let’s break down which parts of the Spotify app on your laptop / phone / browser are frontend, and which parts are backend. Hopefully you’ll be able to apply this same framework to other apps in your life (maybe even the app you work on). We’ll start with the artist screen. ![rick astley spotify](/images/posts/the-details-frontends-and-backends/rick-astley-spotify.png) I’ve picked a niche artist that most of you probably haven’t heard of, but that same logic applies to what the kids are listening to these days, like Kenneth Lamar or whatever. ### What’s coming from the database The first place I like to start is figuring out what “information” that I’m seeing on the page is data – meaning it’s stored in a database somewhere – and what is just formatting and visual elements. Here’s all of the stuff on this page that’s (probably) data: - The artist name - The fact that the artist is verified - The artist's monthly listeners - The artist pick - The song names - The song listen stats - The song lengths - The actual song content (this too is data) - The playlists on the left sidebar - The fact that I’m signed in under my username All of this is likely stored somewhere in Spotify’s database(s), across a variety of different tables or data structures. The rest of the page – the layout, the play button, how far into the song you are, volume – is pure frontend code. So the frontend here is doing a couple of things: - Creating the visual scaffolding and organization - Making calls to the backend APIs asking for artist and song information Again, just like the restaurant: you experience this nice Spotify screen filled with all the data you need, because the frontend set it up for you and is interfacing with the backend (kitchen) to serve you up some fire tunes. ### When does the data get loaded (pages and screens) Most of the calls to the backend are happening when this page gets loaded. The exception is the data for each individual song – the actual song – that only gets sent to the frontend once you click play on the individual song. The backend doesn’t send that data on page load because then your app would have to load the audio data for *every* song on the page, even if you only intend to listen to one of them (or none of them). This same logic holds true for subsequent clicks into more artist details: ![rick astley spotify](/images/posts/the-details-frontends-and-backends/rick-astley-spotify.png) Here I’ve clicked on a specific album, and two things have happened: - The frontend changed my screen to an “album view” format - The frontend asked the backend for data on each song in this particular album This data was *not* fetched when we loaded the initial artist page, because the frontend didn’t need to display it. Now that we’re viewing this specific album though, the frontend told the backend that we needed this new set of data to display. By the way, here’s what a call to the backend might look like (very oversimplified): ``` // fetching the songs for Rick’s page songs.filter(artist=”rick_astley”).get.top(10) ``` The frontend doesn’t just *display* data – it can also create new data on the backend. If you like an artist on the frontend, it’s going to send a call to the backend telling it to update your data with this new info. When you create a new playlist, that’s being written to the backend as well: ![technically beats playlist](/images/posts/the-details-frontends-and-backends/technically-beats-playlist.png) Each new song you add to it gets stored on the backend, etc. In other words, there’s both reading and writing going on here. ### Stuff kept in memory (local data) Though most data is kept in the database and served through the backend, there’s *some* data that’s stored in the frontend itself. This is usually just temporary stuff that relates to how you use the app – since reloading the page or quitting the app will destroy any data saved in the frontend (often called “state”). ![rick astley spotify](/images/posts/the-details-frontends-and-backends/rick-astley-spotify.png) Can you identify any of that local state here? - The currently playing song is highlighted in green - The fact that I’m 29 seconds into the song - The volume is at half of max - Your browsing history (back and forward buttons) None of this is stored on the backend, it’s all scoped to your usage “session” and will most likely disappear if you quit the app out (with a few exceptions). The frontend makes use of local operating system APIs (like [local storage in your browser](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage)) to actually save this data. ## Some final / misc. notes Hopefully by now you’ve got a decent sense of how to break down an application into its component parts. A few more things to think about on your frontend/backend journey: ### Web apps vs. native apps Frontends vary by what operating system or “platform” they’re designed for. The code that Spotify’s developers write for you to access Spotify *in your web browser* is very different from the code they wrote for you to access it *on your Mac*, which is very different from the code they wrote for you to access it *on your iPhone*, and so on and so forth. The backend is pretty much the same (this is how your playlists on your iPhone are the same ones as on your computer). The big two categories here are usually called “web” (accessed through your browser) and “native” (accessed through an app on a particular platform like iOS). ### Client side vs. server side rendering

For more about requests and responses, read the Technically post about HTTP.

When you load a page, you get the whole thing – the visual scaffolding and the data served from the backend. There are a few different ways that can make it to you logistically: - **Server side rendering** – the data gets combined with the page on the server, and is sent to the user in one big bundle. - **Client side rendering – the user loads the page by itself, and then the page sends requests to the backend for the data it needs.** Today there’s no particular standard, and what style developers choose very much depends on the unique constraints of their app. Modern web frameworks like [NextJS](https://nextjs.org/docs/basic-features/pages) often let you choose on a page by page basis. ### Deployment models I mentioned that frontend code and backend code are not always separated, and sometimes are even deployed on the same server. How *do* people deploy frontends and backends in general? There are a few models I’ve seen: - **Frontend and backend deployed on same server** – one giant server (or less likely, distributed across servers), all code together. - **Frontend and API deployed on same server, database on separate server** – likely if you’re using a third party service like RDS or PlanetScale to host your database. - **Frontend and backend on separate servers** – self explanatory. - **Frontend on some serverless thing** – like [Vercel](https://vercel.com/) or [Netlify](https://www.netlify.com/). - **Backend on some serverless thing –** like [Supabase](https://supabase.com/) or [Render](https://render.com/). - **Both frontend and backend and some serverless things** – some combination of the above. [Infrastructure decisions](https://read.technically.dev/p/ask-technically-1) – they’re not fun.