Working with NestJS: A mix between a rant and (hopefully) some useful advice

After a first working (well, kind of) prototype of the product I'm currently working on, Vivi, we decided to rework our API and switch from a simple Express server to a more complete and robust NestJS setup. Though the process is not yet completed, here's what I learned in the process and a rant about what happened while doing this (mostly the latter, to be honest).

From Js to Ts

The first difference we had to face while moving to NestJS was Typescript. To be completely honest it wasn't that difficult, but I thought I should mention it for the sake of completeness. Coming from a background in C and C++, the step into a strongly-typed language was not difficult; I instead found some really cool features offered by types (intellisense, for instance).

Now that that's out of the way, let's delve into some complications we faced and are still facing.


The problem with this project is that, much as we think we have a long-term development plan, we've taken made some decisions at the start of it (mainly because we had to have a working prototype in a month) that are still affecting us. And although most of the problems originating from this are being solved in this version or the next, this still caused some major headaches to the API team (including myself). Still, at the time of writing this, we have two different databases types; MongoDB and RethinkDB. While transitioning mongoose was rather easy given that NestJS has an actual module for MongoDB and mongoose. But RethinkDB is another story...


On paper, RethinkDB is an amazing idea. It is quite lightweight, integrates seamlessly with our docker-compose setup and, most importantly, has change feeds, which is awesome. You can setup a listener for any updates, creations and deletion in a given table and with a given filter. Then you can pass them onto a client using SSEs (server sent events). The problem is that NestJS doesn't yet support SSEs (at the time of writing this article a pr seems to be ready to be merged) ! The issue is that we can't wait for the day when this PR will finally be merged, because we need to have a stabler working prototype for a conference September 3rd.

So we turned our eyes to a rising, seemingly easy to plug in method that could be used to send a stream from the server to a client and could later replace our REST API...


Setting up GraphQL with NestJS was a breeze, that I must admit. Their module for it works really well and gives you the possibility to write classes and handlers instead of a gql schema (it will be generated from the classes you define). The problem I struggled the most with was with GraphQL's subscriptions, specifically getting the info to GraphQL from a Rethink service. Hopefully it holds up for the demo, then we can rework it into using SSEs or some other way of communicating.

Some advice on starting a project with NestJS

Thank you for staying with me until this point!

Now let's get onto some of the things I've learned during this project:

  • Read carefully NestJS's documentation and make sure you understand correctly the module's structure; it will save you a headache.
  • Plan first, code later: instead of jumping head first into coding, take a minute to really plan out the task.
  • DRY (Don't Repeat Yourself): if you need a specific functionality more than once, why not make it into a separate module?

A word before you leave

I know this article is a bit chaotic, but I needed to vent a bit of frustration while working on this stuff. Still, I hope you'll have learned a thing or two from this.

No Comments Yet