-
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
A self-hosted API Explorer as a new extension #2014
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.
The pull request contains three commits to make the review easier:
- The first one adds an empty "explorer" package
- The second implements self-hosted API explorer
- The third one enables self-hosted API explorer in example projects
I'll work on the documentation and CLI templates once the general direction is approved.
@strongloop/loopback-maintainers How should we name the extension providing self-hosted API Explorer? Currently, I am using Also, do we want to start some kind of convention for LB extensions? In LB 3.x, extension packages have names starting with When deciding between Thoughts? |
@bajtos CI is failing. |
I know, this is waiting for feat(rest): add config option to disable API Explorer redirects #2016 to be landed first. |
The proposal combines the ability of controllers and static assets to serve API explorer with server-side templating. I think it's acceptable first step. LGTM. |
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.
Mostly LGTM, left a few nitpicks. I am good with the name @loopback/rest-explorer
.
|
||
const response = await request.get('/explorer/').expect(200); | ||
const body = response.body; | ||
expect(body).to.match(/^\s*url: '\/apispec',\s*$/m); |
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 are 3 endpoint mappings above, do we want to assert the other 2 as well?
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.
This test is verifying that we are picking the correct endpoints (OpenAPI v3 in JSON format). This test is configuring other mappings to verify that the algorithm picks the right mapping..
@jannyHou How can I improve the test to make this more clear to readers?
How about rest-api-explorer ? (too long?), but rest-explorer LGTM also. |
Just my two cents.. Between |
Re: package name - thank you @jannyHou @marioestradarosa @dhmlau for the feedback. I am going to use |
968d42e
to
b090e07
Compare
I have rebased the patch on the latest master and addressed all remaining issues & todos. The pull request is ready for final review. I'll squash the commit history before landing. To make the review easier, I left the first three commits unchanged and added a bunch of new small commits (one for each logical step, kind of):
|
The documentation changes require us to land loopbackio/loopback.io#767, I think that other PR should be landed first. |
Actually, I found a better solution - see #2025 |
Please ignore this build failure. It's just the commit linter using a wrong version of package list to verify scope. This error will get fixed when I clean up the commit history. |
The failure of |
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 work! I've left some comments, but LGTM overall.
debug('Redirect to swagger-ui was disabled by configuration.'); | ||
return; | ||
} | ||
|
||
const explorerPaths = ['/swagger-ui', '/explorer']; |
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.
Should explorerPaths
take into account custom paths the user configures with our RestExplorer
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.
I am not opposed to that, but I think it's out of scope of this pull request.
summary: | ||
A tutorial on using `@loopback/rest-explorer` to add a self-hosted REST API | ||
Explorer | ||
--- |
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.
Are you planning to add docs to this page in this PR?
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.
This page will automatically include the contents of packages/rest-explorer/README.md
, see https://loopback.io/doc/en/lb4/Creating-decorators.html as an example of a page based on README contents.
… was created Before this change, the built-in Explorer redirect could be disabled only via the config object passed to RestServer. Once a RestServer was instantiated, changes to the configuration were no longer honored. This commit moves the detection of `apiExplorer.disabled` to the Express routes handling redirects.
b090e07
to
9ed2384
Compare
Add a new package @loopback/rest-explorer that provides a self-hosted swagger-ui instance and disables the built-in swagger-ui redirect. Modify example projects to use @loopback/rest-explorer. Modify the CLI template to include self-hosted REST API Explorer in new applications.
9ed2384
to
e40b653
Compare
@bajtos when will this extension be released? Thanks |
I believe |
In this pull request, I am picking up the best parts from #1664 and #1976 and proposing an implementation of a self-hosted API explorer build on the features that are already available. The internal design is not as pretty & clean as it could be, but it works OOTB (as long as the user configures a custom url path, see below).
I expect that the internal details of the explorer component will evolve over time as we keep adding more extension points to our REST layer, but that's way beyond this pull request.
The missing piece: how to disable the built-in redirect to
explorer.loopback.io
.I'll be opening a new pull request for that (hopefully today).See feat(rest): add config option to disable API Explorer redirects #2016.Close #1664, close #1976, close #1960.
This pull request is one of the tasks for [API Explorer] Self-hosted API Explorer #559.
@strongloop/loopback-maintainers please review
Checklist
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated