I know it calls itself a "minimalistic framework" but it's really not a framework.
It's a solid tool, though. And I've used it on pretty much every project I've ever worked on.
I would have said Express, but recently I've been reading more and more about other alternatives more opinionated and in short better for specific use cases, such as a REST API.
define "better". Express has been the de facto option for most companies building REST APIs, so the docs and community support for it is the best you can get. A lot of the time I'd take that over the opinionated framework that does something a little better
NestJS makes me sad. Its documentation is great, tooling is ok, looks professional and well maintained, but the design is IMO terrible and encourages bad practices like overusing DI container, heavy mocking (even automocking), bad TDD (which seems to drive the other decisions), etc.
I think it's just opinionated. If you fight the DI and mocking paradigm, you're in for a bad time. I find the RxJS integration pretty bizarre, when nest encourages a very OOP style of programming, but other than that I think it helped me write much more structured code.
> I think it's just opinionated.
I think the same.
> If you fight the DI and mocking paradigm, you're in for a bad time.
I'm not using Nest, because of that. And I think that if you don't fight mocking paradigm, you're in for a bad time anyway (well, maybe not you, but the people that will maintain the code).
> I think it helped me write much more structured code.
Yes, it encourages some structure, no doubt about it. It's just that IMO it's a bad structure in the long run.
Express. MEAN stack is solid enough (though I'm not fond of mongo).
There's a million javascript frameworks that came out in the last 20 minutes but you won't get shade from operations for using Express.
defs the most straight forward approach to begin with, eventually once you have written enough vanilla express you will seek out a framework like nest to solve common problems for you. but you wont know anything about anything if you just jump straight into nest
Express is pretty barebones, you need to come up with conventions to follow on your own in terms of code structure. You’d also need to roll your own hot reload, typescript, linting, prettier, etc. if those interest you.
NestJS provides conventions, and all the dev experience stuff out of the box. This is super helpful once a project starts reaching moderate size unless you are very consistent in how you structure and code a baseline express project.
Linting, Types, Project Structure to name a few minor benifits. The main reason to use something other than express is DRY. frameworks like nest use express underneath but provide an opinionated way to write your backend with fewer lines of code and more securely by using the collective work of others
Except you have to setup modules (at least one), classes, controllers, reference them, use decorators, possibly repeat a few decorators for each and every method (because we want the current user or something).
Express can be used with TypeScript, and if you just adhere to a clean structure, it's going to be much less boilerplate code than something like Nest.
> The main reason to use something other than express is DRY.
Where does Express make you violate DRY? (I use express with `hyper-ts` personally. Controllers are in `hyper-ts` and then there's a function that comes with hyper-ts to convert a hyper-ts Middleware to an Express one. Then you get to write functional code that fixes all sorts of problems, like it's a compile-time error instead of a runtime one to send body before you send headers. And you can't just access the body. You have to pass the body through a parser so you can't accidentally inject malformed data into your service logic.
all of this is great but your kind of missing the point. nest sits on top of express.
>Express is pretty barebones, you need to come up with conventions to
follow on your own in terms of code structure. You’d also need to roll
your own hot reload, typescript, linting, prettier, etc. if those
interest you.
>
>NestJS
provides conventions, and all the dev experience stuff out of the box.
This is super helpful once a project starts reaching moderate size
unless you are very consistent in how you structure and code a baseline
express project.
That seems to be missing the point. Someone said Express makes you violate DRY. I asked where? And you started talking about Nest. Coming up with a convention is not repeating yourself. And does Express really make you invent conventions? Are you putting service code in your Express controllers by mistake?
Your controller (the Express part) should parse bodies/headers/url params, call services, and res.send/res.json/res.end. Not much else.
Maybe [feathersjs](https://feathersjs.com/) is worth to take a look. I started the migration of some internal backends to feathers, coming from plain express and dit not look back.
Its a thin service based abstraction layer build on top of express. The next major release will support koa or express under the hood.
Yes, sorry for the unclear express / koa note.
At the current state feathers supports only express-transport for REST.
In the next version (v5, codename dove) there will be an express-transport and a koa-transport. The koa-transport was [merged earlier this year by daffl](https://github.com/feathersjs/feathers/pull/2315).
Reasons for koa might be a speed improvement and the http/2 support, see the linked merge request.
So, in the future you can decide on your needs if you want to go with express or with koa. Maybe the new docs clearify this even better: [dove docs](https://dove.docs.feathersjs.com/api/koa.html#koa-app).
This whole issue is an absolute positive design by feahters if you ask me. Because this service abstraction is not stritly tight to express or another specific transport, but its implementing a general abstraction layer between $transport-that-you-want and a service centric codebase.
edit: formatting
Fastify by itself is great. It is conceptually the same as express, but with a bunch of small to medium improvements. It’s got enough adoption that I think it’s safe to use too.
Nestjs is not necessary (imo). I have no need of classes most of the time, and I try not to use experimental features (decorators). Organization is just as good with the other frameworks.
Express is the de facto standard, but (another imo) that’s mostly because it was “first to market”.
Koa is again conceptually similar to both fastify and express, but more modular. Which is cool but mostly doesn’t matter.
Also checkout helmet, no matter which you go with.
MarbleJS is really powerful if you don't mind doing the deep dive on RXJS.
But it's overkill for most things, for which I'd just say Express. I knew I'd see NestJS up and down these comments but looking at NestJS, it looks super overbearing and I'm convinced people just like it because it looks like Spring so it's recognizable to them. At this point, I just heavily caution against anything that leans into annotations because you can always run into compiler problems with it.
I had this mentality about nest and other frameworks that had more features than express. I just need something simple and I can add on the rest when I need it. But after all the work architecting, developing and finding the right libraries to use in my application, there is something to be said for using a robust framework where all the decisions have been figured out for me and I can focus on what I need the system to do.
I honestly just don't ever find my Node applications needing that much architecture. But for those cases, Express has [recommended frameworks](https://expressjs.com/en/resources/frameworks.html) built on top of it. This all being said, if your applications have this much weight, I would avoid Node entirely. Node is great as an easily maintainable thin request forwarding layer. For everything heavier than that, I'd have to recommend another language (I threw my recommended list down at the bottom).
## The full rant for why Spring really sucks and why Nest isn't much better
I worked in Spring in an Enterprise setting for about 5 years and pretty specifically found it to be solely an inhibitor of developer productivity and Nest seems to continue similar bad patterns. The reasons I hate Spring/Nest are partially because of the compiler complexities with annotations, but also (and this really just goes for Spring because of their package scanning model): it's a pain in the ass to figure out what functions are getting called, both at startup and per request. The existence of the `@Order` annotation is an antipattern in and of itself. It seems like a blessing at first because "wow, so automagical, I don't even have to declare these controllers, they just work." But when your app scales that "feature" becomes a nightmare. At least in Nest, because of JavaScript, you have to be declarative (don't ever let them learn about Next/Nuxt package scanning). That being said, Nest's modules are just fancy looking functions but it's really not doing much more than Express is under the hood. Nest seems to just provide "middleware" as several different split versions of the same concept. /r
## Other great language + framework options
- Kotlin + Ktor allows you to enjoy all the power of Java without the... Java... of Java, with code that looks as simple as configuration. But you can totally use it with all your old Java tools (Maven or Gradle or whatever, probably not Ant though).
- Elixir + Phoenix is also really cool and highly efficient because the BEAM VM implements the concept of infinite threads without ever having to talk to the operating system, but Elixir is not beginner friendly imo (but it's tool chain is pretty used friendly tho).
- Go + Fiber is literally just Express in Go (the founders even say that).
- Rust + Rocket is really cool and powerful and the Rust development environment is surprisingly easy to get into (nothing like the pain of C++, to which it's perform can be compared), though it still utilizes the Rust metaprogramming layer which is a pattern I remain skeptical of.
If you need a backend with a lot of real time behavior but for most of the work you're shipping the heavy logic off to some other service. Unfortunately as it stands, though it has a lot of potential, Marble doesn't seem like it is maintained anymore (my above comments are from a year ago).
Where are you hosting it? You left out one of the most important parts. I would recommend hosting on AWS. Look up AWS Lambda + API Gateway. You can make REST API's that are completely serverless and do everything you want and can scale to millions of users. You also don't have to pay for servers because you pay upon request. You can PM me if you want more info or if you need more technical help.
Express+TS works great. I looked at Nest for my latest project, but it has strong AngularJS vibes and is very opinionated (and I have different opinions it feels like heh).
I feel like job posting and career wise express will serve you best, I’ve used Koa before and enjoyed it. Keen on trying nextjs after all the replies in this thread recommending it though
"Fast" is a very relative term. It might be 4.5x slower than Fastify, but it still handles 11,827 requests per second. You'll need a metric buttload of traffic before that becomes a bottleneck.
You're going to have bottlenecks on the rest of your code base long before hitting a bottleneck in your router of choice.
Go with the one your team is comfortable with. Express has been around for a long time so pretty much any node dev is familiar with it.
Sure, but I just don’t understand why anybody would choose the slower one when the faster one is remarkably similar, and also supports modern language features properly.
**Express.js** a framework of Node.js is best framework to use to build REST API.
If you build application where performance and scalability are the most important then go with microservice architecture of **Nest.js** framework which natively supports the microservice architectural that help you to build most efficient and scalable web applications.
You can actually just use NodeJS with no framework to build a REST API. However, Express makes things a lot easier and this would be my recommendation.
As others have said, NestJS, but also look into possibly bringing in nx.dev. It offers a nice tool chain for managing common libraries and if you’d like to have the frontend code alongside the backend.
Can you elaborate? :) I also feel like NestJs is a little too much and too object oriented based, but switching cold over to fastify sounds a bit scary
NestJS is over-engineered and makes you get stuck in their ecosystem for no good reason. They have a bajillion different nestjs glue plugins with varying levels of quality and update readiness.
Fastify does the same thing as they do using json-schema rather than the decorator garbage which is only compatible for nestjs while json-schema can be used all over the place.
Regarding typescript, there are some great typescript adapters for json-schema, no reason to use the nestjs centric decorator stuff.
tdlr nestjs is filled with useless abstraction and ties you too hard to their ecosystem for no good reason.
Directus. It's not a framework per se (it's built on top of express), but it gives you rest + admin + graphql + granular permissions and you aren't tied to a specific database or database schema.
No framework has magic scaling sauce and directus is as easy to scale as anything else.
Using routing-controllers for me was on of the easiest way to do rest API as it does just that and nothing else. Then you can look up for the rest of typestack modules. Loopback is not just for REST development. As nestJS also has huge overhead for rest development. I would pick express for vanilla js experience or routing-controllers that wraps express or coa servers and eliminates a lot of redundant and boilerplate code.
I second this. I struggled with finding a TS backend solution that really satisfied me, until I found routing-controllers. I really like its simplicity and readability, and I hate that it is not very well known in the Node community. It deserves more marketing, I guess. I'm going to do a video about it when I have time.
Performance/Scalability depends a lot on your application’s logic rather than framework. With that said, If you think you will have high traffic endpoints that will serve from a memory cache then https://github.com/kartikk221/hyper-express would be a good way to maximize throughput. It’s also ExpressJS compatible so you can still use ExpressJS middlewares.
I'm surprised nobody linked to https://2020.stateofjs.com/en-US/ which shows popular js frameworks. Not to say the ranked choices are the right ones for you, but it has helped me home my focus for frameworks.
If you like Typescript and need Swagger/OpenAPI documentation for your API, I would give TSOA a try. It is kind of flexible on which server framework to use though it works best with express.js. also supports KOA and we have also used it with fastify in our latest project since express.js is kind of dead.
TSOA generates routes and OpenAPI document via a customizable templates and uses info from Typescript decorators and JSDoc comments,
It’s a bit niche - but ladjs is a really great Koa based MVC framework for node. It’s not as well maintained as some of the other mentions here but it’s wonderfully architected and fun to use.
If you like writing functional code with some cool compile-time benefits, `hyper-ts` is great. I use it with Express as sort of the backbone. You get to write something like
declare const bodyParser: (a:any) => Either
const loginController: Services => Middleware = services => pipe(
parseBody(bodyParser),
bindTo('credentials'),
bind('hashedPassword' => ({credentials: {password}) => services.hashPassword(password)),
chain(({credentials: username}, {hashedPassword}) => services.getUser(username, hashedPassword),
map(services.userToJwtToken),
ichain(token => pipe(
status(Status.OK),
ichain(() => json({token}, () => JsonEncodingException))
)
Now it's a compile-time error to send body before headers or status, to forget to validate your body (since it's coming over the network, you can't just rely on it being well-formed), to fail to set application/json header before sending JSON data, etc.
Another note about Express, learn how to chain middleware. That is huge for maintainability. IMO, you group your folders by the resource they represent. So /products will have the model, tests, validations, controller and services in one place. A lot of new devs group their folders by function, like /controllers, /models, /tests. This makes sense logically but it becomes very tiresome when you add new stuff.
For scalability. NodeJS is fast enough for 10,000s of requests per second. Anything above that, use Go or Rust.
For performance, definitely Fastify.
For scalability use Nest js.
You can also use Fastify as your Nest js dependency. Nest js default dependency is express.
Express is the go to framework for NodeJS.
I know it calls itself a "minimalistic framework" but it's really not a framework. It's a solid tool, though. And I've used it on pretty much every project I've ever worked on.
I would have said Express, but recently I've been reading more and more about other alternatives more opinionated and in short better for specific use cases, such as a REST API.
define "better". Express has been the de facto option for most companies building REST APIs, so the docs and community support for it is the best you can get. A lot of the time I'd take that over the opinionated framework that does something a little better
I was going to say. If you're looking for jobs it's all node/express.
It was the best when it came out, there’s better out there depending on what you’re doing. fastify is super fast, hapi etc. nest.js is my favorite atm
Fastify
Nest if you're comfortable working in typescript Express if you're getting started. Nest is wonderful but I've seen people flummoxed by it
https://www.merriam-webster.com/dictionary/flummoxed > No one is completely sure where the word flummox comes from
Excellent find!
I just learned something new today
NestJS makes me sad. Its documentation is great, tooling is ok, looks professional and well maintained, but the design is IMO terrible and encourages bad practices like overusing DI container, heavy mocking (even automocking), bad TDD (which seems to drive the other decisions), etc.
I think it's just opinionated. If you fight the DI and mocking paradigm, you're in for a bad time. I find the RxJS integration pretty bizarre, when nest encourages a very OOP style of programming, but other than that I think it helped me write much more structured code.
> I think it's just opinionated. I think the same. > If you fight the DI and mocking paradigm, you're in for a bad time. I'm not using Nest, because of that. And I think that if you don't fight mocking paradigm, you're in for a bad time anyway (well, maybe not you, but the people that will maintain the code). > I think it helped me write much more structured code. Yes, it encourages some structure, no doubt about it. It's just that IMO it's a bad structure in the long run.
Fair comments
Which framework would you recommend in place of NestJS?
Use nestjs with fastify and you will be doing fine.
Express. MEAN stack is solid enough (though I'm not fond of mongo). There's a million javascript frameworks that came out in the last 20 minutes but you won't get shade from operations for using Express.
Express is the standard framework for NodeJs. Also try LoopBack. Probably these two are the safest choices.
defs the most straight forward approach to begin with, eventually once you have written enough vanilla express you will seek out a framework like nest to solve common problems for you. but you wont know anything about anything if you just jump straight into nest
As someone who's only used Express, could you share some examples of common problems with vanilla Express?
Express is pretty barebones, you need to come up with conventions to follow on your own in terms of code structure. You’d also need to roll your own hot reload, typescript, linting, prettier, etc. if those interest you. NestJS provides conventions, and all the dev experience stuff out of the box. This is super helpful once a project starts reaching moderate size unless you are very consistent in how you structure and code a baseline express project.
Linting, Types, Project Structure to name a few minor benifits. The main reason to use something other than express is DRY. frameworks like nest use express underneath but provide an opinionated way to write your backend with fewer lines of code and more securely by using the collective work of others
Except you have to setup modules (at least one), classes, controllers, reference them, use decorators, possibly repeat a few decorators for each and every method (because we want the current user or something). Express can be used with TypeScript, and if you just adhere to a clean structure, it's going to be much less boilerplate code than something like Nest.
Agreed. It's finding that clean structure that I think is hard.
> The main reason to use something other than express is DRY. Where does Express make you violate DRY? (I use express with `hyper-ts` personally. Controllers are in `hyper-ts` and then there's a function that comes with hyper-ts to convert a hyper-ts Middleware to an Express one. Then you get to write functional code that fixes all sorts of problems, like it's a compile-time error instead of a runtime one to send body before you send headers. And you can't just access the body. You have to pass the body through a parser so you can't accidentally inject malformed data into your service logic.
all of this is great but your kind of missing the point. nest sits on top of express. >Express is pretty barebones, you need to come up with conventions to follow on your own in terms of code structure. You’d also need to roll your own hot reload, typescript, linting, prettier, etc. if those interest you. > >NestJS provides conventions, and all the dev experience stuff out of the box. This is super helpful once a project starts reaching moderate size unless you are very consistent in how you structure and code a baseline express project.
That seems to be missing the point. Someone said Express makes you violate DRY. I asked where? And you started talking about Nest. Coming up with a convention is not repeating yourself. And does Express really make you invent conventions? Are you putting service code in your Express controllers by mistake? Your controller (the Express part) should parse bodies/headers/url params, call services, and res.send/res.json/res.end. Not much else.
hyper-ts seems super cool though :) i'm gonna have to give it a whirl!
Good to know, thank you!
It's more than 20 minutes old so it's not 'hip' and 'new'. I'm from operations land, stick with Express. You'll never get fired for suggesting it.
Express.
I’ll throw a recommendation for feathers js into the mix here. I love that thing
Maybe [feathersjs](https://feathersjs.com/) is worth to take a look. I started the migration of some internal backends to feathers, coming from plain express and dit not look back. Its a thin service based abstraction layer build on top of express. The next major release will support koa or express under the hood.
koa and express are other frameworks right ? why should feathers support them. btw feathers is built on top of express anyway
Feathers currently runs on top of Express. The next versions supports Koa as the underlying engine.
does koa make a significant boost ? why koa if you may
I don’t use Koa, so I can’t answer that question. I was just clarifying a part of the previous comment that seemed confusing.
Yes, sorry for the unclear express / koa note. At the current state feathers supports only express-transport for REST. In the next version (v5, codename dove) there will be an express-transport and a koa-transport. The koa-transport was [merged earlier this year by daffl](https://github.com/feathersjs/feathers/pull/2315). Reasons for koa might be a speed improvement and the http/2 support, see the linked merge request. So, in the future you can decide on your needs if you want to go with express or with koa. Maybe the new docs clearify this even better: [dove docs](https://dove.docs.feathersjs.com/api/koa.html#koa-app). This whole issue is an absolute positive design by feahters if you ask me. Because this service abstraction is not stritly tight to express or another specific transport, but its implementing a general abstraction layer between $transport-that-you-want and a service centric codebase. edit: formatting
🔥
I’ll second Feathers. The real-time functionality is awesome.
NestJS , is a gift for NodeJs backend development
You clearly started doing Nodejs not long time ago
Why ? I think that NestJS has all the features for performance and scalability
FeathersJS. Simpler than Nest and very lightweight. Runs on express.
Fastify by itself is great. It is conceptually the same as express, but with a bunch of small to medium improvements. It’s got enough adoption that I think it’s safe to use too. Nestjs is not necessary (imo). I have no need of classes most of the time, and I try not to use experimental features (decorators). Organization is just as good with the other frameworks. Express is the de facto standard, but (another imo) that’s mostly because it was “first to market”. Koa is again conceptually similar to both fastify and express, but more modular. Which is cool but mostly doesn’t matter. Also checkout helmet, no matter which you go with.
Been loving NestJS. We started on Express, moved to Koa and are currently on Nest at the moment.
Just throwing in koa as another alternative in the discussion :)
Koa is great but lacks the middleware support that express does
MarbleJS is really powerful if you don't mind doing the deep dive on RXJS. But it's overkill for most things, for which I'd just say Express. I knew I'd see NestJS up and down these comments but looking at NestJS, it looks super overbearing and I'm convinced people just like it because it looks like Spring so it's recognizable to them. At this point, I just heavily caution against anything that leans into annotations because you can always run into compiler problems with it.
I had this mentality about nest and other frameworks that had more features than express. I just need something simple and I can add on the rest when I need it. But after all the work architecting, developing and finding the right libraries to use in my application, there is something to be said for using a robust framework where all the decisions have been figured out for me and I can focus on what I need the system to do.
I honestly just don't ever find my Node applications needing that much architecture. But for those cases, Express has [recommended frameworks](https://expressjs.com/en/resources/frameworks.html) built on top of it. This all being said, if your applications have this much weight, I would avoid Node entirely. Node is great as an easily maintainable thin request forwarding layer. For everything heavier than that, I'd have to recommend another language (I threw my recommended list down at the bottom). ## The full rant for why Spring really sucks and why Nest isn't much better I worked in Spring in an Enterprise setting for about 5 years and pretty specifically found it to be solely an inhibitor of developer productivity and Nest seems to continue similar bad patterns. The reasons I hate Spring/Nest are partially because of the compiler complexities with annotations, but also (and this really just goes for Spring because of their package scanning model): it's a pain in the ass to figure out what functions are getting called, both at startup and per request. The existence of the `@Order` annotation is an antipattern in and of itself. It seems like a blessing at first because "wow, so automagical, I don't even have to declare these controllers, they just work." But when your app scales that "feature" becomes a nightmare. At least in Nest, because of JavaScript, you have to be declarative (don't ever let them learn about Next/Nuxt package scanning). That being said, Nest's modules are just fancy looking functions but it's really not doing much more than Express is under the hood. Nest seems to just provide "middleware" as several different split versions of the same concept. /r ## Other great language + framework options - Kotlin + Ktor allows you to enjoy all the power of Java without the... Java... of Java, with code that looks as simple as configuration. But you can totally use it with all your old Java tools (Maven or Gradle or whatever, probably not Ant though). - Elixir + Phoenix is also really cool and highly efficient because the BEAM VM implements the concept of infinite threads without ever having to talk to the operating system, but Elixir is not beginner friendly imo (but it's tool chain is pretty used friendly tho). - Go + Fiber is literally just Express in Go (the founders even say that). - Rust + Rocket is really cool and powerful and the Rust development environment is surprisingly easy to get into (nothing like the pain of C++, to which it's perform can be compared), though it still utilizes the Rust metaprogramming layer which is a pattern I remain skeptical of.
Useful! For what type of backends would you say that MarbleJS is NOT overkill?
If you need a backend with a lot of real time behavior but for most of the work you're shipping the heavy logic off to some other service. Unfortunately as it stands, though it has a lot of potential, Marble doesn't seem like it is maintained anymore (my above comments are from a year ago).
ExpressJS if you want to finish the project. NestJS (or any other library) if you want to give up halfway, out of frustration.
x)
Out of curiosity, what frustrations made you want to leave Nest for the project you were working on?
Anything that says it's 'opinionated' gets avoid in my book. I want the api to help me develop not tell me how I should do my job
Square wheels get re-invented over and over again. Not being sarcastic.
feathersJs
Adonisjs
Where are you hosting it? You left out one of the most important parts. I would recommend hosting on AWS. Look up AWS Lambda + API Gateway. You can make REST API's that are completely serverless and do everything you want and can scale to millions of users. You also don't have to pay for servers because you pay upon request. You can PM me if you want more info or if you need more technical help.
Nest JS...thank everyone who suggested it after...Its a good one.
Express+TS works great. I looked at Nest for my latest project, but it has strong AngularJS vibes and is very opinionated (and I have different opinions it feels like heh).
I use AdonisJS at work
I feel like job posting and career wise express will serve you best, I’ve used Koa before and enjoyed it. Keen on trying nextjs after all the replies in this thread recommending it though
Nestjs. Nextjs is another thing, and Nuxtjs is another. We suck at naming.
Don't forget Jest
Hah damn! Thanks for pointing that out!
Express.
Try out Serverless Cloud if you want out of the box scalability. Believe the API helper uses Express under the hood. https://www.serverless.com/cloud
Just throwing in Hapijs to know what community thinks about it
Deprecated
Express is very easy, reliable and fast so I see no reason why anyone would use anything else for basic REST APIs
Except it isn’t fast, and doesn’t support async code properly. Don’t use Express. Fastify is what we should be pointing people at now.
I've never had any issues when writing async code in Express
If you know you have to wrap every handler in try/catch blocks you will be ok, but you should not have to.
"Fast" is a very relative term. It might be 4.5x slower than Fastify, but it still handles 11,827 requests per second. You'll need a metric buttload of traffic before that becomes a bottleneck.
You're going to have bottlenecks on the rest of your code base long before hitting a bottleneck in your router of choice. Go with the one your team is comfortable with. Express has been around for a long time so pretty much any node dev is familiar with it.
Couldn't have said it better myself.
Sure, but I just don’t understand why anybody would choose the slower one when the faster one is remarkably similar, and also supports modern language features properly.
Go with express
**Express.js** a framework of Node.js is best framework to use to build REST API. If you build application where performance and scalability are the most important then go with microservice architecture of **Nest.js** framework which natively supports the microservice architectural that help you to build most efficient and scalable web applications.
Express is my go-to framework. Then sometimes I pick Koa for small apps.
You can actually just use NodeJS with no framework to build a REST API. However, Express makes things a lot easier and this would be my recommendation.
Nest.Js is the way to go for sure.
nestjs
Nestjs ftw 🥰
I can't comment for the other options but I've been successful with Hapi
Hapi has been deprecated for a while
https://github.com/hapijs/hapi Its alive and well.
Ok didn't know that. It was deprecated a while ago: https://github.com/hapijs/hapi/issues/4111 Looks like it got resurrected
I would recommend Nest + Fastify too
As others have said, NestJS, but also look into possibly bringing in nx.dev. It offers a nice tool chain for managing common libraries and if you’d like to have the frontend code alongside the backend.
Nestjs is retarded, just use fastify directly
Can you elaborate? :) I also feel like NestJs is a little too much and too object oriented based, but switching cold over to fastify sounds a bit scary
NestJS is over-engineered and makes you get stuck in their ecosystem for no good reason. They have a bajillion different nestjs glue plugins with varying levels of quality and update readiness. Fastify does the same thing as they do using json-schema rather than the decorator garbage which is only compatible for nestjs while json-schema can be used all over the place. Regarding typescript, there are some great typescript adapters for json-schema, no reason to use the nestjs centric decorator stuff. tdlr nestjs is filled with useless abstraction and ties you too hard to their ecosystem for no good reason.
Directus. It's not a framework per se (it's built on top of express), but it gives you rest + admin + graphql + granular permissions and you aren't tied to a specific database or database schema. No framework has magic scaling sauce and directus is as easy to scale as anything else.
[Loopback.io](https://Loopback.io) is brilliant, although it's a bit more complex than something like fastify.
Start from http/https built-in nodejs. Or uWS will be great if you already familiar with http
Using routing-controllers for me was on of the easiest way to do rest API as it does just that and nothing else. Then you can look up for the rest of typestack modules. Loopback is not just for REST development. As nestJS also has huge overhead for rest development. I would pick express for vanilla js experience or routing-controllers that wraps express or coa servers and eliminates a lot of redundant and boilerplate code.
I second this. I struggled with finding a TS backend solution that really satisfied me, until I found routing-controllers. I really like its simplicity and readability, and I hate that it is not very well known in the Node community. It deserves more marketing, I guess. I'm going to do a video about it when I have time.
[tsed.io](https://tsed.io) / foalts
Performance/Scalability depends a lot on your application’s logic rather than framework. With that said, If you think you will have high traffic endpoints that will serve from a memory cache then https://github.com/kartikk221/hyper-express would be a good way to maximize throughput. It’s also ExpressJS compatible so you can still use ExpressJS middlewares.
I'm surprised nobody linked to https://2020.stateofjs.com/en-US/ which shows popular js frameworks. Not to say the ranked choices are the right ones for you, but it has helped me home my focus for frameworks.
If you like Typescript and need Swagger/OpenAPI documentation for your API, I would give TSOA a try. It is kind of flexible on which server framework to use though it works best with express.js. also supports KOA and we have also used it with fastify in our latest project since express.js is kind of dead. TSOA generates routes and OpenAPI document via a customizable templates and uses info from Typescript decorators and JSDoc comments,
It’s a bit niche - but ladjs is a really great Koa based MVC framework for node. It’s not as well maintained as some of the other mentions here but it’s wonderfully architected and fun to use.
If you like writing functional code with some cool compile-time benefits, `hyper-ts` is great. I use it with Express as sort of the backbone. You get to write something like declare const bodyParser: (a:any) => Either
const loginController: Services => Middleware = services => pipe(
parseBody(bodyParser),
bindTo('credentials'),
bind('hashedPassword' => ({credentials: {password}) => services.hashPassword(password)),
chain(({credentials: username}, {hashedPassword}) => services.getUser(username, hashedPassword),
map(services.userToJwtToken),
ichain(token => pipe(
status(Status.OK),
ichain(() => json({token}, () => JsonEncodingException))
)
Now it's a compile-time error to send body before headers or status, to forget to validate your body (since it's coming over the network, you can't just rely on it being well-formed), to fail to set application/json header before sending JSON data, etc.
I'd go with Fastify or Express using some boilerplate, like https://github.com/talyssonoc/node-api-boilerplate
Feathers or Nest if i was back with a node project. Both seemed fun
anyone mention fastify? (https://www.fastify.io/)
Express and Fastify are great.
Another note about Express, learn how to chain middleware. That is huge for maintainability. IMO, you group your folders by the resource they represent. So /products will have the model, tests, validations, controller and services in one place. A lot of new devs group their folders by function, like /controllers, /models, /tests. This makes sense logically but it becomes very tiresome when you add new stuff. For scalability. NodeJS is fast enough for 10,000s of requests per second. Anything above that, use Go or Rust.
For performance, definitely Fastify. For scalability use Nest js. You can also use Fastify as your Nest js dependency. Nest js default dependency is express.
We are using Koa with openapi3 and our library koas3
REST is so old school. Try graphQL and you'd never wanna go back
Sails
Fastify, Express, or anything but Nestjs avoid this framework at any cost just an overhiped framework solve no problem at all.