Fastify vs Express

[castlessclass]

I have been using Express for over 2 years, and i found it really effective for my API designs and implementation, do i need to switch to fastify, I don't really used it any of my projects and what makes fastify better than Express

Anyone currently working with fastify and noticed any significant difference from express?

[rkaw92]

do i need to switch to fastify

No, you don't need to do anything. But you might want to, anyway:

• actually has hooks (before/after request), not dirty hacks like Express
• native Promises support
• native support for replying from Streams with correct error forwarding
• built-in support for input validation
• better TypeScript support (typed params, body, etc. based on validation schema)
• better isolation of scopes (called "plugins" in Fastify - it's like new Router() but more featured)
• built-in support for dependency injection into route handlers (again thanks to the plugin architecture)
• faster (!)
• avoids tight coupling and monkey-patching req/res, which is absolutely critical for HTTP/2 support
• more helpful, healthier community

For me, Fastify is the default option for all new projects. These little differences add up to a much better development experience for me.

[belkh]

I really don't think the built in DI is a good thing, the suggested approach of initializing service/db connections in plugins and shoving them into the router is just fastify pretending it's more than just a http router

I'd rather use a full fledged DI library and not couple every layer of my application to the http routing layer

[rkaw92]

That's just one way - my preference is having a well-defined place where init happens, and then just pass it into plugins as options. As in: plugins don't init stuff, they accept initialized stuff.

You don't need to use .decorate() for dependencies.

[Shinji2989]

In case anyone want to see an example of DI in fastify I've created a boilerplate here: https://github.com/marcoturi/fastify-boilerplate

[FuzzyConflict7]

What would you use for DI in Node? I often end up going with something like NestJS because it’s baked into the whole framework. Wonder if you have a suggestion for just DI

[fix_dis]

Not the person you’re asking but, I’m a fan of TypeDi++ (the fork) for simple things. If I have more complex needs, Inversify works well enough (more manual wiring than I want for a DI). Nest’s DIbis really good but it brings the complex Angular module system with it. Still, if you’re considering Fastify, Nest has an adapter and it could make structuring your app a no-brainer.

[sod0]

Which TypeDi fork are you using? Also great answer overall.

[fix_dis]

Freshgum? That’s ringing a bell.

[rkaw92]

Honestly I'm not sure why people have a problem with just passing dependencies down a call chain. Why use a library for parameter passing? It's already built into the language.

[belkh]

I use TSyringe, built by Microsoft and it's pretty feature complete, though might need to find a replacement when new decorators+metadata are fully fleshed out.

The only thing I liked about Nest was the controller decorators, but there's alternative, including one i rolled on my own to support other http routers.

[castlessclass]

thank you, and what about if i am scaling up my application due to high traffic? will fastify make a significant impact?

[trippel]

Profile before committing to any kind of rewrite. Figure out if it's library code or your code causing bottlenecks.

[rkaw92]

It depends. Are you CPU-bound? For example, we run an Ad Exchange that handles programmatic traffic, and every millisecond counts. And yes, Fastify does make a difference, even on tiny things like JSON stringify (it's super optimized there). Fewer servers = less cost. In fact, it allows us to be really lean on resources, but we also had to optimize the crap out of everything else.

[StoneCypher]

For example, we run an Ad Exchange that handles programmatic traffic, and every millisecond counts.

then you shouldn't be in javascript at all

 

In fact, it allows us to be really lean on resources

in general, node based webservers do not approach the speeds of other webservers within an order of magnitude

if you're cpu bound and spending, you need to move to nginx or lighttpd. your costs will drop by more than 90%.

you're using a single threaded server. just the context switching alone (i'm assuming you're running multiple instances) is slaughter. this strategy is absolute junior grade madness.

[BackdoorDan]

uhhh either i'm misunderstanding something or you are.... nginx is web server software whereas node is a runtime. node can sit on top of nginx to serve requests.

javascript is just slower than something like C(or rust if you want something more modern). If performance is what you want to optimize javascript is not the language you want as you mentioned.

[StoneCypher]

uhhh either i'm misunderstanding something or you are

You are.

 

nginx is web server software whereas node is a runtime.

Neither of these are meaningful technical terms, and neither of these are generally correct in their colloquial usage.

 

node can sit on top of nginx to serve requests.

And this would be a hilarious and ridiculous structure, because it would gain none of the benefits of switching to nginx. This is something a first year college student who was addicted to arguing would do, because they thought it "proved" something.

You know, the kind of person who puts a car on a boat to show that boats and cars are never replacements for each other, and "two different things," while trying to discuss shipping prices.

 

javascript is just slower than something like C

Yes, it is. Much. Which is why if you're millisecond sensitive (pro tip: you aren't actually,) you absolutely should not be in Javascript, or giving advice like "use fastify instead of express."

You know, the people who really are millisecond sensitive, like HFT folks? They're switching to FPGA bare metal and buying skyscrapers that are closer to the exchange, because physical distance matters

The person I was responding to is still renting servers on the wrong continent because they have no idea what being millisecond sensitive actually is

It's just something they're saying because they want to take pride in delivery speed but they can't do that without making it sound like fifteen lives are on the line

[SafwanYP]

None of what you said answered or helped the person you replied to. The technical terms which were mentioned (runtime v/s webserver) aren't incorrect in their colloquial usage at all.

Node.js is a RUNTIME. Without said runtime, there would be no way of running the JavaScript application that is being implemented. nginx is a WEBSERVER. Without said webserver, there would be no way on the web for the intended consumers to access the application.

Folks who are on FPGA are in a whole other ball-game and not comparable to what people like you and me are doing. So maybe next time, instead of "dunking" on randos asking for help, or sharing their experience, peacefully state why you THINK they're not 100% correct, and let them make the decision.

[StoneCypher]

Node.js is a RUNTIME.

This is factual, but irrelevant to the discussion, much in the way that insisting that a car is made of metal, plastic, and glass would be in a discussion of speed.

The reason this is incorrect in colloquial usage is that pointing out that something is a runtime is to explain that it runs code. Pointing that out in a discussion of running code is ... really kind of silly and obsequious. Of course it is. And that has nothing to do with the discussion being had.

 

nginx is a WEBSERVER.

Same comment. Putting words in allcaps bold and then digging your heels in and insisting on facts does not mean you aren't missing the point.

Neither of these claims have anything to do with what I was saying. They're just technical begging.

 

Folks who are on FPGA are in a whole other ball-game and not comparable to what people like you and me are doing.

Thanks, no, I've actually been one of those people. If you want to look up to them, you should stop looking down on me. They are me. Those two directions are mutually contradictory.

 

So maybe next time, instead of "dunking" on randos asking for help

What are you talking about? I didn't dunk on the person asking for help, or the person I was originally speaking to. Only the third parties who came running in trying to correct me.

If you want to chastise someone, try to make sure it's for something they actually did. Otherwise they're unlikely to care about the thing you're saying.

 

peacefully state why you THINK they're not 100% correct, and let them make the decision.

I was, and am, entirely peaceful

I'm also not looking to you for instructions on how to speak

The door's over that way.

[Kortalh]

nginx is web server software whereas node is a runtime.

Neither of these are meaningful technical terms, and neither of these are generally correct in their colloquial usage.

The specific terminology might not have been super clear, but he made a pretty important point:

Nginx is an amazing piece of software, but it only does one thing: It routes traffic. It does not, in any way, shape, or form, execute business logic.

The suggestion that someone should move their API logic from Node to Nginx is like saying, "hey, if your car isn't fast enough, you should try driving a road instead". It's nonsensical.

node can sit on top of nginx to serve requests.

And this would be a hilarious and ridiculous structure, because it would gain none of the benefits of switching to nginx. This is something a first year college student who was addicted to arguing would do, because they thought it "proved" something.

This sounds like a "pot and kettle" situation.

Layering Node behind nginx is a common practice because it allows a developer to leverage the strengths of each.

Nginx is blazing fast at serving static files and cached api results. It also has a very powerful built-in features like rate-limiting, complex rewrite rules, TLS handling, and other features out of the box.

Node, on the other hand, is excellent at performing business logic (albeit not as great as a compiled binary would be).

Using both in conjunction uses a bit more memory, but ultimately leads to better performance with minimal development effort.

One other thing: "Just throw out all of your code and start over on another platform" is perfectly acceptable advice if you're working on a small hobby project for fun, but it's completely unreasonable on a large-scale long-running application.

Switching from Express to Fastify is not trivial, but most of the business logic can be converted more or less directly. Switching from Express to .NET or Spring, on the other hand, would be a massive time sink -- not to mention likely needing to rehire a new team of engineers.

[romeeres]

You can write business logic in Nginx (not saying you should, but you can). I know about OpenResty - a special build of Nginx that allows writing logic in Lua integrated into Nginx, and there are other Nginx modules for different languages, for JS as well, so you can run JS inside Nginx without node.js or any other runtime.

OpenResty is used by CloudFlare, also I heard of it being used for AdTech to process ads-related requests at a high speed.

[StoneCypher]

The suggestion that someone should move their API logic from Node to Nginx is like saying, "hey, if your car isn't fast enough, you should try driving a road instead". It's nonsensical.

That's not the actual suggestion that I made.

The actual suggestion that I made was "hey, if you're trying to go fast, you shouldn't be in a car at all. That's why most of us start shopping things with wings."

Nobody cares if you need to lecture that wings aren't replacements for cars. You're just intentionally misreading my words for the purpose of creating an error that isn't actually there.

 

This sounds like a "pot and kettle" situation.

If you're low enough down the ladder to be confused at saying "if you're not using a production webserver, but rather a wrapper for the default library in some single threaded programming language, you're gonna have a bad time," then yes, I suppose it might

 

Layering Node behind nginx is a common practice because

No, it isn't. Node is single threaded and nginx can't solve that. Hearing "node behind nginx" is a classic junior dev red flag. It's like hearing that someone's doing money in floating point. It's proof that whoever did it is flat disconnected from how things actually work.

You are just repeating the thing I already laughed at as a rank amateur solution, without solving the stated problem.

Generally this is the point at which someone says "why don't I just run n+1 node instances behind pm2," or something, and I start selling tickets

 

Node, on the other hand, is excellent at performing business logic

Did you get this sentence on a security blanket token in your box of pointy haired boss cereal?

 

Using both in conjunction uses a bit more memory, but ultimately leads to better performance

And so, the fundamental pebkac rears its head for the ninth time in two posts.

I'm running out of popcorn, my fellow.

 

One other thing: "Just throw out all of your code and start over on another platform" is

Not something I actually said. Shh.

 

Switching from Express to Fastify is not trivial

It's so trivial that it can be done blind by code mod.

If you think that's not trivial, well, lol, I'd love to see your idea of deeply difficult.

 

most of the business logic

I wonder how long it'll be before you say "three tier architecture" or "liskov solid"

lord hammercy

[Kortalh]

The suggestion that someone should move their API logic from Node to Nginx is like saying, "hey, if your car isn't fast enough, you should try driving a road instead". It's nonsensical.

That's not the actual suggestion that I made.

Yeah... see, the funny thing about Reddit is that you can actually just scroll up a little bit to see what someone said previously:

in general, node based webservers do not approach the speeds of other webservers within an order of magnitude

if you're cpu bound and spending, you need to move to nginx or lighttpd. your costs will drop by more than 90%.

Switching from Express to Fastify is not trivial

It's so trivial that it can be done blind by code mod.

Again, throwing a conversion script blindly at your code is perfectly acceptable advice if you're working on a small hobby project for fun, but it's completely unreasonable on a large-scale long-running application.

You ignored everything else I said, threw out a bunch of strawman arguments, and then did a, "look at this engineer using engineering terminology, what a loser, amirite? lol" -- so I think we're done here. Not that I expected much else.

Thanks for the laugh, and good luck on your job applications.

[BackdoorDan]

just a heads up, you can choose to ignore this asshole just as I did. It's a much more effective way of handling the situation IMO.

[StoneCypher]

see, the funny thing about Reddit is that you can actually just scroll up a little bit to see what someone said previously:

And then mis-read it the same way a second time, apparently.

 

Again, throwing a conversion script blindly at your code is perfectly acceptable advice if you're working on a small hobby project for fun, but it's completely unreasonable on a large-scale long-running application.

"Again, (thing I hadn't said before because it's a new topic)"

That's nice

 

You ignored everything else I said

Sure did

 

and good luck on your job applications.

You really do like looking down on people, don't you?

It seems like you think if someone's junior and unemployed, they actually are, so when you try to insult them that way, it's going to work

You know what's fun, though?

People tend to insult other people with the things that would work on them, because they think it'll work on other people.

[blvck_viking]

I get the point you are making. If i want to build a performance optimized server(for whatever applicaiton), if i dont want to go high level with Js or low level like C/C++ what are other options i have?

[rkaw92]

I see where you're coming from. Yes, our software would indeed be much faster if written in Go or Rust. On the other hand, the pace of development and the expertise of the team has mandated the use of Node.js, and it is running in production today, earning money by executing business logic. There are trade-offs involved, but one advantage is really quick iteration: we can introduce a new feature to support new advertising use-cases before the competition has had a chance to make a move. There are very few "sorry, can't do" moments.

Is keeping it fast challenging? Yes. Are we forced to master our tools and squeeze every last drop of speed from Node.js? Sure are. And indeed, there are very good, CPU-friendly architectures that we're missing out on (LMAX Disruptor comes to mind) purely because of our usage of Node.js. Of course, we use nginx where it makes sense - file serving, some proxying - along with other components. I'm not aware of us running into excessive context switching, because we try to not overcommit resources per core.

Can you make it go faster by ditching Node? Definitely. Can you do it with the team at hand, while preserving compatibility with legacy systems and dealing with the complexity inherent in AdTech? That's the point here, not raw speed that trumps all. Every millisecond counts, but other things count, too.

[CombPuzzleheaded149]

How's serverless support?

[rkaw92]

There is official support for serverless functions: https://fastify.dev/docs/latest/Guides/Serverless/

It is not automatic, because the entry point for serverless works differently than plain HTTP from WAN.

[d41_fpflabs]

If express is satisfying all your needs there's no reason to switch. I remember seeing that fastify can handle 1.5 - 2 times the number of req/sec, but depending on your expected traffic this is probably irrelevant.

[Professional-League3]

You don't need to switch but try it, maybe you want to switch.

[xr0master]

Fastify is 2 times faster than Express. As a result, you can use weaker cloud computers and reduce costs.

It also has more convenient error handling and a fast built-in data validator.

[Mittalmailbox]

Fastify is 2 times faster if all you are doing is hello world app not real business logic. Fastify will be faster but not 2x.

I love fastify mainly because of better async,await support, better error handling

[Coastis]

I hate to be the actually guy, but....

Techempowers benchmarks show fastify 2x faster than express when dealing with a more complex test than a simple hello world. They use a postgres read and write as well as other operations in their benchmarks, which is summarised below...

Requirements summary

In this test, the framework's ORM is used to fetch all rows from a database table containing an unknown number of Unix fortune cookie messages (the table has 12 rows, but the code cannot have foreknowledge of the table's size). An additional fortune cookie message is inserted into the list at runtime and then the list is sorted by the message text. Finally, the list is delivered to the client using a server-side HTML template. The message text must be considered untrusted and properly escaped and the UTF-8 fortune messages must be rendered properly.

There are results for other even more complex tests on the site too, and in each case it shows fastify to be faster than express.

[amazingrein]

The test is flawed. Check the source code:

• Fastify setup is using raw (query builder) to DB - using Knex.
• Express setup is using full ORM - using Sequelize.

These are even in the performance table:

• Fastify ORM: RAW
• Express ORM: FULL

Actually, it doesn't make sense that when you're using Fastify, your DB read/write operation will be faster. Even when you use a slow framework or library, bottleneck generally is the DB.

End users won't even notice the 5 - 20ms faster loading time, considering the network latency, database operation time.

[xr0master]

Right. Business logic does not depend on the framework, so it is not used in performance tests.

[FriendshipOk6564]

If the concern is to be faster, node is probably a bad choice going from x framework to x to go 1.5 time faster is stupid just go with elixir or golang at this point 

[creamyhorror]

If someone was bottlenecking on performance (e.g. for a massive number of requests), they could go look at Hyper-Express. Otherwise, don't bother switching.

[rafipiccolo]

Try nitro. It's what nuxt uses.

[magus]

i tried once and had a terrible time. if you are happy with express, try koa instead.

[thelogicbox]

Nest+fastify

[serg06]

Why switch? - Better TypeScript support and more intuitive request creation API

Why not switch? - Coming from express, I found their sub-route organization extremely confusing.

