Why should I prefer Fastify to Expressjs?
Published: 2021-04-21 20:51:04

---
title: Why should I prefer Fastify to Expressjs?
series: Fastify Bonus
---

# "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](https://www.fastify.io/docs/latest/Guides/Plugins/#asyncawait)

### 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](https://fastify.dev/docs/latest/Reference/Server/#getdefaultjsonparser)

### Tests

Fastify explains in its [official documentation](https://fastify.dev/docs/latest/Guides/Testing/) 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`](https://www.npmjs.com/package/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](https://www.fastify.io/docs/latest/Guides/Testing/)

### 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`](https://www.npmjs.com/package/pino)) has so many plugins, so push the logs everywhere that it is impossible to lose them!

[Doc Reference](https://fastify.dev/docs/latest/Reference/Logging/)

### Configuration

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

```js
// 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](https://www.fastify.io/docs/latest/Reference/Plugins/)

### 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](https://www.fastify.io/docs/latest/Reference/Validation-and-Serialization/)

### 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](https://fastify.dev/docs/latest/Reference/Plugins/)

### Release schedule

Fastify has a clear Long Term Support (LTS) [policy](https://github.com/fastify/fastify/blob/main/docs/LTS.md) 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](https://twitter.com/ManuEomm)!

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](https://pxhere.com/en/photo/1640023?utm_content=shareClip&utm_medium=referral&utm_source=pxhere) (Creative Commons CC0)