You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the early alpha versions of LB4, we used to have a guide on building application design-first way. The design-first approach starts with an API design phase, with the intention to find such API that will work great for API consumers and won't be unnecessarily constrained by how easy or difficult it is to implemented. The implementation starts only after the API has been designed and described in an OpenAPI specification document.
Unfortunately, we did not manage to make this approach as easy to use as we would like to and therefore there is no guide yet. As a temporary solution, one can use lb4 openapi to create initial scaffolding of controllers and models from an OpenAPI spec document. This is a one-time action, it's not possible to apply updates made to the OpenAPI spec to the implementation.
At the same time, the runtime implementation of @loopback/rest does allow application developers to use the OpenAPI spec document as the source of truth and use OpenAPI spec extensions like x-controller-name and x-controller-method to map OpenAPI endpoints to Controller methods implementing them.
As part of this Epic, I would like us to make design-first approach a first-class citizen of LB4 world.
Areas to work on:
Improve lb4 openapi to ask the users whether they want to keep the OpenAPI document as the source of truth (NEW) or move API definition to code via decorators (CURRENT).
Write a new Best Practice guide to complement the existing guide Defining the API using code-first approach. This guide should show how to write a test verifying that the OpenAPI spec document is valid among other things.
This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.
In the early alpha versions of LB4, we used to have a guide on building application design-first way. The design-first approach starts with an API design phase, with the intention to find such API that will work great for API consumers and won't be unnecessarily constrained by how easy or difficult it is to implemented. The implementation starts only after the API has been designed and described in an OpenAPI specification document.
See the removed page Thinking in LoopBack.
Unfortunately, we did not manage to make this approach as easy to use as we would like to and therefore there is no guide yet. As a temporary solution, one can use lb4 openapi to create initial scaffolding of controllers and models from an OpenAPI spec document. This is a one-time action, it's not possible to apply updates made to the OpenAPI spec to the implementation.
At the same time, the runtime implementation of
@loopback/rest
does allow application developers to use the OpenAPI spec document as the source of truth and use OpenAPI spec extensions likex-controller-name
andx-controller-method
to map OpenAPI endpoints to Controller methods implementing them.As part of this Epic, I would like us to make design-first approach a first-class citizen of LB4 world.
Areas to work on:
lb4 openapi
to ask the users whether they want to keep the OpenAPI document as the source of truth (NEW) or move API definition to code via decorators (CURRENT).The text was updated successfully, but these errors were encountered: