Skip to content
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

Design-first (top-down) approach to building LB4 apps #1882

Closed
bajtos opened this issue Oct 19, 2018 · 2 comments
Closed

Design-first (top-down) approach to building LB4 apps #1882

bajtos opened this issue Oct 19, 2018 · 2 comments

Comments

@bajtos
Copy link
Member

bajtos commented Oct 19, 2018

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 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.
  • Find a robust and easy-to-use tool that can automatically verify whether the implementation is matching the described API. See A better tool for automated API smoke tests #644.
  • A tutorial showing how to build an application using design-first approach. See [Docs] Top-down (swagger gen) app tutorial #734
  • Check existing doc pages for places where we refer to code-first approach, expand them to cover design-first approach too.
@stale
Copy link

stale bot commented Oct 14, 2019

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.

@stale stale bot added the stale label Oct 14, 2019
@stale
Copy link

stale bot commented Nov 13, 2019

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.

@stale stale bot closed this as completed Nov 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant