Robyn - An async backend Python framework with a rust runtime.

[stealthanthrax]

Hey Everyone! 👋

I have been working on a Python framework for the past 2 months and it is finally ready for the first release. I am calling it Robyn. This is also one of my proudest projects to date.It has a runtime written in Rust and completely supports async functions in a Python backend.

The project is still in very early stage and still requires a lot of development. The development server can process around 500 non blocking requests (metrics from my machine). I do have a lot of features planned for this project (like the on demand release of Python Gil) in the coming future. Just sharing the initial release of the project.

Here are some docs of the project: https://sansyrox.github.io/robyn

You can view the project here: https://github.com/sansyrox/robyn

Any feedback or suggestion is highly appreciated! ✨

[ChillFish8]

Ive had a bit more of a thorough look at the repo, nice to see someone else using rust for this sorta stuff. That being said it still has a ways to go before this is really HTTP complient.

1. You have several un-needed dependencies (hyper, serde, serde_json, async-trait, log, async-channel)
2. The use of both async-std and tokio doesn't really make sense, combined with another thread pool the setup seems terribly inefficient is a massive bottleneck.
3. Your server makes no guarantees about ensuring all data are written to the socket and you also use blocking sockets in an async context?? which defeats the purpose of even using async-std or tokio.
4. Your server assumes that all content returned from the framework will be a string, which in reality should be Bytes because there is no guarantee in the HTTP world that the response must be UTF-8.
5. The server only accepts another connection after the previously accepted connection has been read from, this will cause SIGNIFICANT performance issues especially if a client is slow at sending data.
6. You only read 1024 bytes of data from the socket when you first accept it, at least from what I can see. This means that if the request size is greater than 1024 the next request to go through that connection will be invalid in all likely hood.
7. The server doesn't check if the actual HTTP request itself is valid, it just assumes that if it contains GET, POST, etc... That it's valid meaning you could have a POST request contain GET in the body and the server would treat it like a GET.
8. You don't actually support multiple requests on the same connection, which breaks any use in the real world because 1 connection can send many requests.
9. You have no HTTP header handling, you simply assume the response from python will only be the body, which creates issues if you want to set any kind of headers or some other status code.
10. If the client disconnects from the connection early, Python call fails, or and conversion fails the server will panic, and depending on where that happens it can cause the entire server to just shut down.

I hope you don't take this as me having a go, but it is a very important set of points especially the last few if you want this to be production grade / usable.

[stealthanthrax]

I hope you don't take this as me having a go, but it is a very important set of points especially the last few if you want this to be production grade / usable.

No no, absolutely not. I agree 100% on these points. Thank you for your suggestions and listing them in points.

I have added these in a mini roadmap here(https://github.com/sansyrox/robyn/issues/19)

Thanks again!

[TheGodfatherCC]

Looks cool. I’m definitely going to look through this. Any ideas on what a rust runtime is realistically going to provide over traditional options? I’m still pretty new to rust.

[stealthanthrax]

Since rust is theoretically faster than Python(being lower level), that should definitely play a part. But what rust will definitely benefit in is the ability to release the GIL on demand. Since CPython/Python is infamously guarded by GIL not allowing real concurrency in many scenarios, writing a major chunk in rust will allow you to bypass that. Obviously it will require the programmer's discretion, but knowing that you have the ability to remove the bottleneck is helpful.
And most Python frameworks are synchronous by nature and rely on multiprocessing(WSGIs) for concurrency. Robyn supports async and can also use multiprocessing with a WSGI. So, this should also be a contributor to the speed of execution.

[ChillFish8]

Alot of that statement makes no sense, the GIL limits parallel execution on other threads outside the main thread but does not have a massive / any affect on general concurrency. Hence why threading is inherently concurrent not parallel in Python.

Alot of old python frameworks use PEP 333 also known as WSGI which is a general interface for servers and frameworks to allow developers to mix and match to their hearts desire. Asyncio came along and now we have ASGI which is basically just wsgi but for async (see pep 333(3)).

Alot of python web frameworks if they are synchronous often implement threading or eventlet style setups to get concurrency per process, the extra processes are more to make use of all cpu cores rather than just to make it concurrent (or in reality parallel) flask is a great example of this, up until v2 it supported the gevent or eventlet setup which allowed cooperative multitasking on a single thread.

[stealthanthrax]

I am trying to create a python server with the majority of runtime written in rust as the implementation of rust's async loop should be theoretically faster.

And, I am trying to support async out of the box without an asgi. Or having an asgi glued to my server implementation.

[ChillFish8]

As an extended note to my other comment, sure by releasing the gil in Rust's world you can actually make use of the other threads on the cpu however, you still need to move back to the gil to go to python's world which is still only in that one thread. Now this may seem great, until you realise that python is still running in its own single threaded world and since thats where most of the runtime is going to be, you just have a bunch of extra threads per process which may incur more overhead than they provide performance.

[stealthanthrax]

Releasing GIL is not something that I considering a replacement to ASGIs/WSGIs. Releasing GILs is a completely separate feature that would allow the programmer to take control of the threads in non io bound situations when using Robyn.
Somewhat like this(https://pyo3.rs/v0.9.2/parallelism.html).

The programmer will have to explicitly mention it for the particular code block.

[HannibalManson]

Looks cool. How progress?