Recently I’ve hit a practical limitation with Python’s ProcessPoolExecutor: when feeding it tens of thousands of tasks from hundreds of producer threads, the executor happily accepted them all. The result? Memory usage ballooned, latency increased, and eventually the whole system became unstable.

Why doesn’t Node.js have something like Django’s Class-Based Views (CBVs)?

I love Django key features like its class-based views or ORM, and I usually miss them when working with Node.js. So yesterday night, in the middle of my usual insomnia, I wondered if anyone had already built something like that for Node.js.

I did a quick search, and what I found were just a few experiments from ~8–9 years ago. Nothing robust, modern, or maintained.

Django Class-Based Views (CBVs) provide a clear structure, lots of built-in functionality, and still enough flexibility to adapt them to different use cases. So I decided to sketch out a design for Fastify (and Node.js in general) that feels natural to use, contract-first, and TypeScript-friendly. This post is a walk-through of that exploration during the rest of the Sunday.

An exception happens when something we expected that should happen, didn’t. We can log them, but printing logs everywhere add a lot of noise, so it’s better to throw errors and handle them in upper levels. Also, a thrown error is easy to check and test, but a log message is not, so they are better for unit testing.

I’m a bit obsesive with code and architecture quality, and having them done like they could be put down on a textbook, or at least about they being used by others as reference of how things can be done right. I’ve always feel a bit frustrated that newcomers get and perpetuate bad habits, just because they learned them that way on the first place by thinking that was the way to do the things… Later, if things are working, people don’t give a sh*t on thinking about if there’s a better way to do it, both to improve their work quality or processes, or for learning and improve themselves, they just move on… So it’s better to do things right from the beginning, since later they are more difficult to fix, or simply you forget to do it. And at the end, just by doing things right on a first aproach, you get used to it and does them that way by default :-)

Javascript don’t have the concept of abstract classes, but it’s fairly easy to implement: don’t allow to instanciate them :-) Just check if the constructor of the instance we are creating is the own class instead of one of its childrens, and don’t throw an error if it is:

Long time ago I talked about a pattern I use (a lot!) abusing the functional methods of Javascript to earn some memory and CPU usage. I promised to create a blog post, and almost 4 months after (too much energy draining work…), here is it.