Something that I’ve been considering for a while, that I think it’s time to raise.
There have been three big motivations behind API Star:
- Pushing Python’s asyncio forward through support for ASGI. (Initially by formulating an ASGI-like interface, which helped inform the motivation and design for ASGI 2.0)
- Revamping the schema validation, API docs, dynamic client libraries, that coreapi initially provided.
- Using dependency injection for views, in order to self-document the schema types that each view accepts.
The API docs and validation are available with the
apistar command line tool, although not yet documented. The python client library is part of the core package, although again, not yet documented. The functionality that they provide is also going to be available in the web app that I’ve been working on and will be making public in the next few weeks.
The Uvicorn server, the Starlette library, and the
apistar command-line tool, and upcoming web app, are all nicely scoped, and (along with REST framework) these are the bits that personally, I want to really focus on.
Really I’d like to split out the server part of apistar.
It’d have the
apistar package as a dependency (for the types, validation, docs generation etc…). It might also be a good time considering dropping WSGI support, and having it just as an ASGI framework.
This would happen alongside making the apistar web app public, and making a new release of the
apistar package that has the command line client for API docs generation, schema validation, dynamic clients, and schema mocking.
It’s possible that the server package could just be “apistar-server”, or perhaps even move it to being more of community owned project, with a different name. (I’d like to keep apistar for the core schema library and web app.) Either way it’d have it’s docs separately to the apistar command line tooling.
This doesn’t necessarily mean any upgrade pain, just that the server bits would end up as a separate package.
Figure this all needs raising for discussion.
Taking this step would mean I could focus on the fundamentals of pushing ASGI forward, and bringing it to other frameworks, plus give me a much more narrowly scoped
apistar library to manage, alongside the web app.
- Would folks be up for stepping up as maintainer of the new package?
- Should we be up for renaming it, or is “apistar-server” what you’d prefer to see?