The API allows you to add new properties to the Fastify instance. A value is not restricted to a function and could also be an object or a string, for example.

    decorate Just call the decorate API and pass the name of the new property and its value.

    As said above, you can also decorate the instance with non-function values:

    1. fastify.decorate('conf', {
    2.   db: 'some.db',
    3.   port: 3000
    4. })

    Once you decorate the instance, you can access the value by using the name you passed as a parameter:

    1. fastify.utility()
    3. console.log(fastify.conf.db)

    decorateReply As the name suggests, this API is needed if you want to add new methods to the Reply core object. Just call the decorateReply API and pass the name of the new property and its value:

    1. fastify.decorateReply('utility', function () {
    2.   // something very useful
    3. })

    Note: using an arrow function will break the binding of this to the Fastify reply instance.

    decorateRequest As above, this API is needed if you want to add new methods to the Request core object. Just call the decorateRequest API and pass the name of the new property and its value:

    Note: using an arrow function will break the binding of this to the Fastify request instance.

    Decorators and encapsulation

    As an example, the following will throw:

    1. const server = require('fastify')()
    3. server.decorateReply('view', function (template, args) {
    4.   // Amazing view rendering engine.
    5. })
    6. server.get('/', (req, reply) => {
    7.   reply.view('/index.html', { hello: 'world' })
    8. })
    10. // Somewhere else in our codebase, we define another
    11. // view decorator. This throws.
    13.   // another rendering engine
    14. })
    16. server.listen(3000)

    But this will not:

    1. const server = require('fastify')()
    3. server.decorateReply('view', function (template, args) {
    4.   // Amazing view rendering engine.
    5. })
    7. server.register(async function (server, opts) {
    8.   // We add a view decorator to the current encapsulated
    9.   // plugin. This will not throw as outside of this encapsulated
    10.   // plugin view is the old one, while inside it is the new one.
    11.   server.decorateReply('view', function (template, args) {
    12.     // another rendering engine
    13.   })
    14.   server.get('/', (req, reply) => {
    15.     reply.view('/index.page', { hello: 'world' })
    16.   })
    17. }, { prefix: '/bar' })
    19. server.listen(3000)

    Getters and Setters

    Decorators accept special "getter/setter" objects. These objects have functions named getter and setter (though, the setter function is optional). This allows defining properties via decorators. For example:

    1. fastify.decorate('foo', {
    2.   getter () {
    3.     return 'a getter'
    4.   }

    Will define the foo property on the Fastify instance:

    Usage Notes

    decorateReply and decorateRequest are used to modify the Reply and Request constructors respectively by adding methods or properties. To update these properties you should directly access the desired property of the Reply or Request object.

    As an example let's add a user property to the Request object:

    1. // Decorate request with a 'user' property
    2. fastify.decorateRequest('user', '')
    4. // Update our property
    5. fastify.addHook('preHandler', (req, reply, next) => {
    6.   req.user = 'Bob Dylan'
    7.   next()
    8. })
    9. // And finally access it
    10. fastify.get('/', (req, reply) => {
    11.   reply.send(`Hello ${req.user}!`)
    12. })

    Note: The usage of decorateReply and decorateRequest is optional in this case but will allow Fastify to optimize for performance.

    Sync and Async

    Dependencies

    If your decorator depends on another decorator, you can easily declare the other decorator as a dependency. You just need to add an array of strings (representing the names of the decorators on which yours depends) as the third parameter:

    1. fastify.decorate('utility', fn, ['greet', 'log'])

    If a dependency is not satisfied, decorate will throw an exception, but don't worry: the dependency check is executed before the server boots up, so it won't ever happen at runtime.

    hasDecorator

    You can check for the presence of a decorator with the hasDecorator API:

      hasRequestDecorator

      You can check for the presence of a Request decorator with the hasRequestDecorator API:

      hasReplyDecorator

      You can check for the presence of a Reply decorator with the hasReplyDecorator API: