Boot and mount LB3 app

[bajtos]

This is a follow-up for the spike #2318, see the discussion and PoC code for more context.

Implement @loopback/booter-lb3app, a Booter implementation that takes existing LB3 codebase, boots the application, converts its Swagger spec to OpenAPI v3 and then mounts the app on the target LB4 application, including the spec.

The booter package should not have any runtime dependency on @loopback/boot, it should use peerDependencies to specify which core packages it works with and dev-dependencies for development & testing. List of packages to put in peer dependencies:

• @loopback/core
• @loopback/boot
• @loopback/rest

Proposed user experience: README#basic-use

PoC implementation: lb3app.booter.ts

Related issues: #1849 #2389

Acceptance criteria

• New package packages/booter-lb3app
• Adequate test coverage
• A README file providing enough information for users discovering this package via npm. Make sure to adhere to our README guidelines
• Configure our docs to render booter's README under Using components sidebar section. Use the same approach we did for REST API Explorer, see README layout for technical details.

[jannyHou]

Defer the estimation:
We expect more clarification in ac:

• do we boot the lb3 app in isolation and only expose endpoints to lb4?

[bajtos]

Do we boot the lb3 app in isolation and only expose endpoints to lb4? And are all artifacts in LB3 app booted?

See the PoC implementation in lb3app.booter.ts, the issue description contains this link too.

We will do exactly the same thing that existing LB3 tooling like loopback-sdk-angular-cli does:

1. load the main LB3 app file via require
2. check if boot is in progress and wait until it finishes (if necessary)

LB3 apps can use loopback-boot@2, loopback-boot@3 or even their own custom bootstrapper.

Do we boot the lb3 app in isolation?

I am not sure what do you mean by "boot in isolation". The LB4 booter will ensure that LB3 application was correctly booted, this will happen as part of LB4 boot step.

and only expose endpoints to lb4?

Again, see the PoC. There are two ways:

1. Mount the entire Express application provided by LB3, including middleware like CORS, Helmet, LB4 access token parser.
2. Mount the REST API handler only.

And are all artifacts in LB3 app booted?

That depends on the LB3 application.

My understanding is the lb3 app runs on a http server and lb4 app runs on another one, is it correct?

Please note that LB3 application is an Express app under the hood and it does not come with any HTTP(s) server.

We are not going to start another HTTP server for the LB3 application. Instead, we use the request handler provided by LB3 application (flavor 1) or by LB3's REST API adapter (flavor 2) and mount this request handler on the Express instance used internally by LB4.

Again, see the PoC code for more details.

Flavor 1:
https://github.com/strongloop/loopback-next/blob/379e0c050c49e70713cabc9aa6d85a892250d375/packages/booter-lb3app/src/lb3app.booter.ts#L98-L103

Flavor 2:
https://github.com/strongloop/loopback-next/blob/379e0c050c49e70713cabc9aa6d85a892250d375/packages/booter-lb3app/src/lb3app.booter.ts#L105-L116

---

I think the PoC should answer most questions about both high-level design and implementation details. What we need to do in this story:

• move the PoC code to a new package
• add test coverage
• clean up the PoC code where needed
• write documentation

[bajtos]

I think my confusion is caused by this function https://github.com/strongloop/loopback-next/blob/379e0c050c49e70713cabc9aa6d85a892250d375/examples/lb3app/legacy/server/server.js#L8
thought it will be called so that lb3 app runs on a separate server.

I understand it now. Well, we won't call app.start from LB4, just mount application's request handler on the LB4 app.