React with Express and Angular with NestJS
The most popular framework for Node.js is still Express.js. On the frontend side, there are three kings: Angular, React, and Vue. After adding the most popular NoSQL database, MongoDb, we get a combination of the most common stacks for JavaScript developers: MEAN, MERN, and MEVN.
We can find many similarities between React and Express. Both solutions are minimalistic, based on JavaScript, and provide only the most important functionalities in their main package. They offer great flexibility in the choice of tools and in the structuring of applications.
For Angular, the equivalent on the server-side is NestJS, whose creator was strongly inspired by the solutions from colleagues at Google while working on his project.
What Angular and Nest have in common and what also distinguishes them from the previous set is:
- Use of TypeScript as the main language
- Extensive use of decorators
- A module-based dependency injection system (with importing, exporting, and defining providers)
- Set of officially supported additional libraries
- Main library with lots of functionalities ready to use
- CLI
Each of these approaches has its pros and cons. The biggest mistake is mixing different philosophies in one technology set – while the elements of the MERN set fit together quite well, the same cannot be said for MEAN.
That’s why I want to propose a much better alternative: the NAN.
NAN
NAN is a combination of three technologies: NestJS, Angular, and Nx. The natural combination of NestJS and Angular was described above. Nx is a toolkit to help while working with monorepo, but it is also very useful for developing single, complex applications. For a full-stack developer, the ability to share code, tools, and a repository between backend and frontend is invaluable – Nx offers us that (and much more).
What’s more, in nrwl also the dependencies described above were noticed and the ability to create projects in Angular-Nest or React-Express set was added.
Relational databases have not disappeared
The last major difference between NAN and MEAN is the omission of a database. Including one in the new suite would be an unnecessary limitation. A good backend or fullstack developer should be familiar with both NoSQL and traditional (relational) databases. More importantly, he/she should be able to consciously choose the right database for the project requirements and his/her technology set should not be the discriminator here.
What I mean here is that any Node.js developer is certainly aware that NoSQL is not suitable for certain types of applicationsand should warn the client that another technology might work better here. Even if NoSQL is the only database technology you know of, its use in the project should be sensibly supported.
Summary
MEAN has gained incredible popularity, has a few variants, and has paved the path that many companies and developers have followed when choosing which technologies to specialize in. However, we currently have a worthy successor that those who appreciate the style of Angular and NestJS should definitely consider moving to. I believe that NAN will gain the same popularity as MEAN, make improvements and take its rightful place in the JavaScript community.
Leave a Reply