The Full Stack Development Journey Part II: Backend Basics

If you’ve already read Part 1 of this series, it should be clear that there is a major component to our development journey that requires some attention: the backend.

When I began programming, the distinction between frontend and backend wasn’t 100% clear to me. If you consider different architectures — servers, serverless, microservices– it can become overwhelming. My recommendation to anyone who finds themselves in this confused position is to first think about the most basic structure of an application.

In Part 1, we created a “static” app which was composed of HTML, CSS, and Javascript. This is purely “frontend.” Each time that your browser loads this website, it will be the same exact site, with no data that has changed. Compare that to a site with a backend and dynamic data; Instagram, for example, with a timeline populated with the latest posts from your friends. In order to see this “dynamic” data on Instagram, we need a central server: a backend.

The following time estimates assume 20-25 hours of study/week and some previous foundation in coding principles.

Phase 5: Learn Express with Node ~ 1 month

For your first server-side coding language, I recommend Node because it uses the same syntax as Javascript. Node is a relatively new backend coding language that takes advantage of many modern frameworks and has thousands of “modules” which can make development faster.

Express is by far the most common framework that is used with Node. Just as jQuery doesn’t offer any new functionality to Javascript, Express actually doesn’t offer any additional functionality to Node, but makes it faster to develop with fewer lines of code. I typically recommend first learning the language itself before diving into any frameworks, but the Node+Express combo is an exception, and I believe you can learn them in conjunction (Codeacademy offers a detailed step-by-step tutorial if you have zero experience here).

Node gives you the ability to “start a server,” which means your personal computer will dedicate a portion of its hardware and memory to execute your node code and actively listen on a particular port. As we develop our application, our frontend will be able to communicate with our backend by sending a request to this port that we are currently “listening” to.

For example, after we’ve typed in a username and password and clicked “login,” we’ll be sending a request from our frontend to our backend server, which has an “endpoint” at that port.

In the early stages of learning backend development, it’s most important to learn how to start a simple server on your computer and to develop an intuition on how this communication between frontend and backend happens through a series of requests and responses to your different backend endpoints. As your app evolves, you’ll have endpoints for different functionalities: myserver.com/login, myserver.com/user/profile, etc.

Phase 6: Databases ~ 1 month

The missing piece to a basic application architecture is a database structured to store and retrieve large amounts of data efficiently. Going back to the example with sign-in functionality (after our frontend has sent a ‘request’ to the backend endpoint www.myserver.com/signin), our backend will process the request, and then compare the credentials to what is saved in the database.

A proficient full stack developer knows how to structure a database for efficient lookup. However, this should be balanced with structuring the database for minimal duplication of data. Typically, a non-relational database offers a more simple structure and faster lookup, but more duplication of data (which means you will need to allocate more resources to accommodate for more data entries). Relational (mySql) databases have traditionally been the more common and cost-effective pick, but due to increasingly cheaper storage space, more and more are opting for the more straightforward non-relational database option.

You can create a database, add entries, and perform lookups directly through your terminal. I recommend taking a week to step away from your app/code and practice directly with your database, at least until you develop an intuition of how data is stored, and the difference between a relational and non-relational database. After you are comfortable with that, you can use an ORM, such as Mongoose, to read and write to the database directly from your code.

Phase 7: Deployment ~ 1 week

If you got your static site up and running on Github Pages, you’ve technically already deployed a website. Although we introduced the site as exclusively “frontend” code, that’s not entirely true. Behind the scenes, Github Pages deploys your Javascript, CSS, and HTML onto a server that bundles that code and sends it to any client that requests it (the ‘request’ is made when someone navigates to your URL, and their browser is the ‘client’).

Taking it a step further, if we want to deploy an application which also has backend code (our node code), we need a cloud server that will be able to constantly run this node code and actively respond to client requests. For starters, I recommend Heroku since I have found it to be the most straightforward. From there on, your code lives on servers that Heroku has configured, and any time that a new client request comes in to view your app, the bundled frontend code will be sent to that client. It will then be a series of requests and responses from the client to the Heroku servers, which is actively running the backend code.

—

Now that you’ve given 3-4 months of attention to Part I and about 6 weeks to Part II, you’re ready to move onto the final Part III in this series.