This post is adapted from an internal presentation I gave at Packback on March 6, 2018.
- Why Should You Care?
- How Websites Work
- The Front-End
- The Back-End
- The Database
- Putting It All Back Together
Why Should You Care?
Why non engineers benefit from knowing what “front-end” means
As engineers, some of our most important work is in communicating what we do (and how) to non-engineers. Whether this is fellow team members or customers, this communication is critical to ensuring that miscommunication is minimized and that decisions are made from a shared base of knowledge.
At Packback, this communication might include talking about hiring for front-end and back-end roles, breaking out a project into the front-end and back-end components, and having customers and team members report issues that tie into bugs in our front-end and back-end functionality. When we talk about a bug being “on the front-end”, it is important that our fellow Packback teammates understand what that means, and what other bugs they reported might be described that way. I suspect that this is true for other organizations, and hence the importance of this mutual understanding.
More philosophically, however, providing our fellow teammates with insight into our engineering team, process, and how our website works makes engineering more approachable. At Packback, I found that many team members were curious to learn more about what engineering did in terms that are more than just the product outcomes and final outputs. However, without any technical background, many felt that they lacked the knowledge to grasp these concepts; it is part of our job as engineers to prove that to be untrue, and to help make technology in general accessible.
If you are an engineer, hopefully you can provide this resource to the non technical folks that you work with to help them better understand what you do.
If you are not an engineer, you are in the right place, and I hope this guide can help you understand some of the terms engineers often use, and understand some of the basics of what makes a website work.
Finally, a quick note: the breakdown I provide here comes from how we organize teams at Packback, but many companies might have separate teams (like DevOps) that do specific parts of what our back-end team handles at Packback. That means this might not represent your company exactly, but I hope it still serves as a valuable resource.
How Websites Work
Going behind the curtain of how users might perceive a site to work
To start our dive into how websites work, let’s take a look at how users might think a website works.
The above diagram represents how a non technical person might perceive the process of viewing a website. They open up their browser (Chrome in this case), request a url (e.g. packback.co), and the company (Packback in my diagram) returns the website as it is in their browser.
This assumption isn’t inherently wrong, and it is a generally accurate way of thinking about the web. You ask someone for a website, which is found at a URL, and they do something and return their website to you. However, this idea simplifies the role of the host to being a single entity; in reality, most website hosts are made up of several pieces that work together to create the website that users see in their browser. Let’s take a look at a more thorough diagram that shows us some of the pieces that make up the insides of the website.
The pieces we now see are the front-end (shortened to FE), the back-end (shortened to BE), and the database. Not all websites have all three of these pieces, but most do, and understanding what they are also helps us understand when they might not be necessary. Let’s dig into what these three pieces are, and what role they serve in making the website that our users interact with.
The part of a website that users touch and feel
Like my subtitle suggests, the front-end of a website is the primary part of our site that users interact with. This quote describes it well:
“The front end of a website is the part that users interact with. Everything that you see when you’re navigating around the Internet, from fonts and colors to dropdown menus and sliders…” source
Developers who work on the front-end (front-end developers) take designs and wireframes, and make them into an interactive website. The front-end part of a website generally handles the look & feel of the site, but can handle certain functionality on its own.
Front-end developers priorities often include:
Making the site look good across browsers & devices (e.g. Chrome and Firefox)
Making the site work for all users (called accessibility)
And, of course, making sure that the site looks and behaves like designers envisioned.
A Quick Example
In the image above, one of the images is a mockup made by a designer, and one is an actual interactive website as implemented by a front-end developer. Can you tell the difference? Some details might be slightly off, but the work of creating a website that looks just like the design is one of the biggest parts of what a front-end developer does. By the way, the design is the image on the left.
Servers, databases, and queues. Oh my!
If the front-end of a website is the part of a website that users interact with, the back-end can be considered to be (in some ways) the opposite. To cite my same source from earlier:
“The back end of a website consists of a server, an application, and a database. A back-end developer builds and maintains the technology that powers those components which, together, enable the user-facing side of the website to even exist in the first place.” source
The back-end team manages the servers (computers that host parts of our website) that serve our website to users, and the back-end itself. The back-end of a site often connects with the database (which we’ll talk about in just a moment) to provide information the front-end might request, like the information of a user with a certain name.
In short: Back-end developers handle storing and fetching data as requested by the front-end, handling scheduled tasks (like grading at certain times or sending emails). It is the part of the site that a user cannot directly interact with.
Back-end developer priorities often include:
Efficiently retrieving data
Managing infrastructure (the servers we mentioned earlier)
Security (making sure the right users can do the right things)
Handling load (preparing us to handle lots of users at once)
Another Quick Example
Let’s use the gradebook example earlier that you saw a design of, and setup a hypothetical scenario.
The scenario: A professor puts in that their class deadline is 5 pm on Fridays. The back-end will do the following:
The back-end will pull the posts across the community every week, and calculate the grades for each users based on the professor’s deadline. It then stores these grades on the database for later retrieval.
When the grades have been calculated, the back-end sends an email to the professor, letting them know that their class grades have been updated.
This scheduled process, giant data calculation, and storage of data simply isn’t possible on the front-end; we need the back-end to do it!
Putting our data somewhere for safekeeping
By now, we have talked about the front-end and the back-end, and we’re missing only one piece: the database!
So what is a database? A database is a way to store data long-term. Think of it like a giant, internet accessible spreadsheet. When information needs to be stored permanently (like information about a user, a new post, etc.) it is written to the database, and read from it later. The database can be queried to answer complex questions about the data (e.g. Pull all users whose account was created in the past month and have not made any posts).
It’s really that simple. We use databases because our servers can’t store data permanently, so our database is where we put all information that is persistent and must be accessible in the future.
An Example Database Table
This example of a database is from an article about databases, and it seems like a nice and simple example of what a database might contain. It looks just like a spreadsheet, and contains the names of our customers, an ID that we use to easily identify them, and when their account was made. This could well be an actual database.
Putting It All Back Together
Now that we have explored the basics of our three major pieces, our complex diagram from earlier makes more sense. Here it is again:
To close, here’s a conversational example of how these pieces interact:
Front-end: Prof. Jones wants to pull his grading report for the community BIO 123. Could you send it over?
Back-end: Prof. Jones is professor of BIO 123, and we’ve graded his class for the past two weeks. Here are the grades for that time period pulled from the database.
Front-end: Thanks! We’ll show it to professor Jones.
This conversation is metaphorical (our front-end and back-end don’t talk to each other like this), but it conveys an actual interaction and how the pieces interact to create the end result that our users see. Hopefully, this better understanding of how websites work will help you to communicate better with engineers, understand more about the web, and be curious to learn more.