Node.js Developers: Points To Remember When Going To Start Working on Any Back-end Development Project

On Friday, Oct 18, 2019, I got a query, about how to start a node.js project or any back-end project, how to approach it and mid-set needed. It's a very interesting question.

For the last 8 years, I have been not only working as a back-end developer but worked in front-end projects as well and also handled Cloud Services (i.e., as a full stack developer), I think I would be a perfect person to answer this.

These are the points to remember when going to start working on Node.js / Back-end projects in general:

1) What are the requirements?:

Yes, requirement specifications are the most important part before starting any project. Sync up with Client for requirements, not just hear the requirements, write it down, after summarizing it, send it to the client for confirmation. After the client confirms requirements and everyone agrees on, lock in the requirements and any further addition would be acknowledged as an additional feature (This is to avoid infinite and ever-changing requirements issue).

If you are using any project management tools like JIRA, Asana, Teamwork etc, start dividing the tasks into smaller pieces, that will help things done more smarter and faster way.

2) Decide Application architecture & third party requirements:

After requirements and all other inputs gathered, time to decide on the application architecture.

Here when doing back-end application development, the application architecture is the client-server architecture model. It could be: 2-tier, 3-tier, n-tier, let me discuss a bit more about it:

2-tier Architecture:

It is like Client-Server architecture, where communication takes place between client and server.

In this type of software architecture, the presentation layer or user interface layer runs on the client-side while the dataset layer gets executed and stored on the server-side.

There is no Business logic layer or immediate layer in between client and server.

3-Tier Architecture:

In the case of a three-tier architecture, the tiers are as follows:

Presentation tier (also known as the user interface or the client application)

Business logic tier (also known as the application server)

Data storage tier (also known as the database server)

This architecture most commonly getting used.

A Typical Example could be:

Presentation tier running Angular.js or React.js or Vue.js application or simple Vanilla JS client application.

The business logic tier you are running application server using Node.js or Nginx Server any kind of back-end server

Data-tier you are running MongoDB or MySql in another server (typically for MongoDb you might be running on MongoDB Atlas or if using AWS then AWS DocumentDB and if it's MySql and using AWS then AWS RDS ).

n-Tier Architecture:

This definition from Wikipedia explained it well:

"In software engineering, multitier architecture (often referred to as n-tier architecture) or multilayered architecture is a client-server architecture in which presentation, application processing, and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.

N-tier application architecture provides a model by which developers can create flexible and reusable applications. By segregating an application into tiers, developers acquire the option of modifying or adding a specific layer, instead of reworking the entire application. A three-tier architecture is typically composed of a presentation tier, a domain logic tier, and a data storage tier."

You can achieve true flexibility and scalability in n-Tier Architecture only. Typically when you are developing a back-end application, you have to decide how many tiers you need and what kind of DB you will need considering your database requirements e.g. based on if the data going to be relational data or non-relational data or graph data etc, what programming language you will need to interact with the DB.

Third-party Requirements:

It's very important, as this determines the cost factor, "re-inventing the wheel" or "not using a better third-party option which cost less" is not a wise option. So if something crucial solution already available at a cheaper cost and better functionality, it's better to use that third-party solution.

To run the back-end application you will need a physical server instance. For this obviously you can use your own machine, that will be ok for development but "not ok" for production. As the user will be continuously interacting with your application and it needs to be "Scaleable", "Highly Available" and "Fault-Tolerant" which only can be achieved by running on Public Cloud Service provider platforms e.g. Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Digital Ocean etc. There you can start a server instance and run the applications. and for Database services for production, it might be better to use managed Database Services to avoid own database management overhead and cost, all cloud service providers have managed database service options.

It's also very important to know about Server Less technologies, where you don't have to manage servers by yourself, instead, you can use your logic as functions, you can still use any programming languages like JavaScript (Node.js), PHP, Python, Go etc to program the functions.

Popular serverless solutions are:

AWS: AWS Lambda

Google Cloud: Cloud Functions, App Engine, Cloud Run

Microsoft Azure: Aure Functions

3) Always start with version 1:

If you think you can build all beck-end functionalities al at once, then you are going the wrong way.

Think & build the basic/necessary functionality first, use API versioning, make initial features as the version one so be it front-end applications or apps (if any) can also start functionality integration, that will save time, in this way suppose you are improving existing functionalities and don't want to affect existing implementations, then you can treat them as version 2 APIs and so on, once they are done and tested, you can utilize new APIs in front-end applications or mobile apps.

4) Think of MVP:

MVP stands for a Minimum Viable Product i.e.

"A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product's initial users.

This concept has been popularized by Eric Ries, a consultant, and writer on startups."

-- This definition from Techopedia is simple and easy to understand

Don't confuse MVP with version 1 concept, it can require multiple version to achieve a proper MVP but having MVP is highly desirable, I see 80% failure happens where there is no plan for MVP and client want all at once and finally at the end with infinite requests it's become so late. So build MVP early, then consider the feedback and improve functionalities.

5) Write Test Cases From The Beginning:

Once you write APIs, it's also good practice that after completing the API, write required test cases for that API, it has long-lasting benefits, better code quality, and test coverage.

6) Node.js Special Points:

Now if you have already decided to develop back-end on Node.js, I would suggest to focus on security from the beginning, follow best practices, use ES Lint plugin with Airbnb preset to maintain code consistency and code quality. Consider reading my last Node.js related article where I have explained about all this in greater details: Modern Web Development Using Node.js

7) Consider using Docker To Containize The Application:

When you are working in a Team and different people working on different OS, there might be issues while development that project running in your computer fine but not on other people's computers, to eliminate this issue completely Docker is the best option available right now, but not just that, you can achieve greater level of scalability when you containerize the application in Docker image and use it in Docker Swarm or Kubernetes.

I had made Videos on why developers should use Docker and How can you containerize your project:

If you like the above videos, consider subscribing to my YouTube Channel here.

And subscribe to the mailing list here: https://mailchi.mp/025b8325ea8b/learn-with-sandip if you like to receive notification mail when I release any new article or video.

Above are the points came in my mind, but search out google, you will get a lot more articles on this. My words are not ultimate, it's my thoughts based on my past experience. If you are an experienced developer reading this post then comment your thoughts on this so others can also get benefited, life is too short to make all the mistakes by yourself and learn it. Yes try something new, do mistakes, all fine but try to learn from other's mistakes and their experiences and so that you can gather more knowledge, be sure to not do the mistake as the other person did.

If you like this post, then do Like, Share and comment on what you think, follow me to get useful future articles/video's that I post.

About the Author:

Sandip Das is a tech start-up adviser, mentor to young development professionals as well as working for multiple international  IT firms, tech-entrepreneurs as Individual IT consultant / Sr. Web Application Developer/ Cloud Solution Architect / JavaScript Architect, worked as a team member, helped in the development and in making IT decision. His desire is to help both the tech-entrepreneurs & team to help build awesome web-based products, make the team more knowledgeable, add new Ideas to give WOW expression in the product.

More on Sandip here at LinkedIn?