Discoverability of the ASGI ecosystem

Hey,

One of the selling points of ASGI is to serve as a common interface for enabling a wide ecosystem of frameworks, apps, libraries and tools.

I think it does a great job in this regard — there is a growing number of projects made interoperable thanks to ASGI.

But at the same time, I feel it’s harder and harder to keep track of everything. Starlette and Uvicorn have “third-party packages” sections on their websites, so it’d be interesting to federate this approach more.

I’m opening this for discussion after I learnt about @erm’s asgi-s3 — the idea struck me again that it would be cool for ASGI-related projects to be showcased somewhere. Hopefully this would increase discoverability as well as usage of those projects.

In terms of types of resources, some are code-oriented, e.g.:

and some aren’t, such as:

If we wanted to build a central index of some kind, I see two main options:

  • A static list, e.g. an ASGI awesome list (but who would have authority on whether an item is awesome?).
  • A dynamic solution, e.g. a web directory similar to Django Packages.

I think the static solution would be much less maintenance, but if hosted as a GitHub repo it raises the question of governance and authority. OTOH a website such as Django Packages seems like a more self-governed solution, but would require more maintenance to make sure the website stays up.

So, what are everyone’s thoughts on this?

1 Like

That’s a great idea!
And it’s really important to see the scale of the ecosystem.
“awesome list” seems to be nice, but it would be awesome to also consider something like “Are we … yet” pages, eg. https://www.arewewebyet.org.

1 Like

I’d keep it simple and just go with something static.

I don’t think there’s any governance stuff to worry about either, it’s just a.n.other collaborative resource, and it’s okay for someone to be proactively taking the lead on that, even if that means they need to be making some curation judgements on what goes where etc.

It might be worth raising an issue on the asgiref repo about this. Perhaps the ASGI docs themselves would be an okay place to link out to resources from, so long as it’s done reasonably. (I’d also be a bit tempted to suggest spinning the ASGI spec/docs out from the asgiref package, into a python-asgi GitHub org or something like that.)

1 Like

Oh, yes. I was wondering where to raise this for discussion and the asgiref repo seems more suited indeed. I’ll open an issue there.

Agreed! It might be a good opportunity to give ASGI its own space indeed.

Issue’s up here:

1 Like