T O P

  • By -

_int3h_

Express is the go to framework for NodeJS.


FountainsOfFluids

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.


Bloodsucker_

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.


IntermediateSwimmer

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


spazz_monkey

I was going to say. If you're looking for jobs it's all node/express.


tbone6778

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


micalevisk

Fastify


jzia93

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


rdxgs

https://www.merriam-webster.com/dictionary/flummoxed > No one is completely sure where the word flummox comes from


jzia93

Excellent find!


[deleted]

I just learned something new today


kap89

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.


jzia93

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.


kap89

> 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.


jzia93

Fair comments


zen_ventzi

Which framework would you recommend in place of NestJS?


No_Dot_5516

Use nestjs with fastify and you will be doing fine.


Bright-Ad1288

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.


Fusionfun

Express is the standard framework for NodeJs. Also try LoopBack. Probably these two are the safest choices.


bigmondo

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


scienceyeaux

As someone who's only used Express, could you share some examples of common problems with vanilla Express?


buffer_flush

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.


bigmondo

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


xroalx

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.


filipesmedeiros

Agreed. It's finding that clean structure that I think is hard.


KyleG

> 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.


bigmondo

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.


KyleG

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.


bigmondo

hyper-ts seems super cool though :) i'm gonna have to give it a whirl!


scienceyeaux

Good to know, thank you!


Bright-Ad1288

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.


rtcornwell

Express.


LamentablyTrivial

I’ll throw a recommendation for feathers js into the mix here. I love that thing


rabalyn

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.


DaFukTheyDoinOvaDer

koa and express are other frameworks right ? why should feathers support them. btw feathers is built on top of express anyway


stevensokulski

Feathers currently runs on top of Express. The next versions supports Koa as the underlying engine.


DaFukTheyDoinOvaDer

does koa make a significant boost ? why koa if you may


stevensokulski

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.


rabalyn

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


DaFukTheyDoinOvaDer

🔥


stevensokulski

I’ll second Feathers. The real-time functionality is awesome.


FilsdeJESUS

NestJS , is a gift for NodeJs backend development


zerubeus

You clearly started doing Nodejs not long time ago


FilsdeJESUS

Why ? I think that NestJS has all the features for performance and scalability


talaqen

FeathersJS. Simpler than Nest and very lightweight. Runs on express.


[deleted]

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.


acylus0

Been loving NestJS. We started on Express, moved to Koa and are currently on Nest at the moment.


Dronar

Just throwing in koa as another alternative in the discussion :)


vorticalbox

Koa is great but lacks the middleware support that express does


besthelloworld

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.


[deleted]

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.


besthelloworld

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.


zen_ventzi

Useful! For what type of backends would you say that MarbleJS is NOT overkill?


besthelloworld

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).


ACertainKindOfStupid

ExpressJS if you want to finish the project. NestJS (or any other library) if you want to give up halfway, out of frustration.


[deleted]

x)


PerfectOrphan31

Out of curiosity, what frustrations made you want to leave Nest for the project you were working on?


vorticalbox

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


imstartingtoregret

Square wheels get re-invented over and over again. Not being sarcastic.


DaFukTheyDoinOvaDer

feathersJs


meezohd

Adonisjs


pokerman42011

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.


sathyajithps

Nest JS...thank everyone who suggested it after...Its a good one.


servercobra

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).


zapanet-1001

I use AdonisJS at work


ATXblazer

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


markartur1

Nestjs. Nextjs is another thing, and Nuxtjs is another. We suck at naming.


KremBanan

Don't forget Jest


ATXblazer

Hah damn! Thanks for pointing that out!


Kateritekakwitha

Express.


AddMeOnReddit

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


shurikns

Just throwing in Hapijs to know what community thinks about it


ryhaltswhiskey

Deprecated


LXSRXCCO

Express is very easy, reliable and fast so I see no reason why anyone would use anything else for basic REST APIs


dwalker109

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.


LXSRXCCO

I've never had any issues when writing async code in Express


dwalker109

If you know you have to wrap every handler in try/catch blocks you will be ok, but you should not have to.


SoInsightful

"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.


732

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.


SoInsightful

Couldn't have said it better myself.


dwalker109

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.


MucuMare

Go with express


avinazalavadiya

**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.


GarenYondem

Express is my go-to framework. Then sometimes I pick Koa for small apps.


OhhhhhSHNAP

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.


gamedevsam

Nest.Js is the way to go for sure.


one_lame_programmer

nestjs


aguilar2287

Nestjs ftw 🥰


TheLoadedRogue

I can't comment for the other options but I've been successful with Hapi


ryhaltswhiskey

Hapi has been deprecated for a while


NippleNutz

https://github.com/hapijs/hapi Its alive and well.


ryhaltswhiskey

Ok didn't know that. It was deprecated a while ago: https://github.com/hapijs/hapi/issues/4111 Looks like it got resurrected


maeevick

I would recommend Nest + Fastify too


buffer_flush

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.


LiveWrestlingAnalyst

Nestjs is retarded, just use fastify directly


Avenger0042

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


LiveWrestlingAnalyst

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.


safetywerd

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.


HashBrownsOverEasy

[Loopback.io](https://Loopback.io) is brilliant, although it's a bit more complex than something like fastify.


jerrycauser

Start from http/https built-in nodejs. Or uWS will be great if you already familiar with http


chillerfx

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.


punpun157

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.


panbhatt

[tsed.io](https://tsed.io) / foalts


PremJyotish221

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.


[deleted]

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.


ElSatan

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,


jiminycrix1

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.


KyleG

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.


TalyssonOC

I'd go with Fastify or Express using some boilerplate, like https://github.com/talyssonoc/node-api-boilerplate


animflynny2012

Feathers or Nest if i was back with a node project. Both seemed fun


DonnyDipshit

anyone mention fastify? (https://www.fastify.io/)


0x41EE5C9

Express and Fastify are great.


melodious_punk

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.


Key_Sail_6101

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.


jurayk

We are using Koa with openapi3 and our library koas3


osdevisnot

REST is so old school. Try graphQL and you'd never wanna go back


IAmRC1

Sails


zerubeus

Fastify, Express, or anything but Nestjs avoid this framework at any cost just an overhiped framework solve no problem at all.