Explain Full Stack to Me Like I'm in 5th Grade

We hear the term Full Stack Developer thrown around all the time; we see it in articles, job descriptions, tutorials, hear it from developers, recruiters, and news stories about coding bootcamps. But for those of us interested in learning how to program, Full Stack is just one more vague term in an ocean of new, technical verbiage that we don't fully understand. In this article, we will attempt to blow away the fog that tends to accompany the term Full Stack.

The Front End

There are many ways we could look at Full Stack, and more than enough places we could start the explanation. However, a great place to start is by focusing on what we are all most familiar with, and that is what we see when we sit down at a computer.

A Full Stack web application consists of multiple parts (the front end, back end, and database are the main, high level components). The piece we are all most familiar with, whether we know it or not, as users of websites and applications, is the Front End. This is what we see and interact with, the user interface; when we go to Facebook, eBay, Amazon, or whatever site we are using, what we are looking at is the Front End of a web application. The Front End is all about displaying data in a way that makes sense to us, the users, and allowing us to interact with that data. What type of data does that entail? It could be anything, depending on the app. For example, some of the main data that users interact with on Facebook consists of friend information, posts, comments, pictures, etc... Data on Amazon will be product and customer information such as price, stock quantity, delivery date, address, credit card info, etc... All this data is displayed to users in a nice, pretty manner so that the user experience is better than reading a list of plain text.

Some of the most common technologies/programming languages used in creating the Front End are HTML, JavaScript, and CSS. HTML, which stands for Hypertext Markup Languague, provides the structure and layout of a web application. CSS stands for Cascading Style Sheets, and is in charge of adding style to the application and making it look appealing. JavaScript is the programming language used to add functionality to the application; calculations and requests to the back end (something we'll discuss later) all fall into JavaScript's jog description. These are the main tools used to create the front end of an application, but there are many other tools, libraries, languages, and frameworks that are used as well. Some common examples of libraries and frameworks include ReactJS, Angular, Vue.js, Sass, and Less.

All of these technologies help display data to us in a usable way, but where does all the data come from? The data doesn't exist on our computer (our computer wouldn't be able to hold all that data, let alone keep it updated), and that's important to know because the Front End (which can also be known as the client) runs on our computer. To get the data the Front End has to call a friend (using JavaScript) and request the data that it then displays - that friend is the Back End.

The Back End

As we mentioned before, the Front End displays everything to the user and makes things pretty, but it doesn't store all the data to display (because it runs on the user's computer), the data has to come from a computer, or server, that lives somewhere else and is owned, or rented, by the business that owns the application. These servers are running another piece of the full stack, the Back End. The Back End application is responsible for handling requests that come from the Front End, interacting with a database (which will be discussed later), performing some processing of data, and returning that data to the Front End to then be displayed.

So, the Back End listens for requests, does some stuff, then returns a response to the received request, but what might that look like? Let's take a look at our Facebook example. Let's say we log on and click on the link to show all of our friends. The names of our friends and the links to their pages are not stored on our computers where the Front End is running, the Front End needs to get this data from the Back End. When we click the button to view our friends list, JavaScript sends an HTTP (typically AJAX - Asynchronous JavaScript and XML, but not always) request to the Back End server asking for a list of Facebook users that are friends with you. The Back End will then get that data from the database and put it into a representation the Front End can easily interpret (usually JSON or XML), and send it back.

In summary, the Back End is kind of like a middle man between what the user sees on the Front End, and the database. One important reason we have this middle man instead of just having the Front End call the database directly is so that we don't have to duplicate all the code that interacts with the database if we want to add an additional Front End. If we add a new client, we can make the same calls to the Back End that already has everything coded and working to interact with the database. It also adds a layer of protection around the integrity of the database's data if we make sure it's the only way data gets in and out. Some names you'll hear Back End applications referred to as include API, Web API, Service, Server (server-side), and Micro Service.

