What needs to be considered when building backend with Node.js?
Let’s explore how to build backend system with Node.js. Before going deep dive on to the topic, I want to explain several important concepts so that we know the minimum amount of the terminologies/concepts when building the backend system.
What is REST API?
Baiscally we can say it is REST + API. The REST is Representational State Transfer and it is one of the types of software architectures for hyper media systems. The architecture refers to transferring the resource of the web via HTTP without complicated transfer layers. API is an application programming interface and is a set of subroutine definitions, protocols, and tools for building application software. It is a set of clearly defined methods of communication between various software components.
REST architecture style?
1. Client-server
Separating client from server, client-side can stay away from managing data savings ultimately making client-side more available and server becoming more scalable
2. stateless
Client request is stateless meaning the request itself is not dependent on previous or upcoming requests. The request contains all the info required so good for re-requesting when failed and scaling
3. cache
Caching needs to be there. We can use Last-modified or E-tag to use caching
4. uniform interface
need to use URI to select the resource with certain interface
5. layered system
REST server can have multiple layers: security, load balancing, and encryption layers to have lenient structure and PROXY & Gateway as middlewares
Glory of REST
Above is Richardson Maturity Model by Martin Fowler and shows, the steps towards more completed REST system. Basically, as you go up to level 3, the system become more RESTful. Now let’s briefly walk up to steps.
Level0
End-point itself refers to a single service. It does not use web mechanisms but using HTTP as just mere remote communication transfer system similar to RPC (Remote Procedure Invocation). In simple words, client can call methods defined in server and vice versa. This helps hiding detailed information as much as possible when communicating with servers.
Level1
Instead of communicating with a single service, all the requests communicate with each resource. This resource needs to be directed with URI making client-side to see how the requests are formed easily with relevant ones.
Level2
The HTTP verbs include: POST, GET, PUT, DELETE and with these actions available, same URI can have different meanings making the URI 2-dimensional.
Level3
We can think Hypermedia Links as HATEOAS. It means that controlling the client’s state with links. Client’s state is represented with the URI and a changing of the state is represented from the response of server is HATEOAS. I can explain the difference between level 2 and level 3 with REST API example. Let’s say we are calling the api of getting all the users with get request & uri of /users. From level2, we will get all the ids of the users and in order to see the detail information of each user, we can just call /users/${user_id}. But this is mere assumption from us. We need to be making sure that this kind of URI exists and this is what HATEOAS does for us with Link. When we are requesting with GET request, in response, HATEOAS returns something like below:
Because, we are certain that we will get the detailed information of a product with request /product/1.
Authentication!
Basic CRUD can be done but in order to have a complete system, we need to look at how to authenticate requests. In simple words, when user logs into the service, client will send a request of the user’s userID and password. But carrying this password explicitly, the request can reveal this important information when attackers highjack the request. Therefore, we need a session-based authentication.
HTTP is stateless protocol and does not save any information. In the HTTP request, there should exist a session ID which is a key and will be mapped to a value(user information) in in-memory database such as Redis. Let’s explore the picture above. Server, upon receiving the request from client, needs to save the user’s information, therefore creates a session and in the session, there is a session ID which will be returned to both database(redis) and client(cookie). In this case, once the user is authenticated, next time he/she wants to login, can use the cookie from client side to authenticate and do not need to login again.
Problems?
Of course, problem exists! Session is using server memory and needs to consider scaling. Also, when there is an error in server side, all the information about session is lost.
Solutions?
Session clusters: all the servers are sharing sessions. Similar to above exapmle, we can use In-Memory distribution database such as Redis and this enables to get session from other working servers when one server is down. We are free from sticky sessions by doing this. However, this also can be problem if Redis-server is down so need to consider replicates of this redis server. (The pain of CS!)
Passport?
Passport is a middleware that we can use in nodejs in authentication. This middleware authenticates whether a client is valid to send a request to a server. Using this middleware, we can easily verify if some requests are valid to the server.
Conclusion
Now, we have seen REST API concepts with session. Lastly, briefly, went over passport module to see how to go for the backend with nodejs using javascript. Hope this article helps everyone and if have any comments, please comment on the articles for the fruitful discussion!
