search

sparckles / Robyn

Robyn is a Super Fast Async Python Web Framework with a Rust runtime.
https://robyn.tech/
BSD 2-Clause "Simplified" License
4.23k stars 215 forks source link

ASGI Implementation #27

Open sansyrox opened 3 years ago

sansyrox commented 3 years ago

Robyn will follow the PEP guidelines required to confirm to ASGI specifications.

What this means is that the user/developer will still have the ability to use their preference of ASGI server in front of the framework.

Having said that, most *sgis are written in CPython and they are theoretically slower than their rust counterpart. Robyn will focus on speed and that's why Robyn will also ship with a server implementation. This server will also act as an ASGI but being coupled with Robyn will prioritise Robyn and hence is not being shipped as another ASGI written in rust.

If I ever feel that I am maintaining two projects(SGI and a framework) instead of one(just robyn) we would create two separate projects. Otherwise, if there comes another SGI in the future that is written in Rust or faster than my implementation, we will kill the SGI in Robyn.

TL;DR

sansyrox commented 3 years ago

What I'd suggest you do is add "just" a few functions: Robyn::mount_asgi, Robyn::mount_wsgi, Robyn::asgi_app, and Robyn::asgi_app (1&2 and 3&4 could potentially be merged if you wanted to manually detect which type the app was). 1&2 would be used when the user wanted to serve an app in a different framework from Robyn (either as part of a larger Robyn app or using Robyn as a replacement for e.g. uvicorn) and might (see above disclaimers) be able to take advantage of multiple cores for both Robyn's routing, network code, auth, etc. 3&4 would be used when you wanted to serve Robyn apps as part of an existing WSGI/ASGI application, and would "only" provide true multi threading for routing, auth, etc. and as such would have less of a theoretical performance boost.

From reddit.

sansyrox commented 3 years ago

If I end up adding ASGI support, I would be using a predefined framework and a predefined router. This way, I would end up implementing a lot of code twice!

Even with this ASGI support, robyn would have two different routers. One that is implemented natively and the other one implemented through ASGI.

When running through ASGI , robyn will be unable to use the Tokio runtime that is a core part of the application. This includes the routing awaiting and the responses.

Since these are one of the top priority features that I need to implement at the moment. I am unable to see any benefits to add ASGI support at the moment. Should a very good benefit be highlighted, we can re discuss this.

TL;DR: Little to no plan of ASGI implementation in the near future. If anyone can guide me to a snippet where I could reuse the same runtime and router and implement an ASGI support, then we could have a discussion.

Current Priorities: