In the last couple of years, I have used NestJS really extensively for both clients and my own projects. All the backend parts were built using NestJS only, in a combination with TypeORM for dealing with PostgreSQL database.
For frontend, I used to exchange between Angular and React, I liked Angular more since it inspire NestJS in the first place, and I don’t feel I’m developing in whole different technology like what I feel while using React.
Most of the time I chose React is just 2 main reasons: Client request or Fast delivery. Unfortunately, this comes with a price: Delivery rate
Building a separated backend and frontend has a lot of advantages like:
1. Separation:
By separating the backend from frontend, you’ll be able to have different teams working on their preferred field which will let the dev team to be as innovative as possible. The same point is a bottleneck as we will see next.
2. Deployment:
By deploying the 2 parts in isolated environment, you’ll make sure that there will be some sort of security by not letting anyone call the backend except the allowed frontend server.
3. Scalability:
In the separation approach, it’ll be very easy for the team to scale the part that need to be scale, for example if your frontend server is able to handle the traffic, but your backend server is getting overload, you can just scale the one who needs to.
Actually, all of these advantage can easily turn into bottlenecks for any company, especially small and medium ones, let’s find out.
1. Separation: Need more resources
To be able to deliver faster, more reliable solutions, you need more efficient developers in your team. If you said that you’ll hire a full stack developer, that will not fix the problem, simply because it’s not possible to find a full stack developer who has 50/50 experience in both sides and can do them both in the same efficiency.
2. Deployment And Scalability: Higher costs to keep them running
Your growing app will need more resources each time, and keep scaling your separated apps comes with a huge pain in both technical and financial side, especially if you’re deploying on the cloud.
Even that we knew all of these issues, we went with a separated backend/frontend, believing that we will grow the team fast, and we’ll have the required resources to handle that, but the opposite happened, I ended up doing the whole coding and managing the deployment.
Moving between 2 separated projects is really intimidating, and honestly, it made me lost especially when using React. And because of that, I was obliged to find a solution.
In the last 5 years and a half, I used Typescript as my main programming language, I got used to it syntax and felt comfortable dealing with its bugs, so I was looking for a solution that helps me deliver faster than the stack I was using.
I missed the days of Django and CakePHP, while we were building the full application in a single codebase and deliver to the world, and for that I tried NestJS MVC approach with Handlebars engine.
After a while of ticking with it, I felt that NestJS is not really made to do this, it was designed to build backends only, not a full stack app.
I wanted to use Django or Ruby on Rails, but I had an issue, re-learning Django or learning Ruby on Rails from scratch will be a time-consuming road, and I don’t really have time.
At the end, I have discovered AdonisJS, which has been built to be Ruby on Rails but for Javascript/Typescript developers.
After few tries, building some small projects, I decided to migrate all the current project from the NestJS/React stack to AdonisJS(migrating the projects who are not fully built yet).
Does that mean we’ll not use NestJS and React to build applications with? The clear answer is: No, we will use them when there is a real need but this stack will not be our main stack that we use by default.