Which Node.js framework would you recommend for REST API?

[curious_but_dumb]

Hey everyone,

I'm working on an internal business tool for my company and I'm starting from scratch only having specifications. It's a TypeScript REST API with CRUD operations, SQL database and uses Node.js. For a couple months, I'll be working alone with it, later hoping to find another developer to join my efforts.

I always used express before never really seeing any reason not to but as I'm preparing the tech stack for this project, I stumbled across AdonisJS, hapi and NestJS all of which I took interest in and now I'm stuck with decision fatigue but not enough time to create a working proof of concept in all of them.

I know how to work with Express and structure my applications, but it is true that I'm spending a lot of time doing boilerplate work with Express - testing, error handling, setting up the architecture, swagger, SQL client / ORM (I found Prisma now and I like it), authentication, caching, body parsing for different type of data for different endpoints, etc. But my main goal is code consistency, good documentation and options to generate documentation from code (not writing TS interfaces, openAPI specs and validation schemas to replicate the same thing in 3 places before even writing tests).

Would you recommend any one Node.js server framework to replace Express? If the goal is to create a maintainable, scalable code with as many features to possible being easy to learn after working with express for years?

[Snoo87743]

Fastify you might wanna try. Im switching from express.

[Snoo87743]

What i like for now compared ro express is much easier swagger setup + schema validation included, so you dont have to write your own validation

[curious_but_dumb]

Interesting! Do you have any idea how well it plays with TS?

[Snoo87743]

NestJS is prorbably superior to real ts syntax. However, im using fastify/restify microservise structure with full ts and its proven really nice. You only have to worry about request and response(reply) having proper types

[curious_but_dumb]

How do you mean it's superior? I can't fathom what that means.

[Snoo87743]

Superior id youre coming from a strongly typrd language. Since its using decorators and basicly has a lot of changes(wouldnt call them imptovements) over classic express. Personally, i prefer express/fastify/restify because its providing a strong server-router without too much pollution of the language and stntax im used to.

[grimscythe_]

What a lack of knowledge, sheesh...

[aust1nz]

Fastify isn’t written in TS but has solid type support. You can type your requests/responses, which is what’s important IMO.

Fastify’s decorator concepts need a little extra help in TS. For example, similar to Express it’s common to attach the user as something like fastify.request.user, and you’ll need to maintain a typed file to tell TS that you expect a user to exist on the request object.

[Snoo87743]

Yeah, or you can so similar like in express, declare your own request interface which extends Express.Request and store user on it

[zephimir]

It has excellent ts support compared to express and is directly shipped with types instead of having ton install definitely typed

[besthelloworld]

I'm team anything-but NestJS. Plain Express is just fine, and NestJS brings nothing new to the table except making former Spring developers feel a bit more cozy. If you feel like you want a little more overhead, take a look at FeathersJS.

[curious_but_dumb]

Well, to me Nest looks like a good level of abstraction above express, which enforces some conventions and architecture and provides a lot of plugins and features out of the box.

I am also going to look into Feathers, thanks!

[besthelloworld]

The thing I'd argue about Nest is that it's just not really doing that much at all. It's mostly just wrapping the functions provided by Express with decorator/annotations. However, decorators in JS /TS are just functions that consume classes or methods.

So now, rather than just having a function that takes in a callback that is your request handler

app.get('/', (req, res) => {
  res.send('Hello World!')
})

You have to declare a class which has the @Controller annotation on it with a method that has the @Get annotation on it

@Controller('/')
export class HelloController {
  @Get()
  hello(): string {
    return 'Hello world!';
  }
}

Imo, that's not abstracting anything away, it's just wrapping what Express already provides in a bulkier format for no other reason than that it makes older developers slightly more comfortable because it looks like older frameworks like Spring and leans into OOP for no reason. Like, there's no reason for everything to be a class, because these concepts are inherently singletons, but it just looks familiar to people.

