"Why should I prefer Fastify to Expressjs?"

A lot of people ask me this question over and over again, so I would like to share why I prefer
Fastify to Expressjs because the correct answer to this question is just one:

You should prefer the framework that fit best your needs

Disclaimers:

• I'm a happy Fastify maintainer, so that I could be a bit biased
• I think expressjs is a great project and a pillar for the Node.js community, and the core team is doing a great job to push forward this framework
• Opinions expressed are solely my own and do not express the views or opinions of the Fastify community
• My knowledge is about expressjs@4.x

So...

Why I prefer Fastify to Express

I prefer Fastify to Express for the productivity.
That's all 😀

It seems simple, but this word means that Fastify ships with some key features necessary for me to be productive.

Async

Fastify supports async/await out of the box for all the components that must be awaited like:

• route handlers
• application hooks
• server methods like .listen()
• await plugins loading (like a mongo connection) before start listening

Doc Reference

JSON Input

By default, Fastify has a secure JSON body-parser to read the request body. You don't need anything else to accept application/json inputs.

Doc Reference

Tests

Fastify explains in its official documentation how to write the test for it!
Moreover, it is designed to run fast on test too, this is possible starting the server without listening to the host's PORT, so you may run in parallel tests to speed up the execution (again: using tap the parallel execution is the default behaviour!)

Actual use case: during my job, I migrated a codebase from expressjs@3 to fastify@2, and the test execution time has more than halved!

Doc Reference

Logging

Fastify has a logger included, so I don't have to think about how to log or store the logger instance and boring stuff like this.
Moreover, the default logger (aka pino) has so many plugins, so push the logs everywhere that it is impossible to lose them!

Doc Reference

Configuration

The application configuration is always a pain (usually), but with Fastify decorators or using its plugin system, getting the options is so simple:

// index.js
const myAppConfig = { awesome: true }
fastify.register(myAppPlugin, myAppConfig)

// my-plugin.js
module.exports = async function myAppPlugin (instance, opts) {
  console.log(opts) // print: { awesome: true }
}

Doc Reference

JSON Schema

JSON Schema is another tool included in Fastify, so you don't need to struggle to configure it. You can use it.

Doc Reference

Plugin system

TLDR: Fastify runs the minimal amount of functions to process a request.

I need to make a comparison of the framework architecture here.

expressjs implements the middleware pattern: so the request is processed sequentially by a list of functions that are executed one by one.

fastify implements a tree data structure + the middleware pattern: the request is routed to the right branch to execute, and then it is processed sequentially by only the functions needed.

So, adding a middleware in expressjs will affect all the requests, even if not necessary.
In Fastify, instead, you can add a hook only to a limited set of routes or even on one route.
This kind of architecture will avoid introducing bugs on routes that should not be affected by new middlewares.

Doc Reference

Release schedule

Fastify has a clear Long Term Support (LTS) policy and
it is released whenever there is new bug fixes or new features.

For example, Node.js 16.10.0 introduced a new option to manage the maximum requests a socket can handle.
This option has been shipped in Fastify after 7 days by receiving a pull request.

The expressjs module has not a new release since 2 years ago (at the moment v4.17.1).
For sure you can set the new option in express too, but you will need to create the http server
by yourself, and you will need to use the http.Server class - but I think I'm using a framework
to avoid that.

Money

[Update 2022] I forgot to mention that a more efficient framework leads to lesser servers' resources. It means that to manage X req/sec you will pay less your cloud provider or you will be able to install more applications on the same server instance! I worked on a migration from .NET to Node.js/Fastify and we turned off ~10 AWS t4g.xlarge EC2 instances.

Monkey Patching

[Update 2023] Fastify has its own Request and Reply objects that are built on top of the Node.js's http.ClientRequest and http.ServerResponse. This is more flexible because Fastify does not break the Node.js internals, and both can evolve without conflicting with each other. Express, instead, monkey patch those standard objects with an impact on the Node.js contributors that must be caution to introduce new features because of Express!

Others

There are a lot more for me to prefer Fastify:

• Fastify awesome community
• the focus on performance

End

These are the main reasons why I prefer Fastify.
You should try it by yourself now and find your reasons! (if any, of course!)

For more Fastify content, follow me on Twitter!

Write comments here below or open an issue on GitHub for any questions or feedback!
Thank you for reading!

Acknowledgements

Image post credits to mohamed hassan (Creative Commons CC0)