DEV Community

Cover image for Frameworks War
Farmin Farzin
Farmin Farzin

Posted on • Updated on • Originally published at

Frameworks War

Last year we started building our portal from the scratch and we had the luxury of using any technologies, framework or library that we wanted to.

We didn't have a lot of time so we just wanted to speed up and write the business logic rather than wasting time on the configuration of tools together.
Our only restriction was the fact that we were all JS devs and we wanted to write JavaScript or TypeScript and also from the DevOps side, we knew we'll use K8s (As much as I love Serverless, unfortunately, it was out from the picture - Maybe another blog for another time to talk about this).

We had a list of suggestions and in there we had frameworks or multiple libs working together. We decided to pull out the libraries since we wanted an opinionated framework to give us the power to focus on writing the code for logic from the first day. Of course, there's a trade-off between those approaches as you would have the freedom to choose the best libraries (or the ones that you're comfortable with) or you can just limit yourself to a framework and its conventions/patterns.

This was very controversial as some people believe in the convention over configurations and some people believe in freedom of using whatever they want and configuring them as they want.


But How We Could Decide?

We prepared a list of features and considerations that we liked to have from the framework or library and gave them points.

  • Only Backend/Frontend or Full-Stack Some frameworks offer the Frontend in their architecture too, so there's no need to have a separated project but again, you'd be limited to their patterns.
  • Stable Version There are a lot of amazing frameworks out there, but not that all of them are production-ready!
  • Community Support You'd be surprised how much this matters. When you face a weird bug and want to scream and leave your job, you can just search it on the internet or open an issue on Github and people will help you.
  • Documentation No need to mention how much important it is.
  • DB Migration So this is one of the underrated features that will save your skin. The ability to manage your migrations, revert them, or apply them to new environments.
  • Debugging Easy debugging would save a lot of time from devs and make your delivery pipeline faster.
  • Learning Curve As always, the time constraint is the biggest issue in any product development and this will help for ramping up quickly as you code.
  • Testing There's always a way to test your code with the technology that you want. It depends on what type of testing. I would love to see the framework offering unit testing out of the box but for integration or end-to-end I might go with my solution.
  • Logging Any production application needs good logging. Get you out of trouble when your users are reporting bugs.
  • Configuration How much time we'll spend on the configuration of a project to have it set up? is it high or it's just a matter of running a command?
  • CLI tooling A lot of frameworks offer CLI commands which makes it easy to generate and scaffold a lot of code and saves a lot of time.
  • Backend API protocol We were looking for having Restful but some offer Graphql too!
  • Typescript support This was optional when we were making the decision but if I go back, I'd make it required.
  • Career One of my considerations when I want to learn technology X is "what is the future of X?". This time not for me but also the team, would devs be happy when they become experts of that framework? When we want to hire new devs, are they going to be excited working on it?

So Which Frameworks?

Our final list of frameworks were:


The first decision that we made was around the first item on the list: Only Backend or Full-Stack.
We wanted to scale and we knew we're going to have multiple web apps consuming our API so we decided to have our Frontend separated.
It was easy, Next.js was the winner since it offers a ton on the frontend and satisfies most of our items on the list.

Then we took out the ones that didn't have production-ready version. Unfortunately Blitz and Redwood got eliminated and it was a pity honestly. I loved RedwoodJS so much that I started doing my side project just because I didn't want to miss learning it.

Later we got rid of Express + Prisma because for making it ready we needed to have a lot of configuration and adding a lot of other libraries for future requirements.

So we had the final list of Frameworks which had 'Stable Version', 'Community Support' and good 'Documentation'.
I'm not going to review those frameworks but as we researched and looked into them, not all of them had good tooling or CLI commands or DB migration management capability.

Between those we chose NestJS: it had almost all of the points that we wanted, the only issue at that time was Prisma which wasn't production-ready and its migration was experimental but right now after more than a year, we are super happy for the call that we made!
We have scaled 10x on the product side and 4x on the dev side and NestJs scaled very well, plus Prisma released a lot of features and made it easier for us to scale on the DB side.
Talking to devs on the team, they are super happy too. They have learned frameworks (both NextJs and NestJs) that are great for their career!

Top comments (10)

andycharles6 profile image

What was the reason for not choosing Adonisjs?

farminf profile image
Farmin Farzin

Honestly, Adonis was on top of our list with Nest but we wanted to have Prisma in our stack and that at that time Adonis didn't have a straight forward integration like Nest. IIRC, other reason was Kafka integration in Nestjs that gave it more points.
Anyway, all of these frameworks are great and it was hard to choose one. Small differences made us choosing Nestjs.

andycharles6 profile image

Makes sense. Infact Adonisjs ORM is one of the reasons for us to use Adonisjs.

I tried Prisma, but felt limited with what I can achieve, especially when I want to rely on complex SQL queries

dylanwatsonsoftware profile image
Dylan Watson

I've used both NestJS and NextJS in prod and have loved them both! I'd be curious to hear more about your usages of both of them though

farminf profile image
Farmin Farzin

We love them too. So on the FE part we actually built 2 apps with Next and our user consumption scales 2x monthly.
On the backend, apart from our apps we expose our API to some 3rd party services and the usage is super high. Don’t have a precise data but only on one of our endpoints we have 5k calls per day.
Plus we’re using Nestjs micro-service for Kafka consumer and Nest commands for our cronjobs.

dylanwatsonsoftware profile image
Dylan Watson

Yeah nice. My feeling at the moment is that for simple projects you can probably get away with just nextjs hosted on Vercel (with serverless functions). For larger projects, replacing Vercel serverless with NestJS seems pretty perfect.

joaozitopolo profile image
Joao Polo

NestJS is... difficult to extend things... I tried to use with mongo, for example, and it seems impossible without a deep knowledge of nestjs sources.
Why don't include MeteorJS? It has a good documentation, front and back in the same place, websockets, and graphql if necessary... and you can choose from several frontends. I'm using with react and typescript... I choose that after 1 month trying with nestjs

iameaszy profile image
Yusuf Adeniyi

I've been using NestJS since last year. When i saw your features list, i'd know you will choose NestJS! The framework is awesome ❤️