How To Start Learning Backend Development: The Definitive Guide
Written by Christopher Shelley, senior instructor at WBS CODING SCHOOL.
This guide is meant as a thorough but accessible introduction to backend development, both the theory half and the practical coding half. It is aimed primarily at readers who are familiar with frontend web development and who are considering expanding their skills, but anyone should be able to follow.
Our article is divided into four parts.
Part 1 will be dedicated to the theory. We will explore what ‘backend’ really is and how it differs from frontend, and we will lay out its essential concepts and key terminology.
Part 2 serves as a quick preface to the technology and languages that we’ll use in part 3.
Part 3 is a practical introduction to making a backend. We will get a backend program to print “Hello world!”
In part 4, we finish up with some final pointers and advice about continuing your learning.
This is a guide to a specific topic and not to programming in general — which is why, in case you noticed, the curriculum of our bootcamps in web and app development looks different!
New programming topics can be confusing. If you are totally new to “backend”, do yourself a favour, give the article some time, and maybe read it more than once. And by all means google a lot!
Part 1 — Let’s look at some ideas and confusing words.
I’d like to start by trying to draw some lines between different ideas and terminology. All this technical language can be confusing, and even senior developers will mix these terms up.
As front-end developers we are usually boxed in… in this box. The browser. We write our HTML files and they show up in here.
Other front-end “boxes” exist too though, right?
There’s Android apps, iOS apps, Windows apps etc. and they all have frontends too.
While developers making Windows or Android apps might be using different programming languages in different boxes, not writing in HTML and CSS, they’re still all frontends.
So, frontend: “The things that the user can see, hear and interact with”.
I thought it worthwhile to clarify this point. The frontend isn’t just a web thing.
More often than not, a frontend usually needs something more, some extra information, be it to download a video, or a user’s new unread messages (and even confirm if that user is authorised to read messages in the first place).
All of this happens somewhere else. We typically call that somewhere else the “Backend” (or API, or server, we’ll untangle that confusion later).
In a very broad sense, the backend is the stuff we don’t see directly as users. The data and logic behind the visual experience. It could be getting data from a weather service for the weather widget.
The phone itself has no way of knowing what the current weather is like, so it talks to a “backend” to get that data and show it to the user.
When you boot up a computer game and it remembers your name and what level you are currently playing, it’s reading that data from a file saved on your computer that contains all that information.
When you push control+P in the browser, a little “frontend” window pops up, and that window can talk to the printer plugged into your computer, behind the scenes (the backend!).
So these are all examples of frontends working with backends to provide a useful service or experience to the user.
So, Backend: “A program (or a file) that a frontend program can interact with to get additional information or functionality for the user”.
Let’s zoom back in to what this means in practice, and specifically for a web developer. The backend of a website is usually a “server”, that we talk to via its “API”..
When you go to youtube.com, your browser communicates with the YouTube server which will then send back an index.html file, which is the YouTube website. Your browser will then show that html file on the screen.
Then, when you click on a video on the website, the webpage will send a request to a YouTube “API” asking it to start sending the video to your webpage.
An API — or Application Programming Interface — is like the “menu” part of a server program, and is how one computer program makes specific requests to another. Another way of thinking about the API is that it is the “doorway” into the server.
APIs are pretty simple code — YouTube.com’s server looks like this:
/ -> “I’ll send them the index.html file”
/about -> “I’ll send them the about.html file”
/watch?v=dQw4w9WgXcQ -> “I’ll send them the video with ID dQw4w9WgXcQ”
You see this API usage all the time right? It’s the URL!
URLs are like a universal language, used all over, in desktop apps, across the internet, in the web, in gaming, in blockchains, to make clear requests from one program to another to find resources and ask for things.
This one’s asking wikipedia.org’s API to return an HTML file to us with information about a Cyclone:
https://en.wikipedia.org/wiki/Cyclone_Batsirai
And this URL is asking google’s search API to give us matches for our query “easy recipe ideas”!
https://www.google.com/search?q=easy+recipe+ideas
APIs are made up of ROUTES, like the “/wiki/” and “/search” above, which are like little URL-stubs leading to different places in the server with different features. This is how APIs are organised.
A bit more on this later.
(You can see the webpage you’re on making all these API requests by typing CTRL-SHIFT-J and then clicking on the network tab. If you reload the page you’ll see all the different resources for the page being requested).
So a backend is typically communicated with through its “API”, which is like a menu made up of “routes”. But where does the backend practically exist? Usually in a “server”..
The web, and many apps that you use daily, follow what is called the “client-server” architecture pattern.
Let’s try to see how the words are all related. You will hear people mixing “client/frontend” and “server/backend” together as their meanings are quite similar.
The frontend is a reference to the HTML app that you made, but might also be used more generally to reference your HTML, or the browser that is showing your HTML, or even your computer.
The backend is the “server” part. The word “server” can be used to reference the computer program “serving” the html / data to your frontend over the internet, but the word server also refers to the physical hardware, the computer running the server program. You know, these big computer things.
Software people don’t think about this hardware side of things much though..
So what’s the difference between “backend” and “server”?
The backend of an application could be many server programs combined, for example one server for pictures, one for HTML files, one for logging-in/out, one for sending/retrieving messages etc.
So “backend” is more of an umbrella term for one/many servers generally.
So once again, because this is confusing stuff…
An API is the system through which your program talks to a server. APIs are how computer programs make requests to each other.
A server is a computer program that is usually running 24/7, waiting for client applications to make requests. You communicate with servers through their APIs.
The backend refers to everything behind a frontend app (like a webpage) that helps the frontend function. The backend could consist of a single server, or 25 different servers!
For example, in the case of youtube.com, the frontend (the webpage) is probably communicating with the authentication API to log you in, the search API to search through all the videos in the database, the video streaming API to start streaming the video to your browser, etc. Those APIs are all most likely running on their own special servers.
Without turning this into an article about databases, the database is also part of the backend, and usually one particular server will be responsible for communicating with the database, asking it to find / create / update / delete documents on behalf of the client.
Okay! That’s enough confusing theory and new words. Part 1 is complete!
Part 2 — Notes about languages and technology
Which language?
Which programming language to use? There are literally hundreds of them out there, but for the majority of newcomers the choice should not be very difficult.
I’d recommend only looking at JavaScript or Python, which, trust me, will help you sidestep many other steep learning curves with other languages. These two languages are light and won’t get in your way as much as others.
(A common misconception is that the language of a server matters in relation to the front end. This is not true. Your frontend can be sending messages in JavaScript to a server that is written in C#, Swift, Rust, whatever. The requests themselves are commonly written in HTTP, URLs and JSON, which most programming languages can understand.)
If you are a frontend web developer already, or have an interest in also learning web development, I strongly recommend just focusing on using JavaScript in the frontend and backend. There’s no reason to split your brain in half between languages at this stage. And speaking from experience (I’m regularly working in a bunch of different languages, which can be a pain) no other language beats the flexibility or practicality of using a very modern non-compiled language that lets you write both front and backend.
Old man shakes fist at the cloud
To run JavaScript code outside of the browser, we use a program called “NodeJS”.
Hot Take: People put too much emphasis on NodeJS needlessly, as if it were some magical thing, but the truth is that every programming language has some tool to run its code.
For example, to run Python code, you type “python filename.py”, “python” being the tool which runs python files!
For Clojure programs you type “lein filename.clj”, “lein” being the tool that runs Clojure files.
For JavaScript you type “node filename.js”, and “node” will run your Javascript file.
NodeJS isn’t a “server” or a “framework” or whatever people are calling it these days, and it’s unfortunate that people call it that, because it confuses everyone about JavaScript. NodeJS is just a tool to run your JavaScript files, like any other programming language has. That’s the most helpful way of thinking about it in my opinion.
Part 3 — Let’s make a server program
Let’s make a server program in JavaScript first.
Check if your computer already has NodeJS installed, by opening up
“Git Bash” / “Command Prompt” on Windows or “Terminal” on Mac/Linux, and type “node -v”.
If you don’t see a node version number popping up, download and install NodeJS for you computer: https://nodejs.org/en/download/
If you save this JavaScript file as “index.js”…
You can then run it from your terminal (go to the correct folder with “cd” command first) with “node index.js”. Cool! You can now talk to that server program from any other program on your computer, like the browser for example. Go to http://localhost:8080/
In your browser, it should say “Hello, World!”
Congrats!
For fun, let’s make the same server in Python.
Let’s try the same thing in Python. There’s a good chance your computer has Python installed, but if “python -v” doesn’t give you a Python version number, download and install it from here: https://www.python.org/downloads/
The same simple server in Python, save it as index.py :
You can then run it from your terminal (go to the correct folder with “cd” command first) with “python index.py”. Now, if you go to http://localhost:8081/ you should see “Hello, World!”
Wow, that was quick! Now you’re a JavaScript and Python backend developer! There is no further “hidden knowledge”, no secret handshake… Just keep practising!
These servers could in theory serve files (html, png, css, etc.) or deliver data from a database, let users log in, log out, deliver a user’s calendar information, anything a server does.
Frameworks — for more structured APIs..
Typically, developers try to avoid “reinventing the wheel”. If you’re making 2–3 new products a year, or a month, then you don’t want to write everything from scratch. You’re going to waste lots of time and probably make lots of unnecessary mistakes if you write everything from nothing each time.
For people making APIs there are API frameworks! These API frameworks make it easy to create and manage lots of different API routes, handling errors, dealing with permissions etc.
ExpressJS is easily the most popular JavaScript API framework.
Your next task is to install express and make a simple API with it.
Please make an API with these routes and return values:
/ -> serves an index.html file
/about -> serves an about.html file
/users/1 -> sends back some JSON {“id”:1, “username”: “bob”}
Every other route -> “404 sorry this resource does not exist”
Google “how to install expressJS”, “expressJS example”, “express send JSON”, “express send HTML file”, or “express serve static” to start getting to grips with what it can do.
(If you’d like to do this framework step in Python, the simplest Python framework to use would be Flask. See how far you get!)
I’m not giving you the code for this final step with a framework intentionally.
If you haven’t heard this before, the reality of programming is spending 90% of your time googling keywords, finding and fixing weird bugs, or simply trying to get a clear picture of the task or problem at hand.
It’s not your job to memorise and write code all day, but to become an adaptable and resourceful person that can find useful answers and good solutions to problems.
Memorising everything perfectly about your preferred language / framework might come as a side-effect of experience, but I would never say it’s the goal.
So get to it! Start practising your problem solving skills, and make the router with 4 routes as described above, using expressJS (or Flask for Python). This will involve 99% googling for examples and trying to fix bugs!
This concludes the practical part of the article! Congrats.
Part 4 — Some final notes and pointers
Wow this has been a long guide. To avoid writing an infinitely long article, I’ll instead leave some final notes and pointers.
You don’t need to immediately read through this section, but if you’ve got the energy, go for it!
Try googling these phrases to build your overview of technology!
1. “HTTP status codes”
2. “Dynamic routing express”
3. “What are express sessions”
4. “Microservice architecture vs Monolith”
5. “How to use mongoDB with express”
6. “What is Postman”
7. “What is netlify”
8. “What is AWS S3”
Make a real app!
You’ve got the basic tools and knowledge to make a server, so keep going! As backend overlaps with other fields of programming, your choice on what to create is quite wide.
If you’re looking for ideas on what kind of backends you can build, here is a list of useful examples by Cory Althoff.
Pursue your own interests, think of the sort of projects that attracted you to backend in the first place, and don’t be afraid to experiment. If you’re feeling short of ideas, we recently published an article on where to go look for them.
Putting your server program on the internet
You’ll eventually want to put your server on the internet for other people and programs to communicate with (we call this “deploying”). I would recommend Heroku to start. Heroku is a “hosting” service for running applications on the internet. You can upload your server code and it can run there for free (We call this “hosting”. Heroku will “host” your program).
A “backend” app VS a regular app
Just because a program is not frontend doesn’t make it a server or backend.
“Backend” implies a relationship with a frontend that will consume data and talk to the backend. “Server” implies that you are delivering data to some other program.
You can just write programs that run, do calculations, transfer files around a computer, clean up the harddrive, that don’t have a frontend counterpart at all. Keep that in mind.
Not all APIs are URL-based
There are other types of APIs. For example, localStorage in the browser is an API built right into the browser that you can talk to with your javascript code. You don’t use a URL to talk to it, but it is still a service that you communicate with in a specific way. localStorage.setItem(“username”, “bob”) is asking the localStorage service of the browser to store some information. We would call this also an API.
Web developers, don’t forget about CORS!
It is common in modern web development to host your website(s) and server(s) separately, instead of serving the HTML files from the same server that handles data requests and database interactions. After all, the server might be serving data to a bunch of different apps. The server doesn’t necessarily have anything to do with your website specifically.
For browsers, servers normally enforce a security policy called Same Origin Policy. This means if you are trying to talk to a server’s API at http://localhost:8080 from your webpage which is on http://localhost:3000, then the server will probably reject any message that you send to it.
This Same Origin Policy is to protect consumers and companies against scammers, who could otherwise copy a bank’s HTML website files, put it on the internet on a different server, and then trick people into logging in to the bank’s real server from the fake website!
SOP means that the https://my-bank.com/login API route can only be spoken to from a HTML page that was also served from that same “origin”, from https://my-bank.com/ .This is a very good default behaviour I would say.
In order to let your website communicate, if it’s on a different server (aka origin) to your actual “backend server”, you need to enable CORS (Cross-Origin Resource Sharing) on your server so the website can talk to the backend API.
To solve this issue in Express, just add 2 lines!
This ends our dive into “backend”. I really hope it helped paint a picture in your mind, on where all the pieces go and what some of the different terms mean.
Have fun coding! Now read the article again!
If you enjoyed this article on backend development, check out our introduction to Data Science too, or take a look at our list of bootcamps!
