Discovering 2 Fastify Underrated Tricks You Must Know as a Backend Developer

Boost your Fastify application performance and developer experience by using these underestimated features.

Photo by Joshua Sortino on Unsplash

I’ve been using Fastify for a few years.

It is my go-to choice for every project. Even if I have some experience with Fastify, sometimes, I come across some functionality I didn’t know. I discovered some of them during a workshop, others reading the documentation, and others reading the book (affiliate link).

Here are the 4 underrated features of Fastify you must know.

1. Reset decorator object

Decorators are one of the best features Fastify provides.

Using decorators, you can attach objects and methods to the Fastify instance, the request, or the response. When you decorate the request or the response with an object, remember that the object's reference is shared among all the requests.

Let me give you an example.

In the above example, we decorate the request with a property called “obj” and populate that property with an object.
Then, we registered two routes:

• The first one waits 5 seconds and then prints the content of the “hello” property.

• The second changes the value of the “hello” property to “universe” and prints it.

To test the execution, we can use something like this:

Fastify provides a very useful “inject” utility to test the server.

What do you think will be printed?

(node:10196) [FSTDEP006] DeprecationWarning: You are decorating Request/Reply with a reference type. This reference is shared amongst all requests. Use onRequest hook instead. Property: obj
(Use `node --trace-deprecation ...` to show where the warning was created)

universe
universe

The last two lines are both showing “universe”. The reason for this behavior is explained in the first part of the message. Fastify prints a warning explaining that we are decorating the request (or the reply/response) with a reference type, and that reference is shared among all the requests.

Why does it matter?

Imagine if you try to decorate your request with a “user” property or a reference to the tenant. Can you see the issue?

So, how can we fix it?

We need to reset the request decorator at every request.

To do that, we can create a plugin:

Let me explain what this plugin does:

1. It decorates the request with an “obj” property, setting it null. This has multiple benefits:

   1. It immediately creates that property in the javascript object's hidden class, improving the performance. I am not going deep into the explanation since it is out of the scope of this post.

   2. It ensures the decorator is present, so using the “decorators” option of "satisfy-plugin” is still possible.

   3. The object is always reset, so it’s not shared among the requests.

2. Adds an “onRequest” hook to populate the “obj” property.

We can now change the app.js to use the new plugin:

And not test it:

universe
world

You can notice that the warning has disappeared, and now, each request prints its version of the object.

Note: this specific feature is explained in the documentation.

2. Route config

Fastify gives you the possibility to add a configuration object to each route.

That is particularly useful to make your code more modular and reusable.

Let me explain it with an example:

Note: This is a simple example, so don’t use it as a production security check.

In the above example, we have two routes: one private route and one public route. To access the private route, you need a token to be present in the request header. The public route has no check.

In a real-world application, you might have situations similar to this one, where routes have different conditions.

To make your code reusable, you can use the “config” property of the route.

As you can see, I removed the check inside the private route, and added the config property with a “private” field set to “true”. I also created a hook for the route. The hook checks the “routeOptions” argument for the config property and the “private” field value. If it is present adds the check on the fly to the request populating the “onRequest” hook.

In real-world applications, you can improve the modularity of your code using this trick.

---

Read next