I’ve been moving ahead with work on removing the server from API Star, originally pitched here.
The pull request is here.
This would mean that the next version of API Star wouldn’t include the server at all. Instead it’d be targeted at being framework-independent API tooling, including API documentation, schema validation, API mocking, a dynamic API client library, and a type system that can map to or from JSON schema, and render to HTML forms.
This isn’t going to be massively popular with folks using the framework, but I’ve not been maintaining it, and I’m far happy with a greatly scoped-down project, that can be used with any Python framework, and that fits in much better with other work that I look after. (eg. I want to be able to start recommending
apistar for generating API docs for REST framework, and using it as the api client library, while gradually deprecating
Alongside the dependency injection, one of my main aims in releasing API Star was to help push ASGI forward. I’ve since put in a bunch of work to a far more tightly scoped project, Starlette that I think provides a far more well-designed approach for an async web framework/toolkit than API Star has been able to (since API Star has the weird mix of being able to support either WSGI or ASGI).
There’s a few different options for continuity of the server bit of the project…
- Do nothing. The existing
apistarversions won’t disappear so you just stay pinned to them. (Possibly we continue to accept a critical bug PRs against a 0.5.x branch and roll releases against that.)
- Have a fork of the project, under a different name. The only concrete changes here are that someone else would be doing the maintainance other than me, and that projects would need to change the import name to update.
- Forget about the DI layer, but make sure that there is suitable documentation and support for using
apistar's type system and API docs together with starlette.
- I start a new project that combines
apistar's types and API docs, with
starlettefor the base framework, and just adds in the DI layer and API docs. (ie. a continuation of
apistar's server, but with a clear set of boundaries between the different projects.) I’m not especially keen on this right now, since I’ve got a lot of other plates spinning, but it’s not something I’ve ruled out.
Happy to take feedback on the above, but one way or another I’m going to continue pushing forward with this, and need to make sure everyone’s aware of where my own maintenance priorities lie.