Clarification on the Impact of Awaiting a Plugin/Decorator

[sujeeet-kumar]

I have some confusion regarding the significance of using the await keyword when registering a plugin or applying a decorator in Fastify.

Please clarify the difference it makes when await is used with fastify.register() and fastify.decorate().

Questions to Address:

1. What is the actual impact of using await with fastify.register() and fastify.decorate()?
2. In which scenarios should await be used, and when is it unnecessary?
3. Are there any performance or functional implications to consider?
4. Are there cases where using or not using await might lead to unexpected behavior?
5. What is default plugin load behaviour? Sequencial or Parallel? Does using await makes any change to this default behaviour?

[Uzlopak]

I dont think that fastify.decorate is async. Would surprise me.

But fastify.register is by nature async. So if you dont await it, it could be that the plugin is not fully loaded and then you try to access it or some "decorated" attributes, and it could fail. E.g. using a plugin which initializes a redis connection and then resolves. So when you dont await the redis connection is potentially not loaded.

to 2.) you dont need to await the loading of a plugin, if you know that other plugins arent depending on it. E.g. you have two plugins, which will add some routes to the fastify instance. Then you dont need to await, because when you call listen()/ready() then fastify will wait till all plugins are loaded and then start fastify instance.

to 3.) Registering a plugin without awaiting is faster of course. But if you need decorators or functionality from the plugin, then you need to await it, which slows down.

to 4.) as described above. Always using await is being on the safe side.

to 5.) I think it is parallel.