Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
APIStar as a cli-only API tool. #624
This PR is working towards removing the server framework stuff from APIStar completely, in order to focus on cross-framework tooling for APIs, as discussed initially here: https://discuss.apistar.org/t/splitting-out-the-server/551/19
The initial set of CLI tools would be:
There would also be programmatic access to any of those functions, eg. Python API client that takes a schema on instantiation, and allows the user to then interact with the API.
The type system would also be a documented part of the library, along with API for generating HTML forms out of the types, and for marshalling between JSON Schema and APIStar types.
I haven't quite figured out what I want to do about the server stuff in APIStar (or not), but I'm not happy with it in it's current state, and Starlette does a far better job of pushing forward the fundamentals of an ASGI server.
I know this won't be a particularly popular direction, but I'm keen to focus APIStar on becoming a framework-agnostic tool, for generating and serving API documentation, using as an API client etc. rather than yet-another framework.
So, Starlette takes advantage of ASGI properly, whereas for APIStar it's a bit bolted on. As a result there are a number of things that Starlette does (or soon will do) that aren't so obvious how to nicely build into APIStar, in particular:
It also does a much better job of clear, consistent design.
What it doesn't do, that APIStar does is:
I've not been convinced that APIStar's dependency injection is necessarily that great a solution to anything much, but even if I was, I'd rather see the projects properly scoped.
Here's some different paths we could go down: