DEV Community

Michael Z
Michael Z

Posted on • Edited on • Originally published at michaelzanggl.com

Simple libraries do not guarantee simplicity - Rethinking popular NodeJs libraries

Originally posted at michaelzanggl.com. Subscribe to my newsletter to never miss out on new content.

So often I see people architecturing their projects around low level routing frameworks like expressjs, hapi, koa etc. They often get advertised as "powerful" and are the main resources to develop "robust" web and mobile applications.

Sure it starts of fairly quick, but soon you will be in need of controllers, error handling, accessing a database, an ORM, authentication, authorization, sending mails, caching, validation, and at that point most definitely, a clean architecture to keep everything together. There are of course many other things that you are missing out on such as events, a repl tool, database migrations, ioc container, logging, csrf protection and a way to write tests easily.

Before you know it, you are trapped in spending a huge amount of time hacking together your own framework, rather than writing the application you wanted to build in the first place. Now I don't know what is so robust about that...

I am going to list down some high level alternatives here: (if you know more, let me know)

While the inital learning curve is definitely higher, you will benefit from it in the long run. These frameworks can teach you a lot about clean architecture and code, commonly applied concepts, keeping your application secure and how to focus only on the application you set out to build.

Don't get me wrong, I can certainly see how building everything from scratch is a good learning experience, it was for me! But after I have done it one time and wanted to start another application, I didn't really feel like doing it all over again. You should also be very careful with using your custom built authentication system on production.

Another thing would be onboarding, people familiar with the high level framework can immediately jump into coding, rather than spending a day trying to understand the architecture of the project only to fix a small bug. In case they don't know the framework yet, there is at least documentation and blog posts to read about it.

At the end of the day, we want to build applications and be confident about the code we have written.

Top comments (3)

Collapse
 
gypsydave5 profile image
David Wickes

At the end of the day, we want to build applications and be confident about the code we have written.

Hmm

  • How confident are you about how any of these frameworks work?
  • How confident are you that they will be supported next year?
  • How confident are you that your requirements for next month will be, or even can be, met by these frameworks (hint: you do not know your requirements for next month)?

Simple

No, they are not simple. They are easy. Dig under the superficially simple surface and I'll guarantee that you'll be confronted with complexity, probably incidental complexity. It looks simple because the complexity is hidden away, rather than explicit. Like hiding your dependency graph in an inversion of control container. It's better to try to address and simplify that complexity rather than shoving it under the carpet and hoping that nobody notices.

Collapse
 
michi profile image
Michael Z • Edited

Sure there are some tradeoffs to be made. But I'd say frameworks cover more than one use case, so when requirements change (and they will), there is a good chance the framework already provides a solution for it, or provides a way to override its behaviour. At least working with Laravel, this has been a very pleasant experience. If I wanted to understand how things worked internally I had a look into the source code.

Now if you are not using a framework you'd likely have a big task ahead once requirements change, depending on how coupled the code is. Of course, if you are very experienced this should be not a big problem, but at least for me, it took me a framework to teach me about these things.


How confident are you about how any of these frameworks work?

No, they are not simple. They are easy. Dig under the superficially simple surface and I'll guarantee that you'll be confronted with complexity, probably incidental complexity

The point of my article was that if you are using one of these low level routing libraries, you should simply take a look at more high level frameworks and see if they can not already provide you with everything you need. But are you suggesting that even simple libraries like koa or hapi should be avoided?

Collapse
 
quii profile image
Chris James • Edited

There's lots I disagree with about this post that has been argued so much it seems hardly worth going over again. Just read

However

a clean architecture to keep everything together

What is a clean architecture to you? What does it mean? And why do I need to download someone else's code to get it?