docs: migrate missing files from loopback.io

docs/lb4_sidebar.yml

@@ -0,0 +1,184 @@
+## definition of `menuitem`===========
+# title: string
+# url: string
+# output: [ enum{web, pdf} ] (expressed as comma separated string in YAML)
+# children?: [ menuitem ]
+
+## top level property=================
+# entries: [ menuitem ]
+
+title: LoopBack 4
+url: index.html
+children:
+
+- title: 'Getting started'
+  url: Getting-started.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Examples and tutorials'
+    url: Examples-and-tutorials.html
+    output: 'web, pdf'
+
+- title: 'Key concepts'
+  url: Concepts.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Application'
+    url: Application.html
+    output: 'web, pdf'
+
+  - title: 'Server'
+    url: Server.html
+    output: 'web, pdf'
+
+  - title: 'Context'
+    url: Context.html
+    output: 'web, pdf'
+
+  - title: 'Dependency injection'
+    url: Dependency-injection.html
+    output: 'web, pdf'
+
+  - title: 'Controllers'
+    url: Controllers.html
+    output: 'web, pdf'
+
+  - title: 'Routes'
+    url: Routes.html
+    output: 'web, pdf'
+
+  - title: 'Sequence'
+    url: Sequence.html
+    output: 'web, pdf'
+
+  - title: 'Model'
+    url: Model.html
+    output: 'web, pdf'
+
+  - title: 'Repositories'
+    url: Repositories.html
+    output: 'web, pdf'
+
+  - title: 'Decorators'
+    url: Decorators.html
+    output: 'web, pdf'
+
+- title: 'Booting an Application'
+  url: Booting-an-Application.html
+  output: 'web, pdf'
+
+- title: 'Using Components'
+  url: Using-components.html
+  output: 'web, pdf'
+
+- title: 'Calling other APIs'
+  url: Calling-other-APIs-and-web-services.html
+  output: 'web, pdf'
+
+- title: 'Testing your application'
+  url: Testing-your-application.html
+  output: 'web, pdf'
+
+- title: 'For current LoopBack users'
+  url: LoopBack-3.x.html
+  output: 'web, pdf'
+
+- title: 'Command-line interface'
+  url: Command-line-interface.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Application generator'
+    url: Application-generator.html
+    output: 'web, pdf'
+
+  - title: 'Controller generator'
+    url: Controller-generator.html
+    output: 'web, pdf'
+
+  - title: 'Extension generator'
+    url: Extension-generator.html
+    output: 'web, pdf'
+
+  - title: 'Download examples'
+    url: Download-examples.html
+    output: 'web, pdf'
+
+- title: 'Best practices with Loopback 4'
+  url: Best-practices-with-Loopback-4.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Defining the API using code-first approach'
+    url: Defining-the-API-using-code-first-approach.html
+    output: 'web, pdf'
+
+  - title: 'Defining the API using design-first approach'
+    url: Defining-the-API-using-design-first-approach.html
+    output: 'web, pdf'
+    children:
+
+    - title: 'Testing the API'
+      url: Testing-the-API.html
+      output: 'web, pdf'
+
+  - title: 'Defining your testing strategy'
+    url: Defining-your-testing-strategy.html
+    output: 'web, pdf'
+
+  - title: 'Implementing features'
+    url: Implementing-features.html
+    output: 'web, pdf'
+
+  - title: 'Preparing the API for consumption'
+    url: Preparing-the-API-for-consumption.html
+    output: 'web, pdf'
+
+- title: 'Extending LoopBack 4'
+  url: Extending-LoopBack-4.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Creating Components'
+    url: Creating-components.html
+    output: 'web, pdf'
+
+  - title: 'Creating Decorators'
+    url: Creating-decorators.html
+    output: 'web, pdf'
+
+  - title: 'Testing your extension'
+    url: Testing-your-extension.html
+    output: 'web, pdf'
+
+- title: 'Crafting LoopBack 4'
+  url: Crafting-LoopBack-4.html
+  output: 'web, pdf'
+
+- title: 'Language-related concepts'
+  url: Language-related-concepts.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Mixin'
+    url: Mixin.html
+    output: 'web, pdf'
+
+- title: 'FAQ'
+  url: FAQ.html
+  output: 'web, pdf'
+
+- title: 'Reference'
+  url: Reference.html
+  output: 'web, pdf'
+  children:
+
+  - title: 'Reserved binding keys'
+    url: Reserved-binding-keys.html
+    output: 'web, pdf'
+
+  - title: 'Glossary'
+    url: Glossary.html
+    output: 'web, pdf'

docs/site/Application.md

@@ -32,13 +32,17 @@ tasks as a part of your setup:
 import {Application} from '@loopback/core';
 import {RestComponent, RestServer} from '@loopback/rest';
 import {SamoflangeController, DoohickeyController} from './controllers';
-import {WidgetApi} from './apidef/';
 
 export class WidgetApplication extends Application {
   constructor() {
     // This is where you would pass configuration to the base constructor
     // (as well as handle your own!)
-    super();
+    super({
+      rest: {
+        port: 8080
+      }
+    });
+
     const app = this; // For clarity.
     // You can bind to the Application-level context here.
     // app.bind('foo').to(bar);
@@ -47,17 +51,6 @@ export class WidgetApplication extends Application {
     app.controller(DoohickeyController);
   }
 
-  async start() {
-    // This is where you would asynchronously retrieve servers, providers and
-    // other components to configure them before launch.
-    const server = await app.getServer(RestServer);
-    server.bind('rest.port').to(8080);
-    server.api(WidgetApi);
-    // The superclass start method will call start on all servers that are
-    // bound to the application.
-    return await super.start();
-  }
-
   async stop() {
     // This is where you would do whatever is necessary before stopping your
     // app (graceful closing of connections, flushing buffers, etc)
@@ -191,6 +184,15 @@ export class MyApplication extends RestApplication {
 ## Tips for application setup
 Here are some tips to help avoid common pitfalls and mistakes.
 
+### Extend from `RestApplication` when using `RestServer`
+If you want to use `RestServer` from our `@loopback/rest` package, we recommend you extend
+`RestApplication` in your app instead of manually binding `RestServer` or
+`RestComponent`. `RestApplication` already uses `RestComponent` and makes
+useful functions in `RestServer` like `handler()` available at the app level.
+This means you can call these `RestServer` functions to do all of your
+server-level setups in the app constructor without having to explicitly retrieve
+an instance of your server.
+
 ### Use unique bindings
 Use binding names that are prefixed with a unique string that does not overlap
 with loopback's bindings. As an example, if your application is built for

docs/site/Best-practices-with-Loopback-4.md

@@ -8,12 +8,21 @@ permalink: /doc/en/lb4/Best-practices-with-Loopback-4.html
 summary:
 ---
 
+{% include important.html content="
+The API-first approach for building LoopBack
+applications is not yet fully supported. Therefore, some of the sections in this
+page are outdated and may not work out of the box. They will be revisited after
+our MVP release.
+" %}
+
 LoopBack 4 is more than just a framework: It’s an ecosystem that encourages developers to follow best practices through predefined standards. This section will walk through some important guidelines by building an example API for a catalog of products.
 
 Our best practice follows an "API first" and test-driven development approach:
 
-1. [**Defining and validating the API**](./Defining-and-validating-the-API.md): This section guides you through constructing your API first before any internal logic is added.
-2. [**Testing the API**](./Testing-the-API.md): This section describes the process of writing smoke test for your API and its spec.
-3. [**Defining your testing strategy**](./Defining-your-testing-strategy.md): This section discusses the advantages and the process of building a strong testing suite.
-4. [**Implementing features**](./Implementing-features.md): This section demonstrates how the tests for each feature of your application should be written, and how to write the logic to make these tests pass. In the example, the tests for the controller, model, repository, data source, and sequence are written and then implemented.
-5. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.md): This section shows how the endpoints can be physically tested using the Swagger UI.
+1. **Defining the API**: There are two possible approaches to take in this section
+   - [**Defining the API using code-first approach**](./Defining-the-API-using-code-first-approach.md): This section guides you through setting up a skeleton of your application so that its full OpenAPI specification can be automatically generated.
+   - [**Defining the API using design-first approach**](./Defining-the-API-using-design-first-approach.md): This section guides you through constructing your API first before any internal logic is added. __*Not fully supported*__
+     - [**Testing the API**](./Testing-the-API.md): This section describes the process of writing smoke test for your API and its spec. __*Not fully supported*__
+2. [**Defining your testing strategy**](./Defining-your-testing-strategy.md): This section discusses the advantages and the process of building a strong testing suite.
+3. [**Implementing features**](./Implementing-features.md): This section demonstrates how the tests for each feature of your application should be written, and how to write the logic to make these tests pass. In the example, the tests for the controller, model, repository, data source, and sequence are written and then implemented.
+4. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.md): This section shows how the endpoints can be physically tested using the Swagger UI.