All you need to know about JavaScript on the server-side

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 a 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 interesting in reading the history of JavaScript and it’s 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 in JavaScript language.

How does JavaScript run on a server? To be able to run JavaScript code in 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 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 technologies

Victor Barzana, CEO @Codegenio Node.js Frameworks are now emerging as the most commonly used development environment for building Frontend and Backend for web applications. As JavaScript community grows, this language becomes crucial on both, 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:

Ease 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 nor 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 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.

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

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

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

There are plenty of JavaScript ORMs, you can see the most recommended for 2020 here. This is another topic that generates lot of discussion. From my personal experience, there is 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 is no performance issues so far, although I have to admit that I am scared about the future updates of the MongoDB Driver.

In 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 setup, super fast and elegant and is the preferred one by the community out there.

Application Performance Monitoring for Enterprise Applications

Source: https://docs.newrelic.com/docs/apm 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 trace-ability 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 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 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? JavaScript in the server-side is as powerful as any other programming language. By using JavaScript in the server and client-side your company will definitely save costs by avoiding hiring more people and instead focusing in good Full-Stack developers that know JavaScript. JavaScript is not Node.js. We have learned how to debug a Node.js application in the server side. Now you have an idea how monitor, and scale your JavaScript applications.