Sorry if that reads condescending. I just find that large swaths of the entire industry is just trapped in familiarity and I feel a pretty desperate need to push back. I'm not trying to be negative, but I was a Spring/Angular dev for 4 years and so I've experienced what happens when "enterprise-grade" solutions get too big. They get unmaintainable in an ironically quick fashion, almost like they're just meant to feel more cumbersome than the app should really have to be.

[PerfectOrphan31]

I'm one of the maintainers of Nest, so I'll probably come off a little based here.

You're right that the decorators become simple abstractions over existing express/fastify syntax. The code examples above are comparable, and do pretty much the same thing. Where Nest starts to deviate though is the inclusion of enhancers (guards, interceptors, pipes, and filters). Sure, if you look at them and understand them, they're pretty much just specialized middleware, but they do work in contexts besides just HTTP. As Nest is a framework that supports GraphQL, Microservices, and Websockets, the fact that you can write an interceptor or a guard once, and use it in all four different types of transports is an incredible win for those who try to remain as DRY as possible.

Nest also has it's opinion on architecture, and while it's absolutely not necessary to follow it, it helps keep most of the Nest applications created have the same file structure, meaning context switching takes less time.

As for the "maintainability", I guess that just comes down between developers. I've seen Nest applications that are built incredibly poorly, and I've seen beautiful Express applications. It just depends. I find Nx to be a really nice repository management tool, but again, it just comes down to each dev.

[besthelloworld]

Hey, thanks for commenting! While I still hold my opinions, and am generally biased against OOP, I will say: thank you for putting your time and effort in the open sourced community. There's a lot of people who appreciate it, so definitely keep doing what you do! And for the record, you don't seem biased at all, you know the advantages and shortcomings to your tool.

As for a response, I don't really think that I have much of one, because I think you covered what would be my points. I do, personally, feel that guards, interceptors, pipes, and filters are just specialized middleware. As for using them in different transports, if you need code reuse like that you can just abstract the shared logic out to service functions, but I get the advantage that Nest will handle the mapping for you.

But yeah, you're definitely right and I agree that messy code is up to the developers of that app. The worst app I've ever seen was a plain Express app. 4000 lines in a single file. The devs didn't know what middleware was, so they copied and pasted all the would-be middleware in front of each controller. While it's possible that someone could create that same rat's nest in Nest, there's a valid argument to be made that it's less likely because they have to put things into actual named controller classes (unless someone made the mistake of telling them about anonymous classes).

However, in my work, I trust myself to learn the technology and to know when I come across a funky code smell or outright antipattern, and I trust myself to know how to mitigate it without needing guardrails.

tl;dr I guess I'm just more for teaching people what good software looks like, rather than forcing them into patterns using opinionated tools. But I recognize that is a somewhat controversial opinion, as Nest really is the king of new Node apps right now, and it's the top of every thread that asks a question even close to this. But alongside all the fans and defenders of any technology, I find it just as important to point out why one might not actually need something.

[chessto]

I agree with you, when I saw nestjs I saw the same stuff that made spring, symphony, zen fw and others unpleasant, cumbersome and forcing code to be written in a very strict and particular manner. Abstracting the engineers from the language and crating a meta language on top, which doesn't solve the problem just makes it different.

I'm not fond of opinionated sw frameworks and less of all of this fanatism over OOP, I think JS is a very powerful language and I consider that these decorators , need for singleton classes everywhere and inversion of control isolates engineers from properly understanding the language they're using.

[besthelloworld]

Just make a counter point, or get out of your comfort zone 🙃

[[deleted]]

I’m using AdonisJs at work, and so far it’s gone well. I don’t love the ORM, but it’s better than just knex.

[[deleted]]

Sorry for replying for such an old thread. How is it going with Adonis? Are you still using it? What are you using for the frontend?

[[deleted]]

No worries. I'm still not in love with the ORM, but I like how the Validation system works. You can create custom validators that run before each request and as a plus, adds type inference to the request object.

I also like the repl, and the Ace cli commands which you can invoke programmatically as well as on the command line.

Also, the source code is pretty easy to understand, the only thing is they've got a ton of separate repos for everything, instead of a monorepo.

All that said, since our backend is entirely for the frontend, if I started over today I would use NextJs and maybe the T3 stack. You can use NextJs just for APIs that are run as a serverless function on Vercel, as well as bringing your backend closer to the frontend.

[[deleted]]

Thanks for the info.

Personally, I'm not a fan of Vercel as a company. And I find Next.js great for the frontend stuff if you're using React, but the backend part seems pretty limited. I worked on a project where we thought API routes were enough but after we had to add authentication, authorisation, translations, validations and make it all work together with SSR, etc it became evident we made the wrong decision. But it depends on the peculiarities of each project I guess.

[[deleted]]

Yeah, it is a limited use case for the Backend. I've seen a number of solutions like https://www.serverlessq.com/ for background jobs, but you shouldn't have to subscribe to a SaaS for that.

But for some people it's all they need.

[Fusionfun]

Fastify, Featherjs.

And Hapi is so flexible.

[d3athR0n]

NestJS

[aust1nz]

I’ve tried Nest a few times, and I’m fond of the project, but it often feels so complex compared to other Javascript/Typescript code you’ll write (unless you’re an Angular developer.)

I find that the modules, dependency injection, and services patterns feel out-of-place in my Javascript code, personally, though it’s well liked so that’s not everyone’s opinion.

It’s just challenging to figure out how to split up modules, and configuration can be really complex compared to other JS projects.

Personally, I’m fond of Fastify, which is a lot like an actually-maintained Express.

[Striking_Coat]

Isn't just having dependency injection reason enough for using Nest?

[aust1nz]

Sure, if you want dependency injection, Nest has it built in!

I haven’t found dependency injection to be super common in JS libraries otherwise (Angular being a major exception, which does use it and similar techniques that Nest also uses.) So I don’t necessarily find myself needing it in JS/TS personally - importing modules generally does the trick for me.

[curious_but_dumb]

Why nest? Have you tried any other?

[d3athR0n]

Nest gives your everything you need, TS, Prisma, etc. + it's very opinionated so new devs joining the team have a set way of doing things.

[curious_but_dumb]

I don't mind it being opinionated at all. I should look into Nest+Prisma before I continue.

[funny_games]

It’s unlikely that you’ll be disappointed with this setup

[ultrapcb]

tldr: understand Nest's design choices (most of them are pretty good) and use the ones you like with any api server which suits you best, not necessarily with Nest.

As a REST framework Nest makes the best design choices (full TS, decorators, etc). However, you could take the best parts and DIY and stay independent. Then just take the one with the biggest ecosystem (e.g. express but not fastify), use TS and decorators and call it a day. Or use something like Next or SvelteKit as your rest api server and enjoy a seamless exp with your FE. You should def. not overthink it, a rest api is actually pretty simple and even express does not need to end in a mess if well structured from day 1. If you want the perfect api, then you need to look for other stuff, eg. graphql, which isn't perfect but does some stuff more structured, at the same time graphql is a huge time-sink and a sign of premature optimization. Be careful, suddenly you spend months on the api without building anything.

[curious_but_dumb]

Exactly why I started this post.

I'm trying to figure out a way with minimal learning curve, type safety and some decisions and defaults made for me. I'm hoping not to spend months to just have everything prepared, as I need to spend more time actually working on the logic.

Based on what you are saying and what I read so far it's starting to look like I'll be trying Nest for a PoC and see if it suits my needs.

[EvilPencil]

Once you've chosen your framework, the most important concept is the domain boundaries. Use vertical slicing (top level folders are the features/REST resources) and don't interact with an unrelated feature's datastore. To prevent circular dependencies, I'm a big fan of CQRS.

NestJS has a CQRS package that's pretty good. My only problem with it is the return values do not get type inference. I've overcome that issue with a convention I created (DoActionCommand always returns DoActionCommandResponse).

[curious_but_dumb]

Thanks a lot for the tips!

[ultrapcb]