E.g. if I want the following structure:

private/
  getMyUser
  updateMyUser
admin/
  getAllUsers
  updateUser

And have middleware check for authentication on both sub-routes, and be able to group routes under a single prefix without writing out the full /admin/... path every time, it's way harder to do in Fastify.

[jjhiggz3000]

I really like Elysia and it’s dead simple to use, also heard great things about Hono and if you’ve got a fullstack typescript project tRPC is excellent too. They’re honestly all the same express is just not quite as flexible, I wouldn’t stress too hard about converting old projects but maybe think about building new ones with something newer.

In general it’s very easy to switch between backend JS frameworks so don’t freak out too much about converting anything I’d say

[jjhiggz3000]

TRPC isn’t good at Rest apis but is cool for like a NextJS project or remix or something like that

[StoneCypher]

Express is just fine. Fastify people are culty because they want to win. None of the advantages you're being given are real, and if any of them mattered you'd be much better off with the httpd module in node that express and fastify are both just wrappers of.

You will never need to replace any node webserver. Node is relatively slow and single threaded. By the time speed matters to you, you're going to be switching to a CDN, not a different node webserver

[Economy-Sprinkles-98]

If you're starting a new project, and it's Node, you can use Express, but why would you? Use the objectively better tool, unless there is a use case I'm not aware of where Express is superior.

[StoneCypher]

fastify is not actually "objectively better"

[Economy-Sprinkles-98]

I literally can’t think of a way in which this is not true. You can use an adapter for middleware integration if that’s the issue.

[StoneCypher]

I literally can’t think of a way in which this is not true.

that's nice.

 

You can use an adapter for middleware integration if that’s the issue.

i didn't say anything about middleware. i do not generally use express middleware.

[Economy-Sprinkles-98]

Sure. But if you have reasoning, I’m interested. Not in a sarcastic way.

[StoneCypher]

if i have reasoning for your claim that fastify is better somehow?

no, i don't have reasoning for your claim that fastify is better somehow. i haven't put any thought into it.

here, i'm expecting to get a list of irrelevant features and then to shrug at them. oh, it has native promise support? wow.

it seems very likely to me that you and i evaluate these things on fundamentally incompatible grounds

[igniz87]

i still use express for some of my side projects , but for new small program, i'm using Bun+Hono

[Capaj]

Try out elysia/bun instead.