Scope of project

[shulcsm]

Hey, just wondering about the scope and long term goals.

Since there is TLS termination i assume this is designed in way that this can be run on the edge (without reverse proxy or other servers in front).

If that is the case would you consider adding:

• static file serving
• some naive rewrite rules

Also could you expand on goals and differences between ASGI/RSGI?
Have you voiced your concerns with ASGI people?

[gi0baro]

I think the description of the project is quite straight-forward:

A Rust HTTP server for Python applications

Given this statement, Granian has – and will have in the future – the same scope of projects like Gunicorn, Uvicorn, Hypercorn, etc.
And you can use also those projects on the edge, but still to serve a Python app.
This means Granian will never be something like Nginx, and it won't act as a reverse proxy: it would make no sense, as a pure Rust solution would be dramatically more efficient.

For instance, you can write a Python app which serves static files using Granian and the RSGI protocol in a few lines of code, eg:

import os

async def app(scope, protocol):
    path = scope.path.removeprefix("/")
    if not path:
        return protocol.response_empty(404)
    file_path = os.path.join(os.getcwd(), path)
    if not os.path.exists(file_path):
        return protocol.response_empty(404)
    headers = some_function_to_get_content_type_and_len_from_file(file_path)
    protocol.response_file(200, headers, file_path)

While I'm not sure about a use-case for "rewrite rules".

Also could you expand on goals and differences between ASGI/RSGI?

Well, RSGI born with a couple of intents, specifically:

• Facilitate the Rust-Python intercom
• Optimize some inefficiencies of ASGI protocol, like the unneeded double await to send response head and body (but RSGI still lack a buffered/streamed response type)

I'm not sure about the adoption of RSGI, since it's both very specific and new; let's say at the moment is not in the project goals to spread RSGI popularity, but rather evolving the standard based on the need of Granian itself.

[shulcsm]

Most pre-async python appservers strongly discourage direct http termination/exposure without reverse proxy.
Regarding the features i wasn't expecting a full "webserver" or reverse proxy.

The use case for both features is deploying SPAs with python backend. I'm evaluating options to move away from uWSGI (know it's a very opinioned kitchen-sink and i'm not suggesting going there.) since i want ASGI and async.

Serving statics with python seems like waste. I will just stick with nginx.
Thanks.

[gi0baro]

Serving statics with python seems like waste. I will just stick with nginx. Thanks.

You actually use Python just to populate headers, Rust handles the IO part. For sure it won't beat nginx, but I'm pretty sure it would outperform any other Python server. Probably I should add the example to benchmarks.

[gi0baro]

Anyway, if you can provide some "real-world" use cases for both features, so we can write down an idea of the implementation, I can consider adding such features to Granian. It might be useful for several people out there.

[cirospaciari]

Serving statics with python seems like a waste. I will just stick with nginx.

Serving static files in most Python servers/web frameworks just performs very poorly, Nginx probably will outperform any current Python solution for this, but is great in the development mode for simplicity, in production mode always using something like Nginx is recommended basically in any language.

Granian can add a file extension to ASGI/WSGI to help serve files, but I do not see why it is worth it.

@gi0baro
One good use case is an option on CLI tools with hot reloading it will help a lot in the development. I have it planned for socketify cirospaciari/socketify.py#61 , but my issue is missing the option of the static file path.

I see RSGI as a great opportunity to show how inefficient is ASGI, that's why I also working in something like RSGI for my project, just want to push the boundaries of Python performance up and up.