Node JS for Back End Development

If you’ve read through some of my content, spoken to myself about something technical, etc, then it’s likely that you’re aware that I’m quite the fan of JavaScript, not just for front end web development, but to work with across the entire stack. Recently I’ve been giving Node a serious go on the back end, it’s been a while since I’ve tinkered with Node for anything back end related. I’ve continued to play around with front end technologies from native JavaScript through to all the major front end frameworks, Vue, React & Angular.
Anyway, tinkering with Node to implement some form of RESTful web service, it is honestly a pleasure. Not just writing the actual application code itself, but writing the unit tests & integration tests, setting up a CI pipeline using GitHub actions, etc. It has honestly been pretty damn awesome! – If you want to take a gander at a recent project that I’ve been tinkering with, then you can find the source code here.
While I’d consider myself somewhat comfortable working with the likes of Java, I just find Node to have that element of freedom, that element of simplicity. Unlike Java, there are no hard & fast standards, i.e. if you wanted to, you could theoretically write an entire Node application using not a single class, perhaps implementing business logic with nothing more than arrow functions. Having that freedom just opens up a world of writing code in so many different ways, though I’d consider myself unbiased, I tend to favour whatever I find works the best for the given context.
Having had the chance to make a serious stab at implementing something that’s a tad bit more mature than just some hello world application has been fun. I originally took on this task for a couple of reasons, the primary reason being that it looks like Node will be used in the near future in my current place of work. Secondly, I have many people come up to me asking for advice on this & that, asking how to get into programming on a serious level, i.e. something more sophisticated than a hello world application. So I thought why not tackle both at the same time? Two birds with one stone & all that.
Looking at unit testing with Node, it’s hard to compare it to the likes of Java with Junit, while the fundamental concepts of mocks, spies & so on are transferable, it’s still a very different ball game.
From what I’ve been studying in my own time & from what I’ve been tinkering with in my own time, I’ve come to the conclusion that Node is possibly the perfect fit for implementing micro-service architecture with some technology such as K8s. A part of the argument behind my logic is that with pretty much any Node application, the start up time is next to 0 seconds. Unfortunately, compared to the likes of Java with something as lightweight as Spring Boot. With Spring Boot I’ve found that the start up time with the likes of Spring Boot can be 5+ seconds for a relatively lightweight application, sure you can reduce that, but that involves a lot of R&D work for your given context. Obviously your mileage will vary in these discussions, but I’m mostly talking about what I’ve experienced, Java is an awesome tool, I’m not knocking it by any means. I’m simply making the comparison as I’m mostly familiar with both JavaScript & Java, not to mention that I’ve been using Java for back end development for some time now.
Now it’s an interesting topic when talking about types with weakly typed languages such as Node. It makes me laugh to some degree how some people are under the illusion that using something like TypeScript fixes everything, sure at transpilation, but runtime, it’s a different subject all together. I find it insane how the number of web developers believe that TypeScript enforces type safety at runtime. In my humble opinion, I’d classify TypeScript as a development tool & nothing more, allowing you to add some self documenting code into the mix. I usually try to avoid TypeScript itself per-se for a few reasons:
- Added build complexity
- Added number of dependencies
- Arguably more code to write
- etc.
Note; these points are mostly opinions, I’m bound to know some developer(s) out in the world wild web that would argue otherwise.
Conclusion
Not to blabber on too much, but all in all, Node is pretty awesome for creating lightweight back end applications, the ecosystem has blossomed beautifully & not to mention that there’s an endless number of tools tailored to Node JS. Though, while I am showering Node with praise, it’s not a one fits all solution, there are times where I would argue that a more traditional technology such as Java is more appropriate. The prime example being where you may have a monolithic application, where the code base utilises a lot of the available resources. But to be fair, this is partially by design, Node is meant to be used to create small, simple & lightweight applications, if any computationally complexity is required, it’s best to leverage some underlying API. A lot of people will also state that Node is called ‘node’ because you’re meant to develop many nodes, in plain ol’ English, you should use some form of SOA/micro-service architecture.
Even if you’re a small start up where you can’t afford to host something like a large K8s, no need to worry, you can always utilise technologies such as PM2. PM2 can be used to spawn multiple instances of an application, essentially behaving like a load balancer. You can also decide to spawn 2 instances of one service & 6 of another service that deals with more requests/traffic, i.e. the admin portion of a website compared to the client facing services.
Anyway, I hope that you’ve enjoyed another one of my ramblings, I appreciate that I blabber on & on & bloody on, so if you’ve managed to get this far, thank you! It’s much appreciated & I hope that you enjoy the nonsense that I spout out! ?
P.S. I may be blabbering more so than often, I’m somewhat sleep deprived & it’s safe to say that I’m running on fumes… I can’t seem to drift off at nights despite being to tired, I can only assume it’s one weird side effect of being in lock-down? ?