Adding Maintainers?


#1

I’m a massive fan of APIStar but development does seem to stall occasionally! There seem to be a bunch of outstanding PR’s again, I understand Tom is extremely busy and can’t really devote much time to this project, so is adding some more maintainers a possibility ?


#2

Wouldn’t be unreasonable. I’m open to it, but let’s start with my getting on board with resolving any big blocking bugs to start with.

I guess my reticence is around the fact that the underlying blockers on moving the project forward are things that’ll need my time:

  • Splitting out the API docs and client tooling from the server. (Motivation: Have that tooling be a stand-alone framework independent project, it’ll also fit in much better with the hosted API docs service I’ve got on the back-burner if the server stuff is a separate project.)
  • Switching to ASGI as the only interface, but supporting both sync and async code. (Motivation: Pull out tons of complexity, get proper streaming responses and websocket support, more focused project.)

I’m also a bit lukewarm because functionality-wise I generally don’t want to be pulling much in. I’d far rather push for as minimal an interface as possible, but ensure that middleware, components etc… are well supported, so developers can build whatever additional behavior they want out as third party packages.

What tickets are proper bug-causing issues that need resolving right now?


#3

As a shameless plug - I think my PR #608 could be a minimal change that might open up some functionality to 3rd parties, in terms of expanding options for serialization / deserialization :slight_smile:


#4

@tom https://github.com/encode/apistar/issues/606 is a pretty big issue.