📝 Add FastAPI to Implementations

[tiangolo]

This adds FastAPI to the ASGI implementations 🎉 🚀

[adamchainz]

If we're going to mention Starlette derived frameworks, why wouldn't we mention Responder and Flama too? Both seem to be actively maintained. https://www.starlette.io/third-party-packages/#frameworks

[adamchainz]

The list is in alphabetical order and I presume we'd want to keep it that way, so move above Quart

[tiangolo]

Not sure if you want to mention Starlette-based frameworks, that's your call 🤷 ...I can add them too if you want. I think Sanic also supports ASGI now, that could probably go in there too.

Would you like me to add them or would you prefer to keep only Starlette here?

[jordaneremieff]

There was some discussion here touching on this topic more broadly. I think this PR is revealing how difficult it may be to sustain the implementation list in its current form. In this case specifically, the problem appears to be the lack of a definitive criteria for inclusion.

[tiangolo]

Thanks @ERM !

It makes sense, in that case, I guess it's probably fine to just close this issue.

And maybe we could add a pointer to https://github.com/florimondmanca/awesome-asgi from here as it has many other related resources.

[tomchristie]

Personally I think it'd make sense to include FastAPI, Responder, Flama yeah - they're all significantly different from each other, and significantly different from working with Starlette as a framework, so it'd be a clear thumbs up from me. I also don't think they necessarily need to mention on this resource that they happen to use Starlette. (Tho it's always appreciated on their own docs when they do)

[adamchainz]

I think it might be more sustainable to remove the list here and point to awesome-asgi only, otherwise there will be two community lists of implementations.

[tiangolo]

I guess we can close this PR as I imagine those changes would be in a different one, right?

On the other hand, I'm not sure how would you like to structure it after removing the "implementations" section and where to put the link to awesome-asgi. I guess it might be simpler if you add it directly in a way you're comfortable with... otherwise, would you like me to propose something?

[andrewgodwin]

Let's at least add FastAPI in for now (could you fix the ordering so it matches the existing alphabetical ordering?)

I agree it would be nice to just have awesome-asgi, but we can do this quickly now, and not block small easy changes on a harder, bigger change.

[tiangolo]

Cool!

Sure, done ✔️

[andrewgodwin]

Thanks! We should definitely look at awesome-asgi too, though.

[Kitty2014]

@tiangolo Whether FastAPI can support GRPC implementation?

[tiangolo]

@Kitty2014 it's probably better to ask it in an issue in the FastAPI repo to not pollute much here.

But the short answer is, not really.

FastAPI is designed for web servers/APIs, it is based on Starlette, Starlette is a web framework/toolkit, so it uses the ASGI sub-specs for HTTP and WebSockets. All that is handled and run by an ASGI server like Uvicorn that listens on the web ports and runs the application.

---

Now, about gRPC, ASGI:

GRPC would probably first need an ASGI sub-spec, then an implementation server. And then probably a framework for GRPC.

But gRPC already has all its own ideas, framework, and tools. If I remember correctly, the spec, communication, and everything are heavily based on protocol buffers, which in turn, are heavily based on a C++ implementation, that includes some quirks, for example, many object attributes can be both scalar values and sequences at the same time, and it heavily depends on classes (i.e. no dicts or lists) but without the benefit of classes, like static type checks, completion, etc, all that ends up being quite awkward in Python (I don't know if all that makes more sense in C++).

Also, if I remember correctly it's all quite tightly-coupled, and pretty much expects you to use their provided packages, so, being honest, if you have a simple problem and want to do gRPC you might be better off using those than through the whole route of the ASGI sub-spec. Of course, it would be totally feasible, but probably a lot more work.

---

Now, if what you want is a way to create some type of remote server that can easily communicate in a binary format with clients, then you can probably use FastAPI (or any other ASGI framework) with an ASGI middleware like https://github.com/florimondmanca/msgpack-asgi