Some common technologies and languages used in building the Back End portion of an application are Java, C# .NET, PHP, cloud hosting (AWS, Azure, Google Cloud, Heroku), and really an almost never ending list.

The Database

We've already mentioned the database quite a few times, but let's look a little deeper at the role of the database. The role of the database is to store all the data. We all know that data is important, but have you ever thought of what an application would be like without the ability to store data? Imagine playing a video game where we had to start over every time we rebooted our console. Or logging onto our social media account and not having any of your friends/followers, posts, comments, or preferences saved; if we had to recreate this data each time we logged in we wouldn't use the application, it'd be useless. In fact, we wouldn't even be able to log in because our credentials are data too!

The most common types of databases are Relational Databases, which store data in tables (similar to spreadsheets with columns and rows), where rows in different tables can be related to each other based on keys and IDs. For example, let's go back to our Amazon example. We may have a table that stores all of our user data such as first name, last name, and shipping address, and then we may have another table that has all the information about products we sell, such as name, description, price, quantity in stock, etc... When a customer purchases an item we would want to draw a line between the customer and the item they purchased, which could be accomplished by creating another table and storing the IDs of customers with the IDs of products they've purchased. By doing this, we mitigate the need to have countless columns in a table. For example, we don't want to end up with a customer table that has all the customer info and then has rows for each item they purchase such as item1, item2, item3 ... item1000, etc... this would be unmanageable and inefficient. Relational databases help us overcome these issues and others through building relationships between data. Some common relational databases include MySQL, Oracle, Informix, Microsoft SQL Server, and more. We use SQL (Structured Query Language) to interact with databases (read from and write to databases).

A newer type of database, that has gained some popularity, is the Document Database and other NoSQL databases. We don't use SQL to communicate with these databases, hence the term NoSQL, however, each database does provide it's own way of interacting with the data it stores. Document databases store data in collections instead of in tables. A collection contains multiple documents, and each document can represent an entity of some sort (like a customer, a product, a post, etc...). Each document contains all the information needed to fully describe itself, and while creating relationships between documents is possible, it's not as easy as with relational databases. Some common databases that fall into this category include MongoDB, Cassandra, Redis, and more.

The Full Stack Restaurant

Now that we have an understanding of the Front End, Back End, and Database, let's put it all together by looking at our favorite Full Stack metaphor - The Restaurant. Imagine you are at a restaurant. You sit down at a table and pick up a menu. After deciding what you want to eat, you tell the waitress, who writes down your order and takes it to the kitchen. In the kitchen, she hands the order to the chef, who then goes to the pantry and refrigerator to get the items needed to complete your order. The chef then cooks and prepares the food, gives it back to the waitress, who, in turn, gives the food to you.

In this metaphor, you are the user of an application. The menu and the waitress make up the front end. When you say what you want to eat, that is like clicking a button on the user interface (the Front End). The waitress writes down what you want to eat and sends it to the chef; this is just like the Front End sending a request to the Back End, the chef is the Back End. The chef then goes to the pantry and fridge, which represent the database, where she grabs the necessary components to complete your order (the data), cooks and prepares it (processes the data), and gives it back to the waitress, which is like the response the Back End replies to the request received from the Front End with. The waitress then returns the food to you and places it in a presentable manner, just like when you see the newly loaded data from your computer.

If we remember this metaphor, we will retain a solid understanding of what Full Stack means and what some of the different, major components that make up a Full Stack application are.

Hopefully you enjoyed this article and learned something from it! If so, then stay tuned, because over the next few weeks we will be writing additional articles that break down some of the technologies mentioned here to help you gain a better understanding of each specific technology, what their roles are, and how they're used!

---

If you would like to pursue a career in software development, whether as a first career or if you are making a career change, check out the programs we offer at www.promineotech.com. Our mission is to provide extremely affordable, low-risk education to provide anyone who wants to enter a career in technology a viable path!