The story of a backend — the beginning
Now it’s good to learn from a bootcamp how a REST based backend is created but they generally are not that big that they care much about the developer’s delight. And hence is the purpose of this blog.. To show some snippets and things I learned from experience developing some decently complex backends.
How To Backend →
Let’s discuss for a while about how to approach a frontend creation and about what is REST API, and also why it makes more sense. Now this is just my thinking process and I don’t claim it is flawless but it works for me.
The first step to any kind of development is to understand the problem statement. This infact is the most crucial task. Understanding the requirements well can make your life easier or it can make you cry over your keyboard while you try to figure out what exactly you want the behavior to be(I learned it from a number of bad experiences so learn from my mistakes people.. be absolutely clear about what needs to be done). Ask questions that make your game plan clearer. And not just to the clients but yourself too.. as in if the client tells you their application needs to collect data from the user, you should ask yourself what is the best way you know to do that securely and efficiently and try to get more information as to what data is being collected and how frequently will that be accessed or how much data is targeted to be collected. Now this may seem very simple and “common sense” things, but in reality it can change the database you use or the way you handle the data.
Now that you have your problem statement clear, lets talk about REST
Long long ago in a community called developer, used to create web applications that were so to say, ‘monolithic’ because they used to tell the application what to do in a single big file .. (imagine the horror to debug a system like that). Then came along some smart people who were like why do we need to do it like that, we can break it into small services that can be served at different endpoints, and hence from the ashes was born the concept of micro services.
Anyway, so the REST APIs help developers to create a more manageable code base where you can provide applications data for particular requests. Let me elaborate on that ..
Let’s take an example of a basic e-commerce web application. Now we want to let’s say, log a user in. Now to do that we can send the form data(form == the login form) to an endpoint where we have our function(I like to call it handler because it handles stuff) mapped to that endpoint(or link) and it extracts the form data and makes a query to the database to check existence and validity of the user. If the user is present, it will tell the application the login was a success and can be proceeded. If it fails, it can send the app an error message and even a code with a message that can be used to tell the user that the information entered is wrong. Now since this is done by mapping a function to an end point, we can group such functions that have something to do with user into one place and it will be more manageable now.
I will be showing how that looks in a bit too. The REST APIs have something called a verb, which tells the type of request it is to expect. Get and Post are the most common and you can think of get-requests as to aim to get some information form the backend(like a list of products for an e-commerce web app). A post request is sent when you want to send the data to backend (for example in the previous example, the sign-in/login will be a post request as we want to send form data back to backend for checking validity of the user and without revealing the information user entered in the form). Other interesting verbs are put, delete, patch … etc. You can read more about the types and what verbs are there, if curious, but get, post, delete, patch, put is the most common ones as far as I have experienced(most of the time in that order).
In this post, I would use SQL as database of choice because, mongoDB tutorials are too common and sometimes relational databases are more efficient than non-relational ones. Now the choice of database is a very important decision as you need the most efficiency to store and retrieve data. I can link a nice video about the battle of the backend for reference to when to use which database. You can actually use both types together too. (check this out→ https://www.youtube.com/watch?v=rRoy6I4gKWU) 🤔maybe in future I will write another blog about databases too.
Here is a link to download and install node. Also add it to path so as to use it from cmd/terminal anywhere.
link to node → https://nodejs.org/en/download/
check if the installation was successful.. run
node — — version if it shows a version, congratulations node has been installed and now we can begin with the development.
We will use node package manager to install modules to develop the backend and I’ll explain and show along the way how it can be organized and modularized.
Starting the development process →
We will use npm to install packages for creating a backend server.. the express JS module.
We will use VSCode for the sake of ease and elegance but you may choose your favorite editor to continue. So create a folder for the project, and open it in your editor. To begin with the development, run
npm init and answer the information asked(or just press enter a bunch of time to keep all defaults). This will create a bunch of files to get you ready for a node project.
npm install -g express --save to install the module. Now this is the standard way to install packages. We are going to install a lot of packages throughout the blog so you will be needing this quite a bit. Once the packages are installed, and you upload it to git, (you’d need to add the node_modules folder to gitignore because it would be gigantic to upload to git). When you pull the project again in a new machine, you can just run
npm install to install all the packages.
Now that we have a project ready, we need to create a server.js file for writing the logic for our server. When starting the server, we will run this file to start the server at a specified port(will explain it during the code explanation part)
This is getting a bit too long so not to put in too much knowledge in one blog, I will end this blog at this point where you have a backend project ready to work on. Just one more thing before I go, let’s setup just a few more things to make it easier to “start” the backend:
Before we do that, let’s install one more useful package
npm install -g nodemon` nodemon is a package used to run the server with a bit more verbose output(running node server.js will not output any thing). We will use nodemon to start our server.
If till now, everything was okay, you should be able to see a package.json file. Click on that and you will see a bunch of configurations like the project name version, description etc.
Scroll down to find the ‘scripts’ section.. and add another command “start” like so →
“start”: “nodemon — watch backend — exec node — experimental-modules backend/server.js”,
Now what that does is it allows you to just run
npm start to start you application.
Now that we have a nice setup, in the next part, we will see how to start coding and then how to make code more manageable. And also how to use SQL with node.
Stay tuned to know what happens next!!