...
Rendering issue only happens on production website. Rendering is correct on Gitbook backoffice
Gitbook backoffice appears to use DOM Lazy loading, supporting theory 1
The spec is referencing 3 different swagger files. They are all exports of a Swagger documentation hosted in SwaggerHub by Beckn. There’s a general issue of having 4 different versions files of the same API (3 on the Gitbook, plus the slightly different SwaggerHub online version).
Theories:
Theory 1: Too many swagger blocks called. There are 74 in a single page (in comparison Payments BB has only 20 swagger blocks). Rendering too many swagger blocks may be clogging the DOM.
Solution: Divide chapter 8 in subchapters.
Pros: It is too long for a normal web browser to render anyways and even when it does, it is too much info on a single webpage for an end-user. Quick to to.
Cons: Other BB's do not divide chapter 8. However maybe they should, for legibility.
| Tip |
|---|
This is the most likely theory |
Theory 2: Swagger files referenced are way too large. They contain the full API documentation. In comparison, the Payments BB has one yaml file per endpoint (althought origin / governance is not as clear on these ones, as they don't reference a swaggerhub url). So if this is the problem, and depending on whether the front-end is loading this on-the-fly, it may have trouble generating so many blocks over a large swagger file, so 74 yaml queries to 3 large swagger files, to render each block.
Solution: Break the yml file into many files, one per endpoint.
Pros: Easier to handle changes to the swagger documentation if governance is kept on Gitbook only
Cons: Will decouple what's happening on GitBook and the Swagger app.
Other changes that need to be made about the BB
...