- V8 (Node.js, ArangoDB)
- Rhino (Apache Sling, Alfresco, Eclipse e4, JSSP)
- SpiderMonkey (MongoDB, CouchDB, Aptana Jaxer)
- an open source server environment
- free and runs on various platforms (Windows, Linux, Unix, Mac OS X, etc.)
- not a framework
- not a package manager
At Codegenio we build most of our software applications with Node.js in the server-side. Based on the concept, re-usability at first, we always end up copying some piece of code we already did. Therefore, having a Node.js framework is crucial to gain speed of development and standardization among our products.
How to pick a Node.js Framework?
Go with the flow, it’s the only way to survive to so many emerging technologiesVictor Barzana, CEO @Codegenio
Picking the right Node.js Framework is quite complex, some of the things we keep in mind always is:
- Ease to use
- Maintainability and long term support
- License and costs
- Framework features
- Database ORMs
- Environment support
- TypeScript support
- Clear folder structure
- CLI support
- Community size
- Healthy and up to date documentation
- Real-time working environment
- Simple coding experience
- Seamless data streaming
- Same code pattern throughout development
Express is a fast, minimalist framework of Node.js. It provides a light coating of necessary web application features, without obscuring Node.js features. Furthermore, it’s easy to build powerful Web Services with the help of various HTTP utility methods & middleware available. In other words, if your app is very small, I would definitely consider using Express.
Sails.js is a lightweight framework that sits on top of Express. Its ensemble of small modules work together to provide simplicity, maintainability, and structural conventions to Node.js apps. IMHO I use Sails.js for years in heavy load production environments, clouds and other SaaS applications and I have never had issues with it. The most important thing to keep in mind with this framework is to never do nested saves, avoid populating too much data, don’t mess too much with the blueprints. In the other hand I love the API simplicity, with the passport integration you can build an OAuth or JWT integration in a matter of minutes, and you can build really huge applications with it. The biggest cons I find to Sails is that the Waterline ORM does not have so much maintenance and that the community is open source and it could stop being supported one day in the future. Biggest cons, it does not include TypeScript support yet.
Under the hood, Nest makes use of robust HTTP Server frameworks like Express (the default) and optionally can be configured to use Fastify as well!
At Codegenio we are considering to move from Sails.js to NestJS framework because of 3 main reasons:
- Has a bigger community
- Full TypeScript support
- Has more maintainability
Every hapi feature is designed to make the platform easier and more intuitive to use. That means there’s no need to hack things together, experiment to see what *might* work, or try to figure out hidden internals. There is no “magic” – the code does what you expect with easy to follow internal logic.
An efficient server implies a lower cost of the infrastructure, a better responsiveness under load and happy users. How can you efficiently handle the resources of your server, knowing that you are serving the highest number of requests as possible, without sacrificing security validations and handy development?
Enter Fastify. Fastify is a web framework highly focused on providing the best developer experience with the least overhead and a powerful plugin architecture. It is inspired by Hapi and Express and as far as we know, it is one of the fastest web frameworks in town.
My own preferences?
So, my personal opinion is that we will choose Nest.js for future projects development and if you want to know more reasons, please check out this article: Why I choose NestJS over other Node JS frameworks from Mr. Rahman in Medium.
Is up to you whether you want to use a JS ORM or not but I recommend it
TypeORM goes with the flow, is easy to setup, super fast and elegant and is the preferred one by the community out there.
Application Performance Monitoring for Enterprise Applications
For newbies in the topic, APM allows you to monitor in real-time the performance of your applications down to fine grained statements execution. Low level components such as HTTP clients and database connections are transparently instrumented to publish real-time execution tracing metadata (response times, logs, etc…).
By using any of the described APM solutions, we can also benefit from distributed tracing, a characteristic that allows us to trace our program flows over the network of services.
Debugging is key in Node.js
As a Software Engineer/Developer YOU HAVE TO KNOW HOW TO DEBUG your code. Debugging is the routine process of locating and removing computer program bugs, errors or abnormalities, which is methodically handled by software programmers via debugging tools.
There are plenty of ways to debug a Node.js App, however, every developer has a preferred way to debug. For example, I personally like debugging my app with Jetbrains WebStorm which is pretty straightforward, see below screenshot:
However, if you don’t have an IDE like WebStorm, but you have Visual Studio Code, please see Debugging in Visual Studio Code.
Scaling your Node.js App
Building an application should be planned from the beginning as if you were building a new bridge or a skyscraper. It requires a very carefully planned project using a clear Software Architecture from the beginning. You must foresee your app and think about all possible scenarios ahead of time. However, you have to be careful don’t over-complicate your architecture if it is not needed, for example, all apps don’t need a Microservices based architecture, because it would become costly and extremely big for no reason.
When scaling an app there are a few things you want to take into consideration:
- Where are images and videos stored?
- How many read/write requests are received per second? Per minute?
- What is the level of security required?
- Are these synchronous or asynchronous requests?
- Will you support WebSockets?
- How is the website handling sessions?
IMHO there is one word that will answer all those questions “statelessness”. If you guarantee that your application is stateless or respects the stateless principle, you can ensure that it can be scaled in any kind of workload/processes diversity and you can run even Facebook on it. The below screenshot shows how Heroku handles the scalability of the same application in multiple Dynos by separating it into different process types or small sub-applications.
This topic is rather complex and long, so, I recommend that if you wish to keep reading about how to scale your app with Sails and Heroku, please visit my previous post in our blog. https://codegenio.com/guide-to-scale-a-sails-node-js-app-with-heroku/
What do I take home?
- We have learned how to debug a Node.js application in the server side.
Thank you so much for stepping by, we are looking forward to hearing your comments about the article.