When I started learning web development six months ago, I had a clear goal: learn the full MERN stack. Well, the expression might have been clear, but the truth was that I had no clear idea what that meant. I had a general notion that it involved something called the “frontend,” which sounded artsy and beyond my capacities, and something called the “backend,” which sounded serious and therefore fun. The backend also involved dealing with databases, a topic that the frontend apparently eschewed. The goal of this point is to try to boil these ideas down in hopes of making it easier for other people wanting to become full stack developers.

One thing I learned pretty quickly is that the frontend is not just for visual design mavens. Depending on the nature of your application, a lot of logic and programming goes into frontend development. It’s not just making divs line up with CSS magic (though there are people who are amazingly talented at that, and there is indeed a ton to know about it). One of my first serious projects, a word game called Anagrab which featured as many variables, conditionals, and other forms of logic as you could hope to see, even though according to the nomenclature it is a purely “frontend” app written in pure HTML, CSS, and JS.

I wonder if in some ways it’s better to think of the ends as the “client side” and the “server side” (though the client side will also be hosted on a server…). Frontend client side programming involves the visual interface, sure, but especially using the MERN framework of ReactJS, plenty of hardcore coding as well. The real distinction is that everything you’re doing is on the client’s computer, and totally transparent to the end user. You can keep no secrets as long as you’re programming on the client side. Wordle, which at least originally was written solely on the frontend client side, was thus quite vulnerable to cheating because the “hidden” word is right there in the code if you know where to look.

To offer an analogy, then, the frontend is like your unfenced front yard. Your front yard is yours to do with as you please, and you can make it as elaborate as you want. But there’s no keeping anything secret there. Everybody can see what you’re up to, and in certain circumstances something you leave in the front yard might end up getting swiped. Thus the need for the backend, which in this analogy is your house. With your house, you have more control over what parts of it are exposed to view (whether you leave your prized faberge egg collection by an open window or in a safe hidden in the bedroom, for example) and to access. Maybe you leave the front porch open, or even leave a bowl of Halloween candy on the stoop with a sign saying they are free to take, whereas your valuables are behind locked doors.

This scheme for deciding what parts of the server-side stuff to expose and under what conditions is called an API in the lingo. The API is just a set of rules defining, for example, that there’s a pitcher of lemonade on the front porch anyone is free to pour a glass from, whereas your faberge eggs will be accessible only to someone with the proper pass code and keys. The need to conceal things like passwords, payment information, and so on is what makes the backend so essential. This API programming is not necessarily more complicated than programming the frontend, therefore, and may even be simpler in certain circumstances. One essential feature of the backend is working with databases, which are like your house’s storage — programs are not set up to keep track of their own data in between the different occasions when they are run, so some program needs to have the job of making sure that essential information doesn’t get lost, and that’s your database. The database has to be a part of the backend, because if we just allow access to our database willy-nilly people will be able to play all kinds of havoc with it. Instead, access to the database will be governed by our API that we write on the backend.

When you’re writing a full stack app, then, you’re really writing at least two different programs at once, that will often be hosted on two different servers, or two different serving programs running on your localhost listening at different ports. This creates some delightful challenges, particularly when it comes to deployment. In my next part of this series, I will give a walkthrough of how the MERN stack maps onto this scheme, and discuss in more detail the progress I’ve made over the last six months in implementing a full stack application.