NodeJS Serverless: A New Way to Build

We're living in a time where building and deploying apps feels incredibly different, and for the better. Gone are the days of wrestling with servers, and in their place, we have serverless. For us JavaScript developers, this means NodeJS is in the spotlight. This article is all about that; how we can use NodeJS to create serverless applications, what the advantages are and how it really changes the game.

What is Serverless, Anyway? And why use NodeJS?

Serverless doesn't really mean "no servers". It's more like not worrying about them. When we build an application in a traditional way, we have to think about the server where our code will run. We have to get it up and running, keep it running, figure out how to handle load, and probably wake up in the middle of the night because something doesn't work. Serverless lets someone else worry about that. We just write the code which actually handles the data. It is someone else's problem to run it, scale it and monitor it all. It lets us focus on what matters as developers: building the actual application. We can just deploy small pieces of code, each dealing with one task. These little pieces of code are called functions.

Why NodeJS though? Well, if you have been working with any kind of web technology, there is a very good chance that you know and love JavaScript. NodeJS, as a JavaScript runtime, allows us to write server-side code using the same language we use on the front end. This means no more switching between languages or having to learn new technologies to build back end stuff. It brings efficiency to the development process. Beyond this, NodeJS is known for being very fast and works well with event-driven architectures, which is perfect for how serverless functions work.

How Does it Work?

The serverless world is very event driven. Think of it as someone watching and waiting for something to happen. When that something does happen, a tiny piece of code, one of our functions, executes just to take care of what needs to be done. This could be a user submitting a form on a web page, uploading an image, or getting a signal from another service.

What happens behind the scenes is that someone provides you, the developer, with the service where you can deploy your NodeJS code. And that provider takes care of running that code when the event happens. All that we need to do is write our little function, deploy it by uploading a zip file some times or by using some cli, and it is then ready.

These functions are typically small, focused, and isolated. That helps a lot. When one fails, it won't affect another. It also simplifies testing and scaling. For example, we could write a function for uploading images to a storage service, which is then used by our website. And that piece of code only takes care of just uploading the images. Another function could then handle resizing them. This split simplifies the overall application.

The Benefits of Serverless Using NodeJS

There are lots of reasons why going the serverless route with NodeJS is beneficial. First, there is the cost aspect. Our code only runs when it's needed and we are charged just for that. If nobody accesses the application for a period of time, we are not being charged for server’s idle time. This is known as pay-as-you-go. It is also known as a resource saving.

Second, scaling becomes a non-issue. You do not need to be monitoring and fixing servers. Your serverless functions will scale automatically to accommodate requests. If you get ten users one day and a thousand the next, these function will work very well in both cases. Again we don’t have to worry about infrastructure and scaling. The provider takes care of that.

Third, deployment is much easier and faster. We do not need to be a server guru. We can build an application, and deploy the set of functions rapidly. We can roll out changes and test them quickly. This means less time deploying and more time coding.

Finally, this approach allows us, developers, to focus solely on writing code. Instead of concerning ourselves with servers, networks, and load balancing, we can focus on the application logic. This results in a more pleasant, and creative, working experience.

Some Things to Consider

While there are lots of good things about serverless, there are things to consider as well. One thing is the "cold start". When a function hasn't been used for a while, it can take some time to start up. The first request can feel slow. This effect is reduced or completely avoided by keeping the function warm. This effect has also reduced lately with improvements by the serverless providers.

Then, there is the issue of debugging. Because the code runs in an environment controlled by the provider, local debugging can require some special tools. Some providers allow tools for local execution, which can help with this. It is not as easy as debugging a normal node ./index.js process.

There are also the matters of vendor lock in. Once you choose a specific service provider, migrating to another service can take time. It is important to think this through. Some frameworks and tools can mitigate this.

Another thing to consider is how the serverless functions may interact with a database. Because the functions run for a short time, and also may scale up fast, connection pooling and limiting the database consumption becomes important. Using a well setup pooling library is a good idea