Considering Node.js for Your Next App

Alan Charles
Hat Factory
Published in
3 min readOct 11, 2018

We have recently launched an internal development team here at Hat Factory and we couldn’t be more excited about it. As is the case with all new development teams, building the first project is as much about writing the code as it is about making DevOps and technology stack decisions.

We decided to use Expo, a React-Native framework, for frontend development, and Node.js for backend development. This article is not going to focus on the frontend, but if you’re interested you can read about the decision-making process here.

Why Node.js?

It should be noted that this article is not intended to promote Node.js or to diminish the value of other backend languages. Rather, it is intended to show why, in this particular use-case, we decided Node.js was the way to go.

As is the case with most startups, our development team is quite small. Our developers often have to work in both the frontend and backend, as well as handle DevOps. It can be a lot to keep track of, so a full technology stack in one language has obvious advantages. However, if trying to accomplish this would negatively impact user-experience in any way, the advantages gained by our developers could come at the cost of users.

This leads us to our main concerns, scalability, and speed. Chances are, these are your main concerns as well. No one wants to fight with a language as an app grows in both users and capability. Our current project includes messaging, calendars, tasks, and photo board features, all of which require backend storage, but more importantly, fast response times from the server.

Ruby is undoubtedly better at handling relational databases out of the box. However, it’s relatively straightforward to add Express and Knex to your project, both of which provide a great workaround for dealing with relational databases in Node.js. On top of that, Node.js actually facilitates real-time, two-way connections between the client and the server, making it possible for data to flow freely. Its event-driven architecture is perfect for apps, especially apps that use messaging features and rest services.

There are a few other advantages of Node. While these weren’t the deciding factors, they are worth noting. These include more powerful underlying libraries, better documentation, easy deployment, and faster page loads.

Node.js has come along way in just a few years. One of the longest standing complaints about it was that constant updates were often incompatible with old versions. This forced developers to babysit their code and made large codebases hard to maintain. Since V 2.0 was released, this problem has almost disappeared.

Who’s Using it?

So, with our outdated fears abided, we decided to see if anyone else was using Node.js. Our biggest concern was scalability, so the larger the company the better. It turns out, huge companies are using it, including Netflix, Uber, and PayPal.

LinkedIn even converted their backend from Rails to Node.js. You can read about it here.

Conclusion

Every app is different. Choosing Node.js for our current project was a carefully thought out choice. If it fits your use-case it can make the development process easier. However, if your next project has a lot of processor intensive tasks, I would strongly recommend checking out Rails. We’re excited about its potential and hope that as it becomes more popular new capabilities are added. Until then, we’ll keep writing as much JavaScript as we can.

TL;DR

Choosing a backend is use-case dependentNode.js is a great way to integrate your frontend developers into your backend teamNode.js has come a long way in stability and usability in the last five yearsHuge companies have taken to using Node.js for their backendIt’s great for apps, especially messaging appsIt’s way faster than RailsWe love JavascriptNode.js is the best choice for our use-case

--

--