Skip to main content

Framework: None

For some reason, unlike Python with Django or Ruby with Rails, it seems to me that no back-end or full-stack / monolithic framework is particularly leading in the JavaScript ecosystem. Yes there are some, but I think most of the time, Node developers typically spin up an Express server and assemble various libraries together. There are libraries for everything, so you can pretty much do as much as a monolithic framework could do, but it requires a lot more research and plumbing to hook things up together.

In fact, when I created this project, I intended to call it Blitz Stack, and make it a tutorial about using Blitz. Blitz is a new framework that uses various libraries under the hood (a lot of the same ones I'm using in this stack actually) and takes care of all the plumbing for you, which means you are up and running much faster. However, I feel uncomfortable with the lock-in frameworks impose. If someday I want to swap a library for an other, it will be much more complicated (or impossible) with Blitz. And given how fast the JS world evolves, I think frameworks will have a hard time keeping up.

What's cool today might be dead in 2 years, and I'd rather replace 1 dead part than a whole stack.

So in a sense, this Cool Stack project is a way for myself to document how to make a framework-less stack. I am looking forward to the day a framework will become a standard to help reduce JavaScript fatigue though.

Might change soon?



Blitz and Redwood are very recent but promising projects that are seeing a similar adoption.

Meteor (uses MongoDB, 28% satisfaction).


Nest (87% satisfaction), Feathers (53% satisfaction), Sails (26% satisfaction), and Adonis.

Note: I wouldn't call web server and routing libraries like Express (92% satisfaction), Fastify (89% satisfaction), Koa (76% satisfaction), or Hapi (60% satisfaction), "frameworks". In my opinion a back-end framework should at least also include authentication and the data layer. Also, in the context of this stack I am not using a web server since my back-end is serverless, and routing is handled by Next.js.


A very different approach is to use Firebase, AWS Amplify, Parse (self-hosted or hosted by Back4App), Supabase or many more "backend-as-a-service", which provide varying features. The more you delegate to those services, the more locked-in you are, but they are probably the fastest way to get a back-end up and running.


Finally, let's talk about Hasura for a moment, because it's a strange bird that I really like. Hasura combines an ORM for CRUD operations via GraphQL on a relational database, a DB GUI, DB migrations, roles and permissions, and acts as the single entrypoint for all your API calls, with the ability to call remote GraphQL services under the hood. Its competitor is PostGraphile. I haven't tried it yet, but it looks more complex and is only maintained by a single developer. I like that it's written in Node and can be hosted on a serverless function though. There is also Hasura Backend Plus and Nhost to extend Hasura's features for a more complete back-end. Or you can host it on Hasura Cloud.

Hasura can get you up and running with a back-end very fast but:

  • It can't be run on a serverless endpoint, it's a Docker container.
  • It is very structuring for the rest of your stack, like for authentication or custom back-end logic. You need an other GraphQL server or API, which makes the stack more complex.
  • It's a service your app is talking to, not a library that you integrate. So if there is a bug or anything you'd like to do that isn't their way of doing, it is harder to make workarounds.
  • I don't like using a GUI to alter the database schema or API metadata, which I'd rather do with code. With some digging it seems possible, but it's not their normal way of generating migrations.
  • I am uncomfortable with having a service (even self-hosted) bearing so much responsibility within the stack. Compared to a code library, it feels like a black box doing its thing, and is less transparent than using this or that function of a library.

I will keep an eye on Hasura and will potentially get back to it in the future.

Note: Nhost CLI (for Hasura local dev) does not work on Apple M1 because Hasura does not support it yet. If using Hasura directly, a workaround Docker image is available.