-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: overview of LB3 components and techniques they use #5122
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For each item in the "Techniques", I guess you summarized based on existing issues/repositories/docs, if so, could you add them as references?
I think a more reasonable sequence is having the section "Overview of existing LB3 components" before "Techniques" (spent some time to guess the background of those techniques 🙈 )
Great effort! have a minor comment about the access control component.
`@configure` specific to each service (see the logger extension for an | ||
example)._ | ||
|
||
17. Inject models (entities & repositories) to the service. These models can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: I feel LB4 usually uses a model's type, but does not inject it, the repositories are injected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know! In this list, I am trying to describe what I saw in LB3 components. How to map them to LB4 concept is another thing, I'll be looking into that once this PR is landed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add more content to this item to explain.
|
||
### Authentication & authorization | ||
|
||
21. Add a custom step to the default authentication/authorization sequence, so |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does "the default authentication/authorization sequence" mean LB4 sequence? There is only one action related to authentication currently. The authorization is handled by interceptor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question.
By "default authentication/authorization sequence", I mean whatever steps are executed by LB3 runtime to authenticate and authorize an incoming request.
Obviously, this will be different in LB4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll change "the default authentication/authorization sequence" to "to the default LB3 authentication/authorization workflow", I hope it will be easier to understand that way.
@bajtos Great write-up. I need a bit more time to review it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good write up
Ah, sorry for the confusion. The overview section was meant to add more background for people who are interested to dig deeper and/or understand where are the techniques coming from. For many readers, the first section (Techniques) should provide enough information so that they can skip the Overview. I can add a short note to explain this, would that help?
Sure, I understand it's a lot of information to digest. Any ETA on when you will have that time? This PR is a part of a task committed for April milestone and there are two more steps to be done, I am concerned the schedule is a bit tight. |
Fair enough 👍 thank you sounds good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Nice write up. It would be good to have a short note to explain what the Techniques
section is for. I was confused too at beginning 😄
|
||
1. How to structure the extension code to receive user-provided configuration & | ||
target app instance. What are the instructions for adding a LB4 component to | ||
a LB4 app. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not obvious as there is no explanation of LB3 component's signature (app, config, callback)
. Maybe something like Expected component module layout and exports
?
|
||
3. How to migrate a component exporting mixins. See | ||
[Migrating model mixins ](https://loopback.io/doc/en/lb4/migration-models-mixins.html) | ||
for migration guide for app developers (mixin consumers). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe describe what a LB3 component can contribute to the application when it's mounted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a digram would help if it shows the handshake between an application and a component as well as typical artifacts exported from a component.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To some extent, a LB3 application asks its components to extend/patch the app. In contrast, a LB4 application imports bindings (representing the component's contribution to the app) from its components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are all good suggestions for the migration guide, I'll capture them in a note in this document. Please note that I am not that far yet, here I am just collecting and describinh different techniques used by the components.
@jannyHou @nabdelgadir @raymondfeng thank you for thoughtful comments. I pushed a new commit 08572a2 that should address them, can you PTAL again? Please note that this is not the ultimate final version of the document, we can further improve it in the next step of the spike #4099:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
||
### Services (local and remote) | ||
|
||
16. Add a new local service (a class providing JS/TS API), e.g. Push service or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: I think the numbering is one off from here down
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great catch, thank you!
- Review of our official components - loopback-component-push, loopback-component-storage. - Review of (most popular) community extensions - Documentation explaining common techniques used by existing components. Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>
08572a2
to
6509f52
Compare
This is the first part of documentation for the spike #4099 How to migrate LB3 components.
I reviewed our official components and (most popular) community extensions, and compiled a list of techniques they use. The idea is to use this list of techniques to identify what content we need to write for LB3 extension maintainers to enable them to upgrade to LB4.
My intention is to commit this document so that it can serve as a kind of a Lightweight Architecture Decision Record. I created a new directory
docs/spikes
to hold spike-related docs.@raymondfeng @jannyHou @emonddr (FA owners of Infrastructure for extensions): Please review the document. I am specifically looking for feedback on the list of techniques I identified in LB3 components - is there anything missing? Are there any techniques we don't want to cover at this time, e.g. because we want to wait until there is more demand for them or perhaps because we don't intend to support them in LB4 at all?
I would also like to invite the wider community (@strongloop/loopback-next, @strongloop/loopback-3x-maintainers) to join this discussion too. Is there any LB3 component that you are using in your project and would like to migrate to LB4, but not covered by my list? Let us know!
Below is the list of community extensions I reviewed. I really appreciate the effort our community put into creating extensions, you are awesome! ❤️ Please let us know if you are interested in bringing your extension over to LB4 and what kind of information would help you.
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated👉 Check out how to submit a PR 👈