Boot scripts

[bajtos]

A boot script is a short piece of code that users want to run during application setup (boot), e.g. to apply additional configuration in a programatic way, add more routes, etc.

In LB3, a boot script is a JS file in server/boot directory, loopback-boot automatically discovers and runs these scripts as part of boot.

For LB4, we should come up with a solution that will enable app developers to define custom code bits to be executed during boot, possibly also during start & stop. It is not necessary to use the LB3 approach, we should approach this challenge with a fresh mind and pick a design that leverages the power of LB4.

Acceptance criteria

TBD

[lucaslopez]

Just an idea about this as a LB user. Hope I am not interfering with your discussion, or that this doesn't go against LB4 principles. Just trying to put my two cents here.

I always thought it would be nice to have the option to run your piece of code whenever loopback triggers an event. I imagined it something like:

const app = new MyLoopbackApplication();
app.events.on('modelDefined', (model) => { 
  // do something here
});
app.events.on('serverBoot', async (server) => {
  // do something asynchronous
});
await app.start();

What I liked about this approach is that:

• It would let you define new events easily and in the same way in the future, not only for server boot but for all application and its extensions
• As an extension developer, it would let me catch and interact loopback during its start process
• As an extension developer, it would let me define and trigger my own events so I can let my users know about them If I distribute my extension.

[bajtos]

@lucaslopez I like your proposal, but at the same time I feel it's orthogonal to the concept of boot scripts (a convention on where to place source code bits + a booter to discover and execute those bits).

Could you please open a new issue where we can focus on discussing your proposal?

In LoopBack 3, the application object is also an event-emitter providing events like app.on('modelDefined') and we were using such events internally too. I think it makes a lot of sense to introduce a similar concept in LB4 too.

[raymondfeng]

See #1928

[lucaslopez]

See #1928

Is this considered to cover the loopback application to be an event emitter or should I still open a new issue?

[lucaslopez]

@lucaslopez I like your proposal, but at the same time I feel it's orthogonal to the concept of boot scripts (a convention on where to place source code bits + a booter to discover and execute those bits).

Could you please open a new issue where we can focus on discussing your proposal?

In LoopBack 3, the application object is also an event-emitter providing events like app.on('modelDefined') and we were using such events internally too. I think it makes a lot of sense to introduce a similar concept in LB4 too.

Thanks for the info! I was not aware LB3 is emitting events as well. Is this documented somewhere or it is just meant for internal use?

[raymondfeng]

Please check out #1928

[acrodrig]

I am running into this issue right no with LB4. I want to make sure certain objects exist in the DB right after starting the application. Since all of the application configuration happens in a constructor I cannot use async methods and I am at a loss as to how best to check if the DB has the needed entities and if not insert them.

Can you help with a workaround with the current state of affairs for LB4?

[raymondfeng]

Please follow up with #2094 and #1928.

[acrodrig]

@raymondfeng Thanks for your quick answer. I am just using the DB update as an "example" of something you want to happen right after the application starts. It could also be connecting to a server via a socket, validating a bucket exists on S3, or anything really. So #2094 is not really applicable to my question.

I did read through #1928 before. I love the approach and would use it if it were available. Unfortunately it is not yet available.

So my question is, as I am sitting here today trying to use LB4 to get a project done, what is the best approach to get an asynchronous task done after the application/server starts?

[raymondfeng]

Hopefully #1928 will be landed soon. Before that, you might have to override app.start() method or add more logic to index.js to trigger your scripts after start.

[acrodrig]

Thanks! Somehow I was not aware of index.js, so that works well.

[dougal83]

Thanks! Somehow I was not aware of index.js, so that works well.

Same here. By default, VS Code is hiding the file for me and I was running under the assumption that TS would be used in all circumstances.

[bajtos]

Thanks! Somehow I was not aware of index.js, so that works well.
By default, VS Code is hiding the file for me and I was running under the assumption that TS would be used in all circumstances. If index.js is a file that requires editing occasionally, perhaps editors should be configured to to show certain .js files default?

Please put your custom logic to src/index.ts instead - add more steps to the main function.

[bajtos]

I am closing this story as done via #1928. Please open a new issue if there are any other changes/improvements needed to support your use cases.