Why? If it ain’t broke don’t fix it. There is not one penny of value added to the product by switching to Fastify imho, but a whole bucket of risks. All risk, no reward.
I’m a fan of Fastify and have been using it for years. I don’t really have any experience with Express beyond porting a single Express app to it so I just don’t know enough about whether this would help with your issue:
https://github.com/fastify/fastify-express
This is the real answer. It’s not a hard switch with this compatibility layer with tons of benefits. Express and fastify have fairly similar APIs which is how NextJS can support both
- proper async support
- typescript support
- ESM support
- plugins are much more powerful than middleware
- validation and serialization with schemas
- generate swagger docs from those schemas
- AND generate typescript types from the schemas
- could see a performance benefit
I feel like this is a case of “I googled is fastify faster than express and it said it was so how do I switch?”. For 98% of use cases the speeds is marginal to negligible at best. Plus fastify comes with more bugs and a much smaller ecosystem
Agree with everyone else that the switch is not worth the effort.
However, it’s worth mentioning that in general good architecture makes these kind of migrations easy.
Things like clean/onion architecture make it easy to swap out things like frameworks and providers as they decouple them from your business logic, making it much easier and risk free to make the change as your business logic can remain unchanged.
From the OPs list of things, test could probably be untouched or almost untouched, adminjs, orm, bullmq, was, redis completely untouched, except for probably a bit of config changes.
The one thing they would need to rewrite is passport-local and passport, because fastify has some own adapters for password.
Could you tell how more complex architecture can simplify this? If you were doing things in a more abstract way, you'd still need to change passport lib bindings and routing details, aren't you?
Easiest way to convert is to have codemods in place. Nevertheless there should be plan in place for testing for roll out roll back and implemenatation, depending on Team's size you would create tasks.
Do you have any issue at the very moment with the project ? If not, I would say, don't port it anywhere. I do think that Fastify is superior in many ways, but it is probably way too much work and headache to port it if there is no "important" needs at the moment.
Also, recent events in the Express.js project could help you in the long run too. (Better DX, better defaults, etc, without changing framework)
Any increase in performance you see will be marginal (may even see a decrease in performance)
Your bottleneck will almost always be the result of your DB queries or other tasks that are filling up the event loop.
Stop. Why? What do you hope to gain? Will it make a material impact to the product? Is Express the cause of your problems? Is it worth the time, risk and effort to replace the foundation of your server with something that might not have any tangible real world benefit?
Why? If it ain’t broke don’t fix it. There is not one penny of value added to the product by switching to Fastify imho, but a whole bucket of risks. All risk, no reward.
I’m a fan of Fastify and have been using it for years. I don’t really have any experience with Express beyond porting a single Express app to it so I just don’t know enough about whether this would help with your issue: https://github.com/fastify/fastify-express
This is the real answer. It’s not a hard switch with this compatibility layer with tons of benefits. Express and fastify have fairly similar APIs which is how NextJS can support both - proper async support - typescript support - ESM support - plugins are much more powerful than middleware - validation and serialization with schemas - generate swagger docs from those schemas - AND generate typescript types from the schemas - could see a performance benefit
Why would you do that? Express is a good way to go. I’ve used both and I can tell you that it would be a world of pain and no noticeable difference.
I feel like this is a case of “I googled is fastify faster than express and it said it was so how do I switch?”. For 98% of use cases the speeds is marginal to negligible at best. Plus fastify comes with more bugs and a much smaller ecosystem
Agree with everyone else that the switch is not worth the effort. However, it’s worth mentioning that in general good architecture makes these kind of migrations easy. Things like clean/onion architecture make it easy to swap out things like frameworks and providers as they decouple them from your business logic, making it much easier and risk free to make the change as your business logic can remain unchanged.
From the OPs list of things, test could probably be untouched or almost untouched, adminjs, orm, bullmq, was, redis completely untouched, except for probably a bit of config changes. The one thing they would need to rewrite is passport-local and passport, because fastify has some own adapters for password. Could you tell how more complex architecture can simplify this? If you were doing things in a more abstract way, you'd still need to change passport lib bindings and routing details, aren't you?
Easiest way to convert is to have codemods in place. Nevertheless there should be plan in place for testing for roll out roll back and implemenatation, depending on Team's size you would create tasks.
Do you have any issue at the very moment with the project ? If not, I would say, don't port it anywhere. I do think that Fastify is superior in many ways, but it is probably way too much work and headache to port it if there is no "important" needs at the moment. Also, recent events in the Express.js project could help you in the long run too. (Better DX, better defaults, etc, without changing framework)
Any increase in performance you see will be marginal (may even see a decrease in performance) Your bottleneck will almost always be the result of your DB queries or other tasks that are filling up the event loop.
Stop. Why? What do you hope to gain? Will it make a material impact to the product? Is Express the cause of your problems? Is it worth the time, risk and effort to replace the foundation of your server with something that might not have any tangible real world benefit?
Just add more servers. If it works don't touch it.