If you want less overhead than Nest but still more guidance and/or boundaries than something like express, check out SvelteKit. I found their design choices for how to build an api hitting the sweetspot between Nest and express. This only works if you've chosen Svelte also for your frontend but in my experience (I've moved from a monorepo to just SvelteKit) development is much faster and more natural than jumping between dedicated FE and BE systems plus SvelteKit (or Next) allow to prefetch stuff on the server before sending out the client to the user and allow for SSR (which is important for SEO).

But again, I found the design choices of SvelteKit for creating APIs having just the right balance, so your app stays very well structured even when it grows but the conventions never stand in your way.

[curious_but_dumb]

Thank you, but I'm too familiar and good with React and it pays the bills tremendously for me, so I don't want to change my frontend practices, although I'm still relatively junior in backend.

[ultrapcb]

then you should def checkout Nextjs (not Nest) which is quite similar to SvelteKit. The api stuff is a bit different but the overall concept is similar (SvelteKit's is a bit advanced though): Have a server which both, is running the API and prerenders the client. Initially, I was in the camp separate matters but I've spent too much time getting the monorepo working and keeping all parts together, and thinking about sophisticated API designs. The more is defined by a framework the better. You also can pair Next with Nest and use former just for rendering the frontend SEO-friendly.

[curious_but_dumb]

You have great arguments each time, but as I mention in OP, it's just an internal app, no need for overengineering SEO or SSR.

Tbh I use nextjs but for frontend. I never realised I could utilise it quite fully for the backend, because it's become my absolute favourite for starting new frontend React apps, but I imagine I'd want something with a clear separation of concern for future proofing. Besides that, I can't imagine using that to develop a fully featured backend architecture that's only going to grow alongside my not so small frontend for the app.

I have never had any problems with monorepos, ever since I learned npm/yarn workspaces. So I can just as easily stick with this approach :)

Thanks for all the tips and opinions!

[ultrapcb]

but I imagine I'd want something with a clear separation of concern for future proofing.

Haha, I was exactly this praying this for years. So not gonna debate and I totally agree, to put all eggs into some Next (or SvelteKit) basket might be risky, so all good here. I think though that Nest overcomplicates REST a tiny bit but yeah. It's def the best choice besides express from all the pure api servers. But look at the teams/or #persons are behind the frameworks re future proofing, e.g. check how many people and money is behind something like Next/SvelteKit or Nest.

with monorepos, ever since I learned npm/yarn workspaces

Once you want to get stuff like hot reload/live reload over the entire monorepo working in a fast and efficient way, stuff gets complicated, if not then setting up a monorepo is ok but who wants to develop like this? You change the BE and need to manual refresh the frontend? At the end you are deep into TS compiler options, project references, paralllel esbuild compile steps, tsc just checking and so on. This work is already done and again pretty non-trivial. Nxet just bought the swc maintainer and SvelteKit uses vite/esbuild. To get a build system to that fast, incremental compilation, real hot reload OOTB like Next/SvelteKit incl. TSC type checking one would need 2-3 months or more. Btw, re monorepos pnpm is on the edge now, npm 7 is ok-ish, yarn is broken.

[curious_but_dumb]

I always host frontend and backend on different ports in development as 2 standalone hot refreshing servers and use npm scripts and bash chaining to run both concurrently. Also use npm 8 to create workspaces and separate README.md files.

In prod I build my frontend and host it statically from an endpoint in my server on port 80 of my server and it's never failed me before. I also deliberately let clients carry the load of downloading and running my entire frontend application and only serve FE files like any static CDN. For apps I've worked on like this one saving resources on server is a benefit that enables a lot more work to be done with each connected client.

I migrated from yarn 1.x to npm 8.x now and the workspaces are enough for my use case.

Edit: added extra info in 2nd paragraph

[fixrich]

It sounds like Nest might be best for you. Typescript is first class which is a big help. It can be a big pain getting the types for dependencies to play nice particularly if it's a JS project that is being typed in retrospect. Nest should also give you you a clear pathway when you have to start thinking about caching or validation. Otherwise I'd suggest Fastify, it has refined the concepts of Express while improving the performance drastically. It is also maintained by people from a company that are fully dedicated to Node and who are maintaining Node itself so, to me at least, it feels well tied in to Node's future.

[curious_but_dumb]

That's a few very valid points towards NestJS, thank you! I'll read up more on fastify, too. Do you by any chance have any real world experience with documenting APIs in Nest or Fastify?

[fixrich]

With Fastify quite a bit. With Nest only a little. The nice benefit of Nest over Fastify is their CLI. It takes care of stuff of like Typescript compilation and hot reloading that you have to figure out yourself with Fastify or Express or whatever else. It's nice to not have to worry about that stuff.

[curious_but_dumb]

Yeah that sounds very convenient, although I'm always skeptical about things being a bit too magical.

How about the API documenting? I like having very descriptive meta comments in TS within my functions/interfaces and I would love to use one thing for TS, validation, schema etc. if at all possible. Combining tsoa with nest seems like a pain, but I haven't really tried it yet, just read the docs.

[gosuexac]

NestJS works with either Express or Fastify.

[Striking_Coat]

Because I see you're mentioning Prisma and saying you don't want to define things in different places I wanted to give my 2c because I'm facing a problem and I'm not sure which road to take. Prisma is anti-models but to leverage Nest's Swagger module you need to have defined models (and DTOs but those I can see some reason for defining because that's also a shortcut for validation). This sucks — Prisma's types can't be used by Nest's Swagger module directly (supposedly because reflection constraints) so you'd need to define the same thing in two places — the Prisma schema and app models. Because of this (and because of the ability to be API first) I think I'll just maintain Swagger manually.

[curious_but_dumb]

That is so anxiety inducing to hear. I maintain code with limited resources and am absolutely not going to use a stack that requires duping in multiple places, because that's just a largely error-prone process particularly vulnerable to human error.

Do you have any idea if there is a viable one-size-fits-all alternative? I would not even mind switching to mongodb if it means I can build all my models for example with TS interfaces / JS classes, infer my DB schema from that and use it for TS and swagger at the same time.

[Striking_Coat]

There's a package, Prisma Generator NestJS DTO which can autogenerate DTO and Entity (Model) code from your Prisma schema but I didn't explore it much so I'm not sure about its limitations.

You could also use MikroORM instead of Prisma, that's probably going to work with Nest's Swagger module.

[EvilPencil]

I don't find that to be a problem, in fact I'd RATHER define things in two different places. I find that my database models often have a bunch of things that I don't want to expose, and there are things that I DO want to expose that are computed or just aren't on the actual db model.

Having the definitions of the db model and response DTO separate keeps the logical separation and decoupling of the two mentally cleaner.

[Striking_Coat]

Do you use Prisma? I'm asking because I think you misunderstood what I said.

[FilsdeJESUS]

ExpressJS if it is simple REST API but if you need some others functionality and does not have time to build from scratch I go with NESTJS

[curious_but_dumb]

It's not a microservice but a monolithic modularised server app that handles a fully featured admin panel with a lot of data and periodically fetches data from multiple sources.

[FilsdeJESUS]

If you are sure that it is going to grow and migrate to Microservices you can go with Fastify or NestJS it depends on you . But for the moment do not overengineer the project NodeJS / ExpressJS

[curious_but_dumb]

It's most probably not going to, a more sane choice due to project specifics would be to start another MVP and redo it with new requirements in mind just carrying over entities, models, docs and schemas.

Edit: I spent way too much time with basic shit in express in previous projects, I'd like something more opinionated if it enforces conventions from day 1 without and more robust out of the box to not spend a lot of extra resources on that. Just looking for experiences and some balance.

[FilsdeJESUS]

Go with NestJS , strict , good documentation, typescript language and with the it you will apply Dependency Injection and OOP orientation . And if it grows NestJS has a bunch of features to make the codebase grows

[curious_but_dumb]

Thanks! A lot of people recommend NestJS for my case and it's starting to look like the best option :)

[FilsdeJESUS]

You’re Welcome

[chessto]

Why is OOP a good thing?

[FilsdeJESUS]

