Al escribir una función de decorateApp aplicación, está creando su propia "API" para cargar su aplicación. Dicho esto, la primera carga a la que te enfrentarás pronto es sync o async :

• decorarApp es una función de sincronización
• decorarAppAsync dentro de una función asíncrona

Por ejemplo, necesita precargar algo de la base de datos antes de poder iniciar su aplicación.

 const decorateApp = (app) => { app.register(require('@fastify/mongodb')) }; const businessLogic = async (app) => { const data = await app.mongo.db.collection('data').find({}).toArray() } decorateApp(app) businessLogic(app) // whoops: it is async

En este ejemplo necesitas cambiar mucho código:

• la función de decorateApp debe ser asíncrona
• se debe esperar el registro de mongodb
• el código principal que carga la aplicación debe ser asíncrono

En cambio, al usar el enfoque de fastify, necesita actualizar solo el complemento que carga la base de datos:

 const applicationConfigPlugin = fp( + async function (fastify) { - function (fastify, opts, next) { - app.register(require('@fastify/mongodb')) - next() + await app.register(require('@fastify/mongodb')) } )

PD: tenga en cuenta que el código de ejemplo fastify-plugin pierde la next devolución de llamada ya que es una función de sincronización.

El próximo mal patrón será un alto acoplamiento oculto entre funciones. Cada aplicación necesita una config . Por lo general, la instancia de Fastify está decorada con él.

Entonces, tendrás algo como:

 decorateAppWithConfig(app); decorateAppWithSomethingElse(app);

Ahora, decorateAppWithSomethingElse necesitará saber que se carga después de decorateAppWithConfig . En su lugar, mediante el uso fastify-plugin , puede escribir:

 const applicationConfigPlugin = fp( async function (fastify) { fastify.decorate('config', 42); }, { name: 'my-app-config', } ) const applicationBusinessLogic = fp( async function (fastify) { // ... }, { name: 'my-app-business-logic', dependencies: ['my-app-config'] } ) // note that the WRONG order of the plugins app.register(applicationBusinessLogic); app.register(applicationConfigPlugin);

Ahora, obtendrá un buen error, en lugar de Cannot read properties of undefined cuando falta el decorador de config :

 AssertionError [ERR_ASSERTION]: The dependency 'my-app-config' of plugin 'my-app-business-logic' is not registered

Entonces, básicamente es factible escribir una serie de funciones que usan/decoran la instancia Fastify, pero agrega una nueva convención a su código que tendrá que administrar la carga de los complementos. Este trabajo ya está implementado por fastify y el fastify-plugin agrega muchas comprobaciones de validación .

Entonces, al considerar el ejemplo de la pregunta: no hay diferencia, pero usar ese enfoque para una aplicación más grande conducirá a un código más complejo:

• funciones de carga sincronizadas/asincrónicas
• malos mensajes de error
• dependencias ocultas en lugar de explícitas