The current API docs site (repo) requires a build step to populate with the most current data (minus the home page cards, which can be seen loading in by refreshing the page). The current build system we're using is Docusaurus, with this plugin to generate pages base on an openapi.yaml document. These essentially have a build step where all the data is collected, then you get a bunch static html/css/js pages representing your site.
It would simplify the deployment if every time the user loads the page, it fetches the most recent openapi spec and displays the ui based on that (of course this could be automatically cached if it's too slow).
The simplest solution would be to find another OpenAPI client that we like that doesn't involve a build step. If that isn't possible, we could write our own website to parse the OpenAPI spec (using a package like json-scheme-ref-parser). This is trickier, but doable, and would give us more flexibility in the design and organization of the content.
The current API docs site (repo) requires a build step to populate with the most current data (minus the home page cards, which can be seen loading in by refreshing the page). The current build system we're using is Docusaurus, with this plugin to generate pages base on an openapi.yaml document. These essentially have a build step where all the data is collected, then you get a bunch static html/css/js pages representing your site.
It would simplify the deployment if every time the user loads the page, it fetches the most recent openapi spec and displays the ui based on that (of course this could be automatically cached if it's too slow).
The simplest solution would be to find another OpenAPI client that we like that doesn't involve a build step. If that isn't possible, we could write our own website to parse the OpenAPI spec (using a package like json-scheme-ref-parser). This is trickier, but doable, and would give us more flexibility in the design and organization of the content.