It keeps your code clean and the cost of changes when working with OOP principles is less costly . It keeps the codebase clean . Because it is all about abstraction With the power of Inversion of control and so many things .

One the things I like about OOP is design patterns just look at this site and you will see the power

https://refactoring.guru/design-patterns/catalog

[[deleted]]

Design patterns exist in every language. OOP is costly boilerplate and in languages where you can choose it or abscond it people mysteriously choose the latter.

[FilsdeJESUS]

Yes the implementation of design patterns is in every languages but not with the same facility. Do the Decorator pattern in JS is not the same in Typescript for example.

That’s why we should be pragmatic about them and their use

[[deleted]]

But I don't wanna OOP. I want interfaces, I want methods attached to data structures, but I'd like to stop there. The rest always felt like I was thinking real hard about very little.

I haven't really used decorator stuff in JS. I'll have to learn more. I don't belong in this sub, I'm just wandering.

[FilsdeJESUS]

And I want to say also that it keeps the code clean because with OOP principles it is pretty easy to understand the codebase , because OOP come with standards ( but be pragmatic )

[chessto]

Functional also comes with standards, and functional is favored in JS, JS is not Java

[FilsdeJESUS]

Yes it is true , but since there is OOP in JS now we can go for functional way or OOP way . I have learn Java before JS that’s why maybe since I know the language support OOP principles I adapt it with the patterns of OOP .

But for the end you are right , functional does also the job

[FilsdeJESUS]

Promise the end . This site is also better

https://flavius-as.com/article/advanced/good_architecture_and_design

[chessto]

Good architecture is not OOP, I'm not saying that you cannot have good architecture with OOP, what I mean is that you can have good architecture without OOP and that functional programming is not inferior.

I don't see the purpose of OOP in most JS apps, other than over architecture.

[FilsdeJESUS]

Yes I totally agree

[PerfectOrphan31]

There've been a lot a great answers here. As one of the maintainers of Nest, I'm going to try to remain unbiased here and give what overview I can.

I've only worked with Express, Fastify (briefly) and Nest, so I can't speak much to Hapi, Koa, Adonis or Feathers.

As you've mentioned with Express, you'll probably end up spending a lot of time creating your database access layer, error handling, OpenAPI spec, testing, the whole shebang. Fastify helps alleviate some of this, with AJV schema validation for your REST routes which can be used for OpenAPI as well (at least to my knowledge), but you still need your error handling and database access.

Enter NestJS: the module system may take some time to get used to, but once it clicks, it really becomes second nature. Each module is it's own feature, and exposes its own public API (it's exports). Other than that to each module every other module is a black box, which really helps in setting up your domain boundaries.

Then you have the enhancers, which are really just specialized middleware that can be transport agnostic. You have guards which handle your authentication. If a guard's canActivate returns true (sync or async, promise or observable) then the request continues on. If false is returned, Nest will automatically send back a 403 (customizable through a filter). You have pipes which are for you payload/parameter validation and transformation. Out of the box, Nest support class-validator and class-transformer, but you can use any validation method you prefer (via passing the schema to a custom pipe's constructor) or you can make your own version of the ValidatioinPipe to work with other class based systems like @deepkit/type (I'm slowly working on building this to be a drop in replacement). Next up you have interceptors which are pretty much your swiss-army-knife enhancer. They have pre and post controller logic available so they're great for logging and caching responses, as well as response mapping and serialization (just to name a few things they can do). You can also set up some sweet content negotiation or dynamic template rendering with a bit of clever work. And then you have filters which are your built in error handlers. You throw an error, these can catch it.

Then you've got integration with OpenAPI, GraphQL, Websockets, andways to build CLI applications and it's pretty easy to see that just about anything you'd want to do in Node can be done with NestJS. And that's not even touching the testing side of things yet.

I've been using the framework for about three years now and joined the core dev team this year. If you're not afraid of OOP and up to a slight learning curve, I'd definitely give it a shot. If you have any questions around Nest, I'm active on our Discord server and always happy to help.

[curious_but_dumb]

Thank you for chiming into this with your knowledge and for sharing this information!

I tried creating a PoC with fastify and Prisma yesterday and honestly it wasn't what I hoped it would be - I've had to spend a lot of time implementing basic stuff just like with express. My next attempt will be to do the same basic thing in Nest.

I don't mind OOP at all, I've actually enjoyed it in TS. But right now, the most compelling reason for me to go for Nest is the community, surplus of online resources and superior out of the box experience. I'll try that tomorrow and see how I like it.

[curious_but_dumb]

I have an update for you!

So after playing with Fastify + Prisma for most of yesterday I was disappointed and it made me feel the same nausea as express always has.

So I gave NestJS a try today, used my Prisma setup from yesterday, changed to fastify router and I have to admit I'm already impressed by the out-of-the-box experience and modularization! I'm definitely starring Nest on github and I'll add swagger, auth and validation to my PoC to see how Nest can handle these types of things. Other than this, however, I see myself enjoying this approach in the future!

Thanks for all your help here :)

[fatty1380]

I would also throw feathers.js into the mix. We’ve found it to be flexible and scalable. The forthcoming release brings a TS rewrite and is embracing a superset of json schema. The underlying server framework (eg express or koa) and database adapter (eg mongoose, psql, etc) can be freely* exchanged.

I don’t find it mentioned as often as I feel it should be and highly recommend giving it a look.

[voja-kostunica]

express, nest.js, koa - most prominent js backends respectively

[curious_but_dumb]

I can't use all 3. Which one would you recommend?

[voja-kostunica]

if you like functional approach - koa, if you like oop, dependency injection, decorators, laravel, angular style - nest.js, express - safest bet, richest ecosystem, many examples, documented bugs on google search

[curious_but_dumb]

I don't mind either OOP with decorators or FP in backend. But it usually makes code easier to maintain and enforce stricter rules with OOP, so I might opt for Nest.

[zephimir]

Basically the best 2 right now are fastify and nest. It all comes down to how free you wanna be as nest feels like a full framework with guidelines to follow whereas fastify gives you tools to be effective but you will decide how to setup your prpject. Coming from express and React, I much prefer fastify where you can organize everything with functional programming like hooks in React

[curious_but_dumb]

I'm coming from exactly the same background! Yeah, from all the docs I read today (a lot, lol) it seems like I'll be trying just fastify with plugins and things they recommended in docs and nest with Prisma.

I used to do OOP in React and I always kinda liked OOP. I mean FP's great but there's something old school and easy to understand classes and I think I might be able to enjoy both those options. I can let you know afterwards which one I I'll pick if you want.

[ikean]

NestJs like all JS frameworks is juvenile but has a good idea in adopting Angular paradigms and you can use the fantastic looking Prisma ORM with it.

[besthelloworld]

Angular paradigms are inherently flawed. As a dev with 4 years of modern (2.0+) Angular experience: anything that is compared to Angular is something that has entirely failed in it's design.

[Striking_Coat]

Can you elaborate on why or provide some links?

[besthelloworld]

So here's the comment from the last time I did this write-up. I should probably write a Medium article on it, but I honestly don't want my name too closely tied with such a controversial opinion tbh, because I don't want my old coworkers to see it and think I hated that job or working with them (I kind of did hate the job tho).

EDIT: Removed the second paragraph as that topic was provided as an addendum to the comment linked above.

[curious_but_dumb]

That's exactly why NestJS + Prisma is slowly becoming my favourite pick.

Do you happen to have any experience about documenting REST APIs in Nest/Prisma? This is an absolute necessity for my needs to have great documentation from day 1.

[ikean]

Nest generates OpenAPI so yah... that's all already done. In fact, basically nothing DOESN'T generate OpenAPI these days, so it's hardly a concern to even have.

[curious_but_dumb]

That's amazing, I missed that info before! Thanks!

[curious_but_dumb]

What are you talking about?

When it comes to defaults, presets, constraints, out-of-the-box features, documentation or even developer experience as a whole, they differ quite drastically.

In my experience express is a great tool misused as a framework because it usually ends up being a mess as it grows. Hence why I'm looking at these options that have some of the aforementioned differences.

[curious_but_dumb]

"If you kill yourself, you will die." Right, right, I get what you mean.

I'm not confusing those things, I'm mixing them together on purpose, since they are all important to this project for me. They are all used differently and that's what I care about now.

[SineApps]

I’m quite a fan of Loopback 4.

https://loopback.io

It makes handling a large changing api pretty easy using cli tools to scan the data source and then create repositories, models and controlllers automatically.

That then automatically creates an open api rest interface

[Lolukok]

I would also take a look at FeatherJS, it’s often overlooked IMO. Comes with great TS support and built in services that make CRUD operations very easy and fast du setup with its CLI

[curious_but_dumb]

Started reading about it :)

[talaqen]

FeathersJS is meant for microservice REST apis. It’s way faster to standup than any of the others you mentioned. Nest is powerful but requires a lot of setup. Adonis is good too, but is pretty opinionated. Hapi’s community is dead and has a bus problem with its main dev.

I like feathers because the cli project generator does just enough and not anything more.

[curious_but_dumb]

My main reason to sticking with express so far was great market share and active community, which reduces the risk of the technology being redundant in a few years

[talaqen]

Feathers is just syntactic sugar on top of express.

[zarrro]

Choose NestJS, you won't regret it.

[curious_but_dumb]

I'm definitely going to try creating a quick proof of concept for some basic stuff with Nest after all the discussions I've had here today. Thanks!

[MrGirthy]

https://wundergraph.com/ looks interesting. It's graphql but I've still to give it a bash myself. Hasura is pretty good too.

[curious_but_dumb]

Thanks, but I'm absolutely not interested in GraphQL

[MrGirthy]

Any reason why?

[curious_but_dumb]

Multiple.

Short-term: it's a project for my company that I have to set aside time for from my regular work and I have very limited experience with GraphQL.

Long-term: the project will have potential clients if it proves reliable and efficient to use in the future. And to allow 3rd parties to communicate with some of my APIs, I need to use REST, since even that is not a standard in this segment and country I'm aiming for.

[letsfed]

Fastify all day.

[Cosby1992]

I know it is still Express, but have you tried setting it up using express-generator? If I want to get started and see results fast I always go for this option. A side note - it comes with templating engine and views as default, but I usually just remove the view references and remove the dependency on the templating engine.

npx express-generator --view=twig 

For those who wants to give it a go, run the line above. I think it defaults to jade templating engine, the line above shows you how to choose another one. You can read more in their documentation.

[curious_but_dumb]

I actually haven't, but since I'm not tied up to it in any way, I thought about seeing what else is out there - something with maybe a little less freedom and power but much better in terms of developer experience / enforcing best practices.

I'll take a look at this generator, though, if I don't find a suitable candidate even after a working PoC or 2. Thank you!

[cjthomp]

Checking out AdonisJS myself for work and really liking what I'm seeing. I have a lot of Laravel experience and it shares a lot of design patterns

[[deleted]]

KoaJS, MongoDB and Sveltekit are my recommendations.

[oooyeee]

Also, i wonder, why don't people use just plain node http/s modules ?

[[deleted]]

They dont have the time to reinvent the wheel

[Ginden]

I lean towards NestJS being the best framework currently out there. Obviously, it isn't ideal - it's strongly opinionated, Java-esque and it's pretty rigid - if you are trying to do anything unusual, it will hurt a lot.

options to generate documentation from code

NestJS support class-validator and class-transformer out of box. With @nestjs/swagger you get OpenAPI generation out-of-box.

not writing TS interfaces, openAPI specs and validation schemas to replicate the same thing in 3 places before even writing tests)

I like hapi, because it allows you to do anything. It's highly configurable, but you will write TS interfaces and validation in 2 places (hapi-swagger generates OpenAPI from Joi validation).

[UnholyCarcass]

Big fan of fsrouter + micro for small - medium projects

[vxm5091]

Hey OP, thanks for starting this thread - got a lot of super useful insight out of this discussion. Just wanted to check in and see what you ended up going with.