This content originally appeared on DEV Community and was authored by Farmin F
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:
Decisions
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!
This content originally appeared on DEV Community and was authored by Farmin F
Farmin F | Sciencx (2021-09-14T02:47:25+00:00) Frameworks War. Retrieved from https://www.scien.cx/2021/09/14/frameworks-war/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.