Open josh-chamberlain opened 3 months ago
@josh-chamberlain I've created two complimentary draft requests here:
SUMMARY.md
, correct?data-sources-app
once the documents are moved, rather than within the same issue.@maxachis
Yes! they show up on the left bar here: https://docs.pdap.io
you moved them already, it's the hidden properties markdown file
docbox was suggested because API docs can be so complex and tedious to generate, yet they are repeatable in structure. in the screenshot attached, you can see that gitbook is doing some extra work to render tabs and things that are not supported in github flavored markdown. this is the source of the screenshot below. API docs are often hosted separately because of their specific requirements. The ideal case is that we have API docs generated from the app repo, so that PRs which change the API can change the docs at the same time. I'd rather not merge until they're rendering properly.
So at least looking at the Python end, the best solution for automatic API documentation appears to be using Flask-RESTX. This is a popular module that provides decorators and other tools to describe the API and expose its documentation automatically.
The catch is that we will need to swap out uses of Flask's Api
and Resource
classes with flask_restx's implementations of the same class. Then, we'd need to add special decorators unique to the module. In theory, not too much, and once we do that, we can put the documentation right there in the code and see it replicate.
There may be a complicating factor with the Vue
side of things, but I'm not sure yet. I may create a small sample Flask-RestX test repository on my own account to make sure I understand its functionality. I'd also want to keep @mbodeantor and @bonjarlow apprised of this, since these changes would affect code they've created.
@josh-chamberlain This work could probably wait until we're further with V2 right?
@mbodeantor yeah, I suppose this work seems much less urgent now that there's v2 stuff to do. As part of the v2 stuff we're going to be making a lot of API changes, but I guess it's about the same amount of work either way.
@maxachis I am open to Flask-RESTX and in-code documentation—are you good to wait on this a bit?
@mbodeantor yeah, I suppose this work seems much less urgent now that there's v2 stuff to do. As part of the v2 stuff we're going to be making a lot of API changes, but I guess it's about the same amount of work either way.
@maxachis I am open to Flask-RESTX and in-code documentation—are you good to wait on this a bit?
I can, indeed! But there may be a third option!
I may be able to incrementally replace some of our components with flask_RESTx as I develop for v2. Flask-RESTx is a fork of Flask-RESTful and is designed to maintain backward compatibility -- it just allows for auto-generated Swagger documentation. So I may be able to swap out the flask_restful version of App
with flask_restx's version, and do the same for any new
Resource` classes I instantiate. It may be that simple. If not, it'd be able to be identified when testing the PR, and I could easily swap them back.
The risk is this is a little extra effort with a chance of it coming to nothing (but not much). But if successful, it may reduce redundancy by not requiring us to change that documentation to a different schema later on.
@maxachis It seems like more moving parts to me, but you'd be the one primarily managing that complexity—I don't really want to have API docs in two places. I wouldn't say starting this now is a good idea, but when we're further into v2 it might make a lot of sense
Context
The gitbook docs at https://docs.pdap.io should be for people using PDAP as a software/service. Everything to do with the code should be in the README, /docs folders and markdown files in the respective repo. It's all already markdown, but might need some light formatting.
Plus, it's nice to be able to change the code + update the docs at the same time.
Requirements
documentation
andsource of truth for the app
at the same time.Docs
lol