Spike: How to migrate LB3 components

[bajtos]

This is the first spike for #3955, see also #3718 and #3922.

Eventually, we want to write content for docs/site/migration/extensions.md and explain how can users migrate their custom LB3 components to LB4 extensions:

• How to rewrite components from LB3 component to a LB4 extension?
• How to migrate applications using such components/extensions?
• What's our advice for apps using official loopback components like loopback-component-storage?

Before we can write such migration guide, we need to build a better understanding of how a typical LB3 component look like, what kind of features & functionalities are contributed by existing LB3 components (including 3rd party modules) and how to map such functionality to LB4 concepts.

Unfortunately, our documentation for LB3 component authors is rather short, see LoopBack components and Creating components

Acceptance criteria

Initial research

• Review our official components - loopback-component-push, https://loopback.io/doc/en/lb3/Storage-component.html. Please note these two components were created in early LoopBack days and most likely don't follow idiomatic LoopBack patterns. When thinking about migration path to LB4, try to approach these components with a fresh look. Do not try to map the current design of the LB3 implementation directly to LB4 counter-parts. Start with a high-level review of what functionality are these components providing to their users and then look for an way how would you implement such functionality in LB4 style.
  --> docs: overview of LB3 components and techniques they use #5122

• Use the following npm search to find existing LB3 mixins as examples to help us better understand different usage patterns we need to cover in our migration guide:

  https://www.npmjs.com/search?q=loopback%20component

  --> docs: overview of LB3 components and techniques they use #5122

• Write a document explaining common features and patterns implemented by existing components. Get the document reviewed & approved by the team before moving to next steps.
  --> docs: overview of LB3 components and techniques they use #5122

Action plan

• For each feature/pattern found in existing components, propose how to implement it in LB4 style. Some patterns may require functionality that's not available in LB4 yet. This is expected, put down a note and try to link to existing GitHub issues where possible. (Do not create any new issues yet!) Get the proposals reviewed & approved by the team before moving to the next step.

• Propose a plan - create a list of follow-up tasks. Some of these tasks may be "implement a feature we already have a GitHub issue for", some of the tasks may be "create a new GH issue to implement a missing feature". Don't forget to describe tasks for writing the migration guide too, e.g. "write a skeleton/outline", "fill content for section XYZ", etc.

List of areas to cover:

• Migrate component infrastructure - see docs: component migration - general aspects #5262
• Migrate current context - see docs: component migration - general aspects #5262
• Migrate mixins - see docs: component migration - general aspects #5262
• Migrate Models, Entities and Repositories - see Allow components to contribute models + migration guide for LB3 components #5477
• Migrate REST API - see docs: create REST API endpoints in components + LB3 migration #5385
• Migrate API transports - see docs: update "LB4 Component Migration" spike proposal #5427
• Authentication & authorization - see docs: update "LB4 Component Migration" spike proposal #5427
• Migrate Introspection - see docs: update "LB4 Component Migration" spike proposal #5427

Out of scope

Migration of the following component is out of scope of this spike:

• OAuth2 - will be covered by auth&auth migration guide
• Passport - will be covered by auth&auth migration guide
• Synchronization - won't be implemented in LB4. It's important to mention this fact in the migration guide.

[jannyHou]

• lb3 component and lb4 component are consistent on high level.
• lb4 component can contribute artifacts as bindings, but some are not supported yet, like connector

[deepakrkris]

@bajtos can we scope out the following tasks into a separate issue:

• - For each feature/pattern found in existing components, propose how to implement it in LB4 style. Some patterns may require functionality that's not available in LB4 yet. This is expected, put down a note and try to link to existing GitHub issues where possible. (Do not create any new issues yet!) Get the proposals reviewed & approved by the team before moving to the next step.

• - Propose a plan - create a list of follow-up tasks. Some of these tasks may be "implement a feature we already have a GitHub issue for", some of the tasks may be "create a new GH issue to implement a missing feature". Don't forget to describe tasks for writing the migration guide too, e.g. "write a skeleton/outline", "fill content for section XYZ", etc.

[deepakrkris]

@bajtos since you have covered enough ground in this spike, can we close this issue, and open a new issue for #5262

[bajtos]

Closing as done 🕺