docs: move Application recipes to how-to guides

[bajtos]

At the moment, the Application page in "Behind the scenes" is mixing explanations with how-to guides. This makes it difficult for our users to find the relevant content (a recipe to achieve the outcome they want).

As part of our adoption of the four-quadrant documentation system (see #5549 and #5718), we should extract all guides from explanation pages into guide pages (see #5768 for inspiration) and keep explanation pages focused on explaining the concepts & providing background information.

This story is a part of Epic #5783 move recipes to how-to guides.

Acceptance criteria

Move the following recipes into "How-to guides", decide yourself whether to create a new page for each recipe or group multiple recipes in one page.

• How to make your own application class

• How to configure app-level bindings

• How to register artifacts like components, controllers and servers to the application.

  I think we should have a single page for all of them, we should mention non-core artifacts like DataSources and Repositories too, and include instructions for adding artifacts via project-layout conventions, where the artifacts are picked up and registered by @loopback/boot.

• How to serve static files

Consider adding a "Common tasks" section to "Application" page, it should list pointers to new how-to guides. See Server >> Common tasks for inspiration.

[mrmodise]

Will take this on. Thanks

[mrmodise]

@bajtos on this point:

I think we should have a single page for all of them, we should mention non-core artifacts like DataSources and Repositories too, and include instructions for adding artifacts via project-layout conventions, where the artifacts are picked up and registered by @loopback/boot.

Are you referring to how they're automatically booted to repositories.* datasources.*?

[bajtos]

@bajtos on this point:

I think we should have a single page for all of them, we should mention non-core artifacts like DataSources and Repositories too, and include instructions for adding artifacts via project-layout conventions, where the artifacts are picked up and registered by @loopback/boot.

Are you referring to how they're automatically booted to repositories.* datasources.*?

I am referring to the following content:

• https://loopback.io/doc/en/lb4/Application.html#components
• https://loopback.io/doc/en/lb4/Application.html#controllers
• https://loopback.io/doc/en/lb4/Application.html#servers

I think we should start with a new page that will contain the existing instructions for adding artifacts manually via TypeScript API (e.g. app.controller).

The second step - and that's what I meant by my comment you quoted - is to enhance this new page to explain how to register artifacts automatically by leveraging @loopback/boot, exactly as you wrote:

they're automatically booted to repositories.* datasources.*?

The idea is to explain all options we provide for registering artifacts - TS API, boot conventions.

[mrmodise]

@bajtos will update accordingly. Thanks