JavaScript on the server side “to be or not to be”

The present article attempts to explain the key benefits of using JavaScript programming language for building large-scale web applications on the server side. Will also cover how to improve efficiency, performance, and simplicity while using JS, as well as debugging and having strict control of which processes run in your production environment and how to monitor your server’s health. We will also mention what are the most popular JavaScript Frameworks on the server side.

JavaScript in a nutshell

JavaScript is a scripting or programming language that allows you to implement complex features on web pages — every time a web page does more than just sit there and display static information for you to look at — displaying timely content updates, interactive maps, animated 2D/3D graphics, scrolling video jukeboxes, etc. — you can bet that JavaScript is probably involved. It is the third layer of the layer cake of standard web technologies, two of which (HTML and CSS) we have covered in much more detail in other parts of the Learning Area.

Source: Mozzilla Developers

If you are interested in reading the history of JavaScript and its standardization by ECMA, you may want to read this great article from Auth0.

What is JavaScript on the server side?

Server-side JavaScript (SSJS) refers to having your entire application in the server implemented with JavaScript language, which is therefore not downloaded/executed in the browser. The first implementation of SSJS was Netscape’s LiveWire, which was included in their Enterprise Server 2.0 back in 1996. Since then, a number of other companies have followed them by offering an alternative to the usual server-side technologies based on JavaScript language.

How does JavaScript run on a server?

To be able to run JavaScript code on the server side, it is required to use a JavaScript Engine, which consists in a computer program that executes JavaScript code. The first JavaScript engines were mere interpreters, but all relevant modern engines utilize just-in-time compilation for improved performance.

The most common JavaScript engines are:

• V8 (Node.js, ArangoDB)
• Rhino (Apache Sling, Alfresco, Eclipse e4, JSSP)
• WebKit JavaScriptCore
• SpiderMonkey (MongoDB, CouchDB, Aptana Jaxer)

JavaScript is NOT Node.js

For newbies, with this question, the answer is NO. As we previously read, JavaScript is a programming language that runs in any browser, but on the other hand, Node.js is an interpreter of JavaScript. So, in other words, Node.js is:

• 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
• not a programming language, but uses JavaScript on the server-side

At tourware we build most of our software applications with Node.js on the server side. Based on the concept, of 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 technologies

Victor Barzana, CTO @tourware

Node.js Frameworks are now emerging as the most commonly used development environment for building Frontend and Backend for web applications. As the JavaScript community grows, this language becomes crucial on both, the client and server side, more and more developers have the necessity to implement/look for standard frameworks that encapsulate all features that are required for developing a complete application. Even though the competition is tough, here the winners are the ones that allow you to do more with less code, however, won’t mention any name because this could create conflicts.

Picking the right Node.js Framework is quite complex, some of the things we keep in mind always is:

• Easy to use
• Maintainability and long-term support
• License and costs
• Framework features
• Database ORMs
• Performance
• Environment support
• TypeScript support
• Clear folder structure
• CLI support
• Community size
• Hosting
• Healthy and up-to-date documentation
• Real-time working environment
• Simple coding experience
• Seamless data streaming
• Same code pattern throughout development
• User-friendly

I could keep talking about features for a couple of pages, however, the truth is that there is not a perfect choice, especially because among the community everybody pulls to their own side, while it would be better to have the majority the effort and focus spent in only one powerful JavaScript framework.

Please keep in mind that the intention of this article is not to compare or criticize already existing frameworks. And my apologies if your framework is not mentioned in the list below. Currently, the most well-known JavaScript frameworks on the server side are:

Express

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

Sails.js is a lightweight framework that sits on top of Express. Its ensemble of small modules works 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. On 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 that the community is open source and it could stop being supported one day in the future. The biggest con, it does not include TypeScript support yet.

Nest.js

Nest (NestJS) is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with and fully supports TypeScript (yet still enables developers to code in pure JavaScript), and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).

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 tourware we are considering moving from Sails.js to the NestJS framework because of 3 main reasons:

• Has a bigger community
• Full TypeScript support
• Has more maintainability

Hapi.js

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.
This framework is also used by Brendan Eich, the JavaScript Father, and by Auth0 in some internal applications, maybe that’s why it got famous. However, I think NestJS comes very strong and is their biggest competitor.

Fastify

An efficient server implies a lower cost of the infrastructure, 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 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.

Source: https://www.fastify.io/

My own preferences?

So, my personal opinion is that we will choose Nest.js for future project 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

There are plenty of JavaScript ORMs, you can see the most recommended for 2020 here. This is another topic that generates a lot of discussion. From my personal experience, there are so many people that hate Waterline, however, we have had it running in Production with a clustered MongoDB database and a Stateless Sails application and it has been very stable. At this point, our client’s database has grown to millions of records and there are no performance issues so far, although I have to admit that I am scared about the future updates of the MongoDB Driver.

On the other hand, I am pushing my Team to move to TypeORM which is an ORM that can run in NodeJS, Browser, Cordova, PhoneGap, Ionic, React Native, NativeScript, Expo, and Electron platforms and can be used with TypeScript and JavaScript (ES5, ES6, ES7, ES8). Its goal is to always support the latest JavaScript features and provide additional features that help you to develop any kind of application that uses databases — from small applications with a few tables to large-scale enterprise applications with multiple databases.

TypeORM goes with the flow, is easy to set up, super fast and elegant, and is the preferred one by the community out there.

Application Performance Monitoring for Enterprise Applications

Node.js is broadly supported by APM solutions such as New Relic, Datadog, or Elastic APM. So you can run enterprise applications at scale with full traceability and real-time monitoring capabilities.

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 the 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.

If you still prefer the no IDE way, then you can do it using Google Crome Dev Tools to debug your JavaScript app, just follow these instructions from the Node.js docs: https://nodejs.org/en/docs/guides/debugging-getting-started/

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 you to read my post about how to scale your app with Sails and Heroku.

What do I take home?

• JavaScript on the server side is as powerful as any other programming language.
• By using JavaScript on the server and client side your company will definitely save costs by avoiding hiring more people and instead focusing on good Full-Stack developers that know JavaScript.
• JavaScript is not Node.js.
• We have learned how to debug a Node.js application on the server side.
• Now you have an idea of how to monitor and scale your JavaScript applications.