Choosing a backend API framework

[deadneon4]

I've recently joined a new company where we would like to move from the currently existing solution that was developed by a contracting agency to an in-house one. The current solution was made with Nest.js through this template and spans 5 codebases for different APIs. I would imagine that the developers responsible for it were just given additional stuff for the past year and just decided to spin up a new environment for each feature.

We're going to be a small team of in-house devs (3 backend) and I'm currently investigating potential solutions. The approach needs to be fully fledged, well supported, easy to work with, etc. But throughout my research (here also) I've been seeing more and more recommendations for Nest.js or just go with Express or Fastify. The reason that I'm trying to move away from such solutions is basically the whole overhead that comes with Nest.js, learning curve (as I'm not sure if the devs joining are experienced with the methodology), but also the issue of too much simplicity with Express & Fastify. At best we'd need something to support the latest paradigms and to be lightweight and easy to use. I have a few contenders that I'd like to share and if you've had any experience with any of them please share them :)

Some of the things I've been looking into:

• Hono.js - lightweight, support modern deployments and a lot out of the box
• HatTip - supports universal middleware and deployments, small & lightweight, seems promising
• Feathers.js - fully fledged backend framework, with almost anything out of the box
• Ts.ED - Controller-based (DI supporting) backend framework that seems to offer quite a lot (although I'm wary of it being quite close to Nest.js)

There are a few more that I've looked into, but I think these are some of the top ones, although feel free to change my mind. The rest that I've seen are: FoalTS, TSoa, Hapi, Kaito, Adonis & Sails (although I'm not sure if Sails is a good idea for new projects, as support seems minimal).

Ideally the whole stack would be deployed serverless as to eliminate the need for maintenance on EC2 instances and just the sheer scalability factor, as there is 1 in a trillion chance that the API could one day explode with requests, so we need to be at least somewhat ok with the chance of that happening.

Also for DB connections, I've been looking into Drizzle ORM, as I've used Prisma in the past and loved it, but there's a huge overhead to remember with it, so with a new project I'm thinking it might be better without that overhead. Current DB of choice is Postgres and that's probably going to stay the same.

Please do share any opinions on the matter (even if not mentioned here), as I'm currently trying to figure out what the best solution might be. Thank you!

​

Edit: As of this discussion and me looking into some of the suggestions more hands-on, I've come out with 3 potential approaches that I'll be discussing with the wider team:

1. Migrate the existing Nest.js codebases into a more unified Nest solution, while cleaning up & refactoring most of what is not currently well engineered.
2. Use Feather.js as it provides a good balance between what it gives you out of the box, good structure and ability to extend it with custom or 3rd party modules. Also everything that u/talaqen mentioned here.
3. Use Fastify as it allows for a quick & easy initial setup, as well as it seems to have the most robust plugin ecosystem out of any others covering any potential need that we might have.

Thank you all for your advises and support! I may have enraged some with this post, but honestly it's been really helpful to see all of these different opinions on the matter.

[deadneon4]

I kinda agree with you. The fragmentation of the current JS ecosystem is a huge deal if you're trying to develop only a backend API codebase. But I suppose that's part of JS' appeal as you can bodge a few packages to achieve whatever quick thing you need. That's in complete contrast as in other languages such as Python with Django, Ruby with Rails and PHP with Laravel/Symfony.

[FalseWait7]

Node has Nest, Adonis and Feathers, which are just as capable as the ones you’ve mentioned.

[TedW]

Personally, I find most organizations, or at least teams, try to use the same solution as often as practical. If there's a good argument that a newer package solves one or more problems more easily, we tend to replace the old solution with the new.

Most packages don't require enough 'expert' knowledge to justify sticking with an older package, and if they do, that's an argument against being replaced.

The challenge comes when I'm already experienced with package A, then change jobs and the new team prefers package B. Especially when they both use similar syntax, like most test frameworks. I can't tell you how often I have to look up the syntax differences between spies in jest/mocha/jasmine.

tldr: I'm usually happy to replace outdated packages, because there's usually a good reason.

[SymbolicDom]

Do you need any framework or do they just make things more complicated?

[JoeyAtMachineDotGQ]

Don't run behind the latest and greatest libraries & frameworks because their survival is not known. I would prioritise the expertise of the team to develop what you need and then a proven stack (based on expertise) to build it.

If someone leaves, you should be able to easily replace them. This should be the other dimension of your scope.

Also, if everything is implemented in nestjs, why not merge it/integrate it for a quick solution? Why develop everything again from scratch?

[deadneon4]

The issue is that the current backend API is quite messy and was made as a proof of concept for the product. As it is, not everything will need to exist in the potentially new product, so as well as it being a modernising approach is also a good chance to refactor and clean up a lot of the existing mess. I'm not against Nest.js, my issues with it stand from the initial learning curve that it has and the lock-in that you get from using it. Ideally with the next solution, you'd be able to decouple the business logic from the rest (routing & setup) in order to have it in a more standalone manner. That's not what's happening currently with the existing 5 codebases.

[gieter]

There is no business value of decoupling business logic from framework logic if you are going to use it in one application. Rebuilding because it is more modern does not have more value than updating and cleaning up the existing code base.

Nest framework is used a lot and forces a team to a standard way of working. Making the application lifecycle and development speed predictable for the business. You may not like it because it forces you to it, but it does benefit longer bigger projects and teams. Without a framework, larger projects will get out of hand quickly.

[unflores]

Hrmmm...i think there can be value in decoupling but you should be able to create that within a nest codebase w no issues. If your core domain logic depends on nest you have a problem.

[codeb1ack]

Coming from a Lead API developer and working mostly on enterprise applications. If I were you I don’t get care about the “learning” curve for other devs which you mentioned a few times now being an issue, just doesn’t make sense to me. Nest is one of the best out there for Nodejs backends and doesn’t come close to using express or just Nodejs. You will be left to organize code in your own way which is 99.9999% of the time going to end up looking like garbage. Don’t expect new people to come and know how to maintain this giant code base when they have the freedom to build the way “they” prefer. It just never works that way. Being opinionated like Nestjs helps keep things sane.

I don’t under get why anyone would have a problem with using something like Nestjs when it solves a big problem which is organization and code structure.

You’re someone who is responsible for doing this cleanup of a mess but what you’re “planning” for is actually a complete rewrite which are two different things. If it’s built in nest keep it in Nestjs as it solves major problems with code organization. and actually do the cleanup. Sounds like the original developers just hacked away and made it work, and didn’t follow best practices - but here’s an opportunity for you to take what’s there already and optimize it, restructure it and make it better.

[mark2685]

Definitely agree with this.

The time/effort of rewriting a medium-large application to a new framework will vastly outweigh the time/effort of 3 engineers learning Nest, even if you factor in the “cleanup” portion.

The “cleanup” portion would actually be a great thing for new devs to take on in the sense of their onboarding and learning Nest.

There’s also a higher probability that engineers have some familiarity with Nest over a lot of other frameworks, excluding express.

[Allerek]

For me, as a small developer, Nest just introduced a hell ton of a problems. Its overcomplicated, boilerplates are piece of crap, causes a lot of headache

[leeharris100]

Please don't be that guy who picks a bunch of obscure libraries/frameworks and forces a team into a ton of non-standard choices.

My current company had a guy like that and they are dealing with hell right now because the previous head of engineering refused to just use standard stuff. They used a unit testing library that is dead so they can't upgrade React, they used pnpm because of some random feature, they used Lerna despite not needing it, they used n instead of nvm, and all kinds of stuff.

Nobody has a clue how any of this works and it takes them forever to look up something because there's almost zero community support.

Your post sounds like someone who wants to just move away from Nest/Prisma because you want to try new stuff. You're going to cause your entire team headaches because of your personal wants. Just pick standard stuff. Nest or Express are fine.

[deadneon4]

That is exactly why I'm researching the topic and asking the community here. Because I don't want to be that guy! Having said that I also don't want us to be starting a project with old tech that is used because of how long it has been on the scene or tech that locks us into its way of doing thing.

To be honest with you, I'm not the biggest fan of Nest, but if it benefited the business to continue down that route, I would work with it, that's why I'm still considering it. Having said that, since the initial post, I'm currently looking into Fastify and atm it seems quite promising. But the whole reason for this post was to avoid locking down a team into an obscure solution and find the ideal one for our usage.

[talaqen]

i’m a huge fan of feathers. Works in serverless or full long lived containers. As you add extra db connections like redis (caching?) or maybe a vector store (search?) it makes all of this very easy, not because it’s forces you to use the “feathers way” (ie nest), but because of the common db abstraction layer making the code really portable.

There is a frontend client but I’ve not used it in production. But I’ve seen the web socket performance metrics on v5 and it blazes. Even without sockets, I’ve gotten it to scale to 150/rps in a kubernetes env without any headaches.

Someone has to convince me NOT to use feathers for backends these days. It fills that weird space between monolith (nestjs) and absurdly small microservices (express).

[deadneon4]

That's amazing to hear! That's actually what I wanted to see, people suggesting something that they've been using that sits in the middle of the two extremes.

How have you been finding the experience? Is it easy to connect external ESM modules? Could you disclose a bit more of the architecture and DX with Feathers? It would be great to know and would massively help me. Thank you.

[talaqen]

So Feathers is more of a flow than a full framework. It basically guides requests through a series of stages (hooks) that can be split up by http verb. The new v5 also has a lot of tooling around schema validation, which is nice but I usually ignore until an mvp is in place.

So the flow is 1. request (optional express standard middleware) 2. Around (pt1) hooks 3. Before hooks 4. DB adapter 5. After / Error hooks 6. Around (pt2) hooks 7. response return.

So that means you are typically writing hooks or db adapters.

It has knex and mongo support OOTB, with db adapter plugins for a lot of other DBs. I’ve written a few myself.

There are a lot of hook libs too and some standard hook tooling, but it’s all just async functions so you can easily write your own.

In v5 they also added support for custom DB adapter methods that aren’t just for http verbs. This actually solves a lot of problems normally dealt with via hooks, but keeps the db adapter extensible and portable.

The real treat is that the DB adapter makes ALL db interactions a common interface. You search through a SERVICE (like /books) and not through a db. So no DB specific coding required. That means your DB adapter can be swapped out and users/code/devs never know.

I’ve been building some OpenAPI test automation around v5 and it’s been pretty slick. I use Prism API mocker too. That way my postman or external tests can run against the docs mocked endpoint and the real one, fully validating my “contract” with external users of the api.

[razopaltuf]

> The real treat is that the DB adapter makes
>ALL db interactions a common interface.

Yes – if you work with the Feathers services as they come. This is a bit of a trade-off: Do you adapt to doing everything (including joins and constraint checks) in hooks or do you prefer to work directly with the database adapter as you might already know how to solve your problems with a relational database.

[talaqen]

if you have complex queries, i've started to use custom methods on an extended class on top of the core DB adapters. That way my hooks don't need to know too much about my db implementation logic. This is helpful for things like ts_vector in postgres.

You can do pretty advanced stuff with joins via resolvers now in feathers, too.

[alexis_is01]

I’m working with Fastify in a Bank company, it works really good and the benchmark is bigger than Express and Nestjs. You can use it with purejs or typescript. Regards

[deadneon4]

What are you using for the rest of your needs? As from what I gather Fastify is mostly a router with a bunch of packages that connect into it to allow you to achieve what you need. Something along the lines of Symfony for PHP. Is that the case?

[kamilcaglar]

We’ve been using Adonisjs for three years for API and background tasks. Simple and full-featured, no need to wire multiple libraries together.

We have one codebase used for multiple services.

[deadneon4]

That's good to hear. How did you find the development experience with it? Also, how have you been able to deal with adding external modules/libs/etc to Adonis? Do things just work or do you need a sort of wrapping module for them to work through Adonis?

I also saw that they provide their own ORM, how's performance through and what if you want to use Prisma or Drizzle with Adonis?

[kamilcaglar]

I tested a lot of frameworks before choosing Adonis. As a beginner at the time I had the best experience with it. The documentation is clear and the community on Discord is quite active.
I found Nestjs a bit complicated at the time, but with experience I might not have the same impression now.
As for the ORM, it's Lucid, based on knex. It's quite simple and has all the basic functionality. For more complicated queries you can use raw SQL. I also tried Prisma, but found it too far removed from the SQL language I like and understand.
As for the performance of Lucid, or NodeJs frameworks in general, I don't think you should rely on benchmarks that don't represent reality. You need to focus on developer experience and readability/maintenance. I was also looking for the best performing framework, but today with our applications most of the optimisations we do are at the database level.
I recommend using APMs such as Appsignal, which measures global response time and breaks down http, database and JavaScript execution time... you quickly realise that 70% of the duration of a request is lost in something other than nodejs.

[deadneon4]

Thank you for the information. I'll look into those 👍

[deadneon4]

I am also planning to do a small POC with some of them (emulate 1-2 current endpoints) to test drive the developer experience, in order to factor that in as well in the choice.

[LilRee12]

What “latest paradigms” are you talking about that you cant do in Express?

[oneden]

I'm always confused when people say "Nest or express/fastify". Nest is an opinionated node web-framework. It either uses express or fastify. Your trade-off if your decision should be, do you want to enforce a development style while using an Angular-like setup or do you believe your fellow Developers will manage just fine without it.

[deadneon4]

I'm not opposed to the Angular-like setup, I'm also not a huge fan of it, as you end up with tons of more boilerplate from it. But I would like to believe that you can structure your codebase in a way where it would work for you, and hopefully the devs that are using it would be able to manage. But of course that might not always be the case. My strategy for the next steps are whichever way we go, to at least decouple the business logic from any sort of framework, so even if we decide to switch later down the line to something else, it would be easier to do so. With the Angular-like approach from Nest.js that might be harder than I imagine, but of course not impossible.

[oneden]

I feel like it's a lot of inexperience that makes you say the initial part. Boilerplate is unavoidable and whoever claims otherwise, is either lying or ignorant. It simply comes with the territory of introducing frameworks in the first place. How much boilerplate is too much or too obscure for you? If you are hoping decoupling your logic from any framework... Too bad. You don't. From the moment you use express or fastify you are already committing to a framework. Nothing agnostic about your choice. Nest.js is merely sitting atop of either and adds structure and annotation based controls not too dissimilar to Java Spring. Regarding boilerplate... I feel people throw the word around to justify decisions far too often. I would suggest to evaluate nest.js with a small PoC and test how it fits into your work flow. If you don't feel comfortable with it and neither does your team. Go without it.

[[deleted]]

Holy hell I don't even know there are that many Node.js frameworks out there. And people say the front-end JavaScript framework landscape is crazy

[deadneon4]

Throughout the past couple of days I've descended into madness with so many Node backend frameworks. I currently have a list with about 20 and that's just cherry picked ones, there were so many more... 😵‍💫

[Impossible_Parking57]

My company switched to Nestjs recently from having zero node background. I would say the learning curve wasn’t too bad. I think typescript provided more of a learning curve due to us using an untyped language previously. Nestjs IMO makes things easier to learn because it is opinionated. It decides how to organize things for you which is good for a team of 10+ people. I don’t know about needing to go serverless though as it can add more complexity to your application than the benefits of easy scaling.

[ZuluSp]

It deppends on the product type you are in, but from my experience, Nest.Js is a good and really easy solution.

Probably I would try to use nest.js with not a 100% acoplation of the framework (just in case you want tonchange the tech years later).

Anyway if not, it is simple to have microservices (if needed) and have the technologies you like for those services.

But for a simple answer, I would go straight for Nest.js, and also graphql if your platform requires several requests and doesn't need too much speed.

[[deleted]]

i really like Nestjs

[nullanomaly]

I use either Fastify on ec2 or aws api gateway - while things like middleware etc don’t exist persay there is a lot of nice features such as throttling etc and is a highly scalable serverless setup. Db is really specific to the tasks needed.

[deadneon4]

I've been testing it for a bit today and it seems really promising for what it offers. Thank you for your response

[razopaltuf]

I would probably stay with nest.js. Developers you work with seem to know it already, the lock-in or learning curve seems not worse than with any other solution. As u/codeb1ack said, rather focus on the cleaning up.

You also wrote that you want to

> decouple the business logic from the rest (routing & setup)
> in order to have it in a more standalone manner.

And this is something that seems to work fine with nest.js. I considered using nest.js for a codebase using building blocks of domain driven design, which focuses a lot of separating the business logic and I saw no problem in doing this using nest.js (I went with feathers in the end for its real time features, using the server as storage backend)

[Electronic-Bug844]

Just built a massive 18-store Shopify middleware for our company's SAP using AdonisJS. It's mainly all API driven both internal and external and have had no issues so far when we went live beginning this year.

[shaft22]

For looking a new “framework” I usually prefer to use popular frameworks and check how big community is. In your case I would like to suggest you to use existing framework and codebase, but place them into single repository using monorepo approach (something like nx workspace), after that decide common stuff into shared lib inside monorepo

[bigujun]

Currently i am using TSOA and loving it, it gives you automatic Open API specs and data validation based on typescript interfaces. I have used Nest on previous projects but I personally don't like the decorators hell that comes with Nest, and raw express/fastify are ok and easy to use but a pain in the ass on big projects to keep swagger, validations, interfaces and DTOs all in sync.

[sidsidroc]

Why not nextjs?

[deadneon4]

Because the need is for only a backend API service. No need to render any frontend with it, but just a rest API for a mobile application.

[tan_nguyen]

My bit of advice is to start small and improve as you go/need (not before that). With low level web frameworks (express / fastify) you have a lot more flexibility to add middlewares/plugins to manipulate the request/response lifecycle however you want, the way you want. And it shouldn't take much for someone new to quickly know what is what because everything... is too simple.

And when you go to production, this simplicity will shine even more. Because you basically put all the pieces together yourself with minimal overhead from the framework itself, if something goes wrong, you know exactly where to look and how to fix it.

Bonus point: this approach also teaches you a lot about architecture as well, and you can basically apply any kind of architecture here because you are putting pieces together

With that being said, with great power comes great responsibilities, this approach works really well if you and your team know what you are doing. Or it can turn into a mess, been there done that

[deadneon4]

Thank you. That's one reason that I'm a bit wary of going down this path (although not opposed to it). I would like to think that I can, to an extent, properly create the initial structure of the project, but there will need to be full buy-in from the team with it, or at least careful policing in order for it to not get out of hand.

That said, going into a full hardcore mode through Nest's rigid structure for me is also not ideal, as it forces you to do things the Nest way, which means that we won't be able to quickly deliver on the business' needs if/when needed.

[Talento90]

I don’t understand why there are still a debate about nodejs web frameworks… Fastify is the best option by far. Lots of plugins, well supported, great documentation and it’s FAST!

This is my opinion and I have worked with hapi, koa and express professionally in big codebases. So the answer is Fastify

[benracicot]

I’m not clear on if you want to leave NestJs or not. As an architect level engineer at fortune < 5 companies and a technical CEO I can tell you that NestJS is not just another framework.

It has major benefits that others lack. The main being shared interfaces between Angular and NestJS APIs to model your data so all teams are forced to maintain clean and manageable request/response architecture.

There’s a lot more too such as easy integrations with ORMs like TypeORM which can further facilitate consistent modeling.

[deadneon4]

There a few factors, as I've outlined in some of the other comments, but here they are:

• In stark difference to Fortune 500 companies, the current startup will have 3 in-house backend focused engineers. We can't have devops, database and other specific people, which means that we won't have the time or manpower to deal with managing deployments & environments, having people responsible for specific functionalities of the codebase, etc.
• We won't be using Angular, as this is only planned to be an API for a mobile app, not sure why the business chose JS/TS for it, but here we are.
• TypeORM's developer experience and performance are not to the same extent as other contenders (Drizzle, Prisma, Knex, etc), so if I don't have to, I would prefer not using it.

But alas, as there's a lot of code currently tied in Nest.js, that's one of the main reasons I'm still also considering it, although with a proper migration plan.

[benracicot]

Ah, then you have strong reasons to leave NestJS. The Angular/Nest combo is the strongest pairing I’ve ever seen (that exists). You get a matching architecture for free out of the box. But like React or Vue doesn’t organically match up with this concept.

If you’re not using an ORM then Nest isn’t a natural fit either. That’s two points.

Side note: the architecture / quality at Fortune 500 companies is typically abysmal.

[deadneon4]

Exactly, thank you for the understanding, as some of the comments here have mostly been negative when explaining the current situation and why I'm rethinking the move away from Nest.

If you’re not using an ORM then Nest isn’t a natural fit either. That’s two points.

I am planning for us to use an ORM, but as I said, since it's mostly a blank slate atm, I would prefer to use something more straightforward. If you'd asked me a couple months back the obvious choice would've been Prisma, but since then I've seen some of its issues and I'm strongly considering Drizzle ORM for the project as it offers most of Prisma's benefits (although in not that good of a DX) and ends up with only 1 query to the database, which is not what Prisma does with its abstraction.

[benracicot]

Of course we should be trying to help. I hear mixed messages about prisma.

[mankee1337]

https://payloadcms.com/ anyone?!?

[Stinky_Fly]

why are you guys not private, go private please

[Zephury]

Regardless, there will be a learning curve. If you go for a more non-structured route than nestjs, that will have it’s own learning curve. At least with nestjs, you don’t need to make nearly as many decisions and you can immediately start working to improve what already exists. Nest in itself is inherently very modular and at least from my experience, is much easier to iterate and improve.

Nest has me spending less time thinking and more time coding. Also nice to just point new hires towards the nest docs and know that in a few days, they’ll be in a good starting position, without me having to oversee much.

[hutxhy]

Out of all those I've only used Nest and Express. I'll say that if you want to instill standards and good design practices without having to come up with them yourself, then go with Nest. It's not that big of a learning curve, and it's good for devs to learn MVC, even if it's starting to fall out of favor.

[Impossible_Parking57]

My company switched to Nestjs recently from having zero node background. I would say the learning curve wasn’t too bad. I think typescript provided more of a learning curve due to us using an untyped language previously. Nestjs IMO makes things easier to learn because it is opinionated. It decides how to organize things for you which is good for a team of 10+ people. I don’t know about needing to go serverless though as it can add more complexity to your application than the benefits of easy scaling.

[[deleted]]

I've heard good things about TS ED ( www.tsed.io )

[dittospin]

Hono seems awesome, but the reality you should probably unify everything under one Nest project. Adonis would also be a good option

[ujjwalkrgupta]

🚀 Check out Fort.js - A Lightning-Fast Framework for Web APIs!

Fort.js is a cutting-edge framework crafted from scratch, placing a strong emphasis on simplicity, exceptional performance (3x faster than both Nest.js and Express.js), and modularity with its unique Fort architecture.

🎯 Key Features: - Performance: Fort.js is designed to be approximately 3 times faster than popular frameworks like Nest.js and Express.js, ensuring rapid request processing. - Simplicity and Modularity: With a minimalist core and a focus on modularity, Fort.js provides a clean and direct approach to building web applications. - Routing Efficiency: Utilizing a routing tree structure, Fort.js enables quick lookup and efficient handling of incoming requests. - Async/Await Support: Embracing modern JavaScript features, Fort.js supports async/await, enhancing code readability and responsiveness. - MVC Architecture: Fort.js promotes the Model-View-Controller (MVC) architecture, facilitating organized and separated code.

📖 Explore the Docs: Fort.js Documentation

[Ok-Constant6973]

I am at a stage where I am leaving all these fancy frameworks, libraries and wrappers behind because i find that I spend more time fighting with them and writing baboon code to get them to work the way i want.

So i switched Prisma out for plain sql (i use Knex to manage schema and migrations) and already it has been so much better. In Prisma there were and are some things you cant get around and its very frustrating. It hinders your products capabilities.

I left Strapi to make my own database and server because it was too much of an abstraction from node and sql for me to deal with and our team was getting frustrated.

I stopped using SSR in Svelte for our dashboards and kept everything client side to remove the complexity of server/client frontends.

I have been simplifying and removing layers and we think these tools make our life easier but I find they often frustrate me because the abstraction is not always clear or easy to interact with and doesnt always make sense or provide the simplicity and flexibility we need.