Encapsulation

A fundamental feature of Fastify is the “encapsulation context.” The encapsulation context governs which decorators, registered hooks, and plugins are available to routes. A visual representation of the encapsulation context is shown in the following figure:

Figure 1

In the above figure, there are several entities:

  1. The root context
  2. Three root plugins
  3. Two child contexts where each child context has
    • Two child plugins
    • One grandchild context where each grandchild context has
      • Three child plugins

Every child context and grandchild context has access to the root plugins. Within each child context the grandchild contexts have access to the child plugins registered within the containing child context, but the containing child context does not have access to the child plugins registered within its grandchild context.

Given that everything in Fastify is a plugin, except for the root context, every “context” and “plugin” in this example is a plugin that can consist of decorators, hooks, plugins, and routes. Thus, to put this example into concrete terms, consider a basic scenario of a REST API server that has three routes: the first route (/one) requires authentication, the second route (/two) does not, and the third route (/three) has access to the same context as the second route. Using fastify-bearer-auth to provide the authentication, the code for this example is as follows:

  1. 'use strict'
  3. const fastify = require('fastify')()
  5. fastify.decorateRequest('answer', 42)
  7. fastify.register(async function authenticatedContext (childServer) {
  8.   childServer.register(require('fastify-bearer-auth'), { keys: ['abc123'] })
  10.   childServer.route({
  11.     path: '/one',
  12.     method: 'GET',
  13.     handler (request, response) {
  14.       response.send({
  15.         answer: request.answer,
  16.         foo: request.foo,
  17.         bar: request.bar
  18.       })
  19.     }
  20.   })
  21. })
  23. fastify.register(async function publicContext (childServer) {
  24.   childServer.decorateRequest('foo', 'foo')
  26.   childServer.route({
  27.     path: '/two',
  28.     method: 'GET',
  29.     handler (request, response) {
  30.       response.send({
  31.         answer: request.answer,
  32.         foo: request.foo,
  33.         bar: request.bar
  34.       })
  35.     }
  36.   })
  38.   childServer.register(async function grandchildContext (grandchildServer) {
  39.     grandchildServer.decorateRequest('bar', 'bar')
  41.     grandchildServer.route({
  42.       path: '/three',
  43.       method: 'GET',
  44.       handler (request, response) {
  45.         response.send({
  46.           answer: request.answer,
  47.           foo: request.foo,
  48.           bar: request.bar
  49.         })
  50.       }
  51.     })
  52.   })
  53. })
  55. fastify.listen(8000)

The above server example shows all of the encapsulation concepts outlined in the original diagram:

  1. Each child context (authenticatedContext, publicContext, and grandchildContext) has access to the answer request decorator defined in the root context.
  2. Only the authenticatedContext has access to the fastify-bearer-auth plugin.
  3. Both the publicContext and grandchildContext have access to the foo request decorator.
  4. Only the grandchildContext has access to the bar request decorator.

To see this, start the server and issue requests:

  1. # curl -H 'authorization: Bearer abc123' http://127.0.0.1:8000/one
  2. {"answer":42}
  3. # curl http://127.0.0.1:8000/two
  4. {"answer":42,"foo":"foo"}
  5. # curl http://127.0.0.1:8000/three
  6. {"answer":42,"foo":"foo","bar":"bar"}

Sharing Between Contexts

Notice that each context in the prior example inherits only from the parent contexts. Parent contexts cannot access any entities within its descendent contexts. This default is occasionally not desired. In such cases, the encapsulation context can be broken through the usage of fastify-plugin such that anything registered in a descendent context is available to the containing parent context.

Assuming the publicContext needs access to the bar decorator defined within the grandchildContext in the previous example, the code can be rewritten to:

  1. 'use strict'
  3. const fastify = require('fastify')()
  4. const fastifyPlugin = require('fastify-plugin')
  6. fastify.decorateRequest('answer', 42)
  8. // `authenticatedContext` omitted for clarity
  10. fastify.register(async function publicContext (childServer) {
  11.   childServer.decorateRequest('foo', 'foo')
  13.   childServer.route({
  14.     path: '/two',
  15.     method: 'GET',
  16.     handler (request, response) {
  17.       response.send({
  18.         answer: request.answer,
  19.         foo: request.foo,
  20.         bar: request.bar
  21.       })
  22.     }
  23.   })
  25.   childServer.register(fastifyPlugin(grandchildContext))
  27.   async function grandchildContext (grandchildServer) {
  28.     grandchildServer.decorateRequest('bar', 'bar')
  30.     grandchildServer.route({
  31.       path: '/three',
  32.       method: 'GET',
  33.       handler (request, response) {
  34.         response.send({
  35.           answer: request.answer,
  36.           foo: request.foo,
  37.           bar: request.bar
  38.         })
  39.       }
  40.     })
  41.   }
  42. })
  44. fastify.listen(8000)

Restarting the server and re-issuing the requests for /two and /three:

  1. # curl http://127.0.0.1:8000/two
  2. {"answer":42,"foo":"foo","bar":"bar"}
  3. # curl http://127.0.0.1:8000/three
  4. {"answer":42,"foo":"foo","bar":"bar"}