#Why is NestJS using express as default?

1 messages · Page 1 of 1 (latest)

dreamy rain
#

I have read that NestJS developers decided to still use express as default. And i dont get why.
At the moment i have a default project and my main thoughts are now, how can i improve my project and make everything faster? So i found out that i have the choice to use fastify, what is really cool. But i have now to implement it and change some of my code.
Its obvious that the perfomance from fastify is much better then from express. Isnt that what everyone wants?
I mean, express is widely used, yes, but its much slower and i cant see any benefit of using express, just because in NestJS we dont use express itself very often. Its nice for middleware, but there are better solutions.

Do the developers have any thoughts to maybe switch to fastify?

Im a bit frustrated that i have a project and to get the most out of it, i have to rework some of my code now. Didnt know, as i started with the project, that fastify is in many things just better.

olive carbon
#

only Kamil can answer this

gusty swift
#

I can give some reasoning, but Kamil will always have the final say here

olive carbon
#

I'm pretty sure that this is related to the popularity of ExpressJS over any other lib/framework

#

and I don't think that the main goal of nestjs is to be fast
The framework introduces overhead on the underlying http lib, so it will never be as fast as not using it

gusty swift
#

To be fair, the express ecosystem is generally more mature and more fleshed out. Fastify has a great ecosystem, but it's plugins are generally harder to abstract around, which makes it more difficult for Nest to as quickly and readily support. You'll find there's several integrations that only work with Express (Apollo I'm pretty sure, though there's Mercurious and Yoga instead). Passport (fastify/passport exists, but it doesn't work out of the box with @nestjs/passport), multer (similar story here). Express was also the default when Nest was created so Kamil hasn't necessarily been gung-ho aboutt swapping over, more just about adding support.

Also, by the time you add everything in, validation, interceptors, filters, actual logic, the throughput of Express vs Fastify is almost negligable. Sure at a simple "Hello World" you'll see a difference, but that's not really where you'll find gains unless you're trying to do microadjustments. Simply put, for the most part, Express is good enough

dreamy rain
#

I mean everyone knows tobaco, but nobody should use it and smoke it. Popularity means nothing in my opinion. As example, wordpress is popular and many use it, but wordpress was never developed to be an CMS and it now has a lot of problems. Widely used or popular doesnt mean anything, when you want a good RestAPI.
Maybe im wrong, but who doesnt want a fast performing server?

olive carbon
#

I mean, popularity and mature

#

and this for sure is important in the nodejs ecosystem

gusty swift
#

And to explicitly address this:

who doesnt want a fast performing server
The underlying HTTP adapter is going to be a negligable gain in the grand scheme of things. Optimizing queries, making your database more efficient, making your code more efficient, that's gonna be more of how you get a faster server

olive carbon
#

to me, if you really need an ultra fast http server, you probably won't use nodejs. At least not back when nestjs was created

dreamy rain
#

Ok, im not really to deep in it, but when you search for things like that (performance) for NestJS on the internet, then you get so many results that explain that fastify is better.

olive carbon
dreamy rain
#

Hmm yeah i thought about using Go as webserver, but didnt want to learn a new language and framework

olive carbon
#

there is deno and bun tho

dreamy rain
gusty swift
#

And most of them benchmark a Hello World server rather than their fully fledged server with all the features

#

I mean, yes, you will get some performance increase, but it's not gonna be anything super insane

dreamy rain
#

As example i found this

fastify.webp
gusty swift
#

What what are the contents of the servers they are running?

dreamy rain
#

Hmm ok. I was very worried

gusty swift
#

Because try adding a database and you'll see the numbers diminish

dreamy rain
#

For my project i have maybe 100-400 active users when im lucky. So i could stay with express?
Recently i added some caching with redis to get faster responses and some other stuff.

olive carbon
gusty swift
#

Yeah, you should easily be able to handle 400 concurrent users

olive carbon
#

just try to not use express-specific libs in your main code so that you could switch to fastify easily

dreamy rain
#

What if i have more users? Lets say maybe 3000-5000? I mean that is unrealistic for my project, but it should still work

#

I use 1-2 middlewares and class-validator

#

Websockets are also a thing i want to use, but later

gusty swift
olive carbon
#

there is no way to predict that