docs: update "LB4 Component Migration" spike proposal

Link to follow-up issues for the following areas:

- Services: #5424
- API transports: #5425
- Instrospection: #5426

Propose to not write any migration guide for auth/auth extensions yet.

Add a placeholder page for migration of Models, finalize LB4 sidebar
and the component-migration overview page.

Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>

docs/site/migration/components/models.md

@@ -0,0 +1,13 @@
+---
+lang: en
+title: 'Migrating components contributing Models'
+keywords: LoopBack 4, LoopBack 3, Migration, Extensions, Components, Models
+sidebar: lb4_sidebar
+permalink: /doc/en/lb4/migration-extensions-models.html
+---
+
+{% include note.html content="
+This is a placeholder page, the task of adding content is tracked by the
+following GitHub issue:
+[loopback-next#3955](https://github.com/strongloop/loopback-next/issues/3955)
+" %}

docs/site/migration/components/overview.md

@@ -11,12 +11,6 @@ redirect_from: /doc/en/lb4/migration-extensions.html
 Missing instructions for your LoopBack 3 use case? Please report a [Migration docs issue](https://github.com/strongloop/loopback-next/issues/new?labels=question,Migration,Docs&template=Migration_docs.md) on GitHub to let us know.
 " %}
 
-{% include note.html content="
-This is a placeholder page, the task of adding content is tracked by the
-following GitHub issue:
-[loopback-next#3955](https://github.com/strongloop/loopback-next/issues/3955)
-" %}
-
 In LoopBack 3, a component is essentially a function that extends and/or patches
 the target application.
 
@@ -68,14 +62,28 @@ instructions into several sub-sections.
    migrate your LoopBack 3 extension project infrastructure to LoopBack 4 style
    and how to update the instructions for using your component.
 
+1. [Migrating components contributing Models, Entities and Repositories](./models.md)
+   explains how to migrate a LB3 component contributing Models into a LB4
+   component that contributes Entites and Repositories.
+
 1. [Migrating access to current context](./current-context.md) describes how to
    migrate code accessing contextual information shared by different parts of a
    LoopBack application.
 
 1. [Migrating components contributing Model mixins](./mixins) explains how to
    migrate a component that's contributing Model mixins.
 
-1. [Migrating components contributing REST API endpoints](./rest-api)
+1. [Migrating components contributing REST API endpoints](./rest-api) explains
+   how to migrate different kinds of REST API endpoints.
+
+There is no migration guide written for the following areas yet, please up-vote
+the referenced GitHub issues to let us know if you are looking for such content:
+
+- Migrating services (local and remote):
+  [loopback-next#5424](https://github.com/strongloop/loopback-next/issues/5424)
+
+- API transports (websockets, pub/sub message consumers):
+  [loopback-next#5425](https://github.com/strongloop/loopback-next/issues/5425)
 
-1. _More sections will be created as part of
-   [loopback-next#3955](https://github.com/strongloop/loopback-next/issues/3955)._
+- Introspection of application artifacts:
+  [loopback-next#5426](https://github.com/strongloop/loopback-next/issues/5426)

docs/site/sidebars/lb4_sidebar.yml

@@ -893,6 +893,10 @@ children:
       url: migration-extensions-project-layout.html
       output: 'web, pdf'
 
+    - title: 'Models'
+      url: migration-extensions-models.html
+      output: 'web, pdf'
+
     - title: 'Current context'
       url: migration-extensions-current-context.html
       output: 'web, pdf'

docs/spikes/2020-04-how-to-migrate-lb3-components.md

@@ -130,26 +130,25 @@ coming from._
 17. Add a new local service (a class providing JS/TS API), e.g. Push service or
     (database) Migration service.
 
-    - The service must be configurable by the target app (e.g. Apple & Google
-      credentials for push notifications, transport config for logger
-      frameworks, Amazon S3 credentials for storage component, etc.).
+    The service must be configurable by the target app (e.g. Apple & Google
+    credentials for push notifications, transport config for logger frameworks,
+    Amazon S3 credentials for storage component, etc.).
 
-      _LB3 typically uses component configuration. I think in LB4, we can use
-      `@configure` specific to each service (see the logger extension for an
-      example)._
+    _LB3 typically uses component configuration. I think in LB4, we can use
+    `@configure` specific to each service (see the logger extension for an
+    example)._
 
 18. Inject LB3 models (LB4 entities & repositories) to the service. These models
     can be provided either by the extension or by the target application. When
     using models from the target application, the developer needs an option to
     specify which models (entities) and associated repositories to use.
 
-    _Note: In LB4, models/entities are not injectable now, we used them
-    primarily for the type information (to describe the shape of model data). As
-    part of the follow-up research, we will need to decide if it's enough to
-    inject LB4 Repository to a component or if we need to make model/entity
-    classes injectable too. Also note that `DefaultCrudReposiory` class provides
-    a public instance property `entityClass` referencing the model/entity it's
-    bound to._
+    _Note: In LB4, models/entities are used primarily for the type information
+    (to describe the shape of model data). As part of the follow-up research, we
+    will need to decide if it's enough to inject LB4 Repository to a component
+    or if we need to inject model/entity classes too. Also note that
+    `DefaultCrudReposiory` class provides a public instance property
+    `entityClass` referencing the model/entity it's bound to._
 
 19. Provide a service factory to create services dynamically at runtime, e.g.
     named child loggers created via `app.log('name')` in LB3.
@@ -259,19 +258,48 @@ downloads, I feel it's not necessary to provide migration guide for this case.
 
 ### Migrate Services (local and remote)
 
-TBD
+Created a follow-up epic
+[loopback-next#5424](https://github.com/strongloop/loopback-next/issues/5424) to
+look into this area later, when there is user demand.
 
 ### Migrate API transports
 
-TBD
+Created a follow-up epic
+[loopback-next#5425](https://github.com/strongloop/loopback-next/issues/5425) to
+look into this area later, when there is user demand.
 
 ### Migrate Authentication & authorization
 
-TBD
+Considering the huge difference between the auth & auth design in LB3 and LB4, I
+think it's not feasible to migrate existing LB3 auth extension(s) to in way that
+will preserve the high-level design. Instead, users need to approach the auth
+layer with a fresh perspective and structure their extensions around the new
+architecture of auth & auth.
+
+In that light, I don't see much value in describing how to migrate techniques
+from LB3 auth extensions to LB4, because such techniques are very likely to be
+irrelevant in LB4 world.
+
+Let's see what questions LoopBack 4 users come with and write content that's
+useful to current LB4 applications & extensions, instead of documenting
+techniques that used to be useful in the past.
+
+> 24. Add a custom step to the default LB3 authentication/authorization
+>     workflow, so that we can compute additional information about the current
+>     user (e.g. groups the user belongs to).
+>
+>     _Note: I think this step could be replaced by lazy initialization, where
+>     the current user groups are computed on the first access and cached for
+>     subsequent use._
+>
+> 25. A new role resolver (e.g. using groups), the app developer needs a way how
+>     to configure which models/repositories to use for role resolution.
 
 ### Migrate Introspection
 
-TBD
+Created a follow-up epic
+[loopback-next#5426](https://github.com/strongloop/loopback-next/issues/5426) to
+look into this area later, when there is user demand.
 
 ## Overview of existing LB3 components