Gunicorn: Adicionando suporte ASGI?

@arcivanov irei examinar mais de perto este protocolo para ver o que precisa ser feito para ele :)

Atualizará este tíquete o mais rápido possível.

alguma atualização?

@benoitc @berkerpeksag e eu conversamos por e-mail sobre isso. Nenhum trabalho foi iniciado, ainda, que eu saiba. Ainda não tive tempo de ler mais sobre o ASGI, então não posso estimar a complexidade de sua implementação. Se alguém quiser contribuir com um trabalho para isso, eu ajudaria, discutir e revisar com entusiasmo.

Estou em processo de revisão da especificação ASGI para fazer muito mais sentido para os servidores de qualquer maneira, então eu alertaria sobre fazer qualquer coisa até que isso seja concluído (uma nova especificação está sendo elaborada aqui, mas não é final: http: / /channels.readthedocs.io/en/2.0/asgi.html - é basicamente muito mais parecido com WSGI)

@andrewgodwin cool

@andrewgodwin qual é o status do ASGI?

Recentemente, tentei testar um aplicativo ASGI e aqui está o que consegui:

import json

def app(scope):
    async def channel(receive, send):
        message = await receive()

        if scope['method'] == 'POST':
            response = message
        else:
            response = scope

        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                [b'Content-Type', b'application/json'],
            ],
        })
        await send({
            'type': 'http.response.body',
            'body': json.dumps(response, default=bytes.decode).encode(),
        })
        await send({
            'type': 'http.disconnect',
        })
    return channel

> daphne app:app
2018-03-31 22:28:10,823 INFO     Starting server at tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,824 INFO     HTTP/2 support enabled
2018-03-31 22:28:10,824 INFO     Configuring endpoint tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,825 INFO     Listening on TCP address 127.0.0.1:8000
127.0.0.1:43436 - - [31/Mar/2018:22:28:17] "GET /" 200 347
127.0.0.1:43440 - - [31/Mar/2018:22:28:22] "POST /" 200 43
127.0.0.1:43446 - - [31/Mar/2018:22:28:42] "POST /" 200 54

> http -b get :8000/
{
    "type": "http"
    "http_version": "1.1",
    "method": "GET",
    "path": "/",
    "query_string": "",
    "root_path": "",
    "scheme": "http",
    "headers": [
        ["host", "localhost:8000"],
        ["user-agent", "HTTPie/0.9.9"],
        ["accept-encoding", "gzip, deflate"],
        ["accept", "*/*"],
        ["connection", "keep-alive"]
    ],
    "client": ["127.0.0.1", 43360],
    "server": ["127.0.0.1", 8000],
}

> http -b -f post :8000/ foo=bar
{
    "body": "foo=bar",
    "type": "http.request"
}

> http -b -j post :8000/ foo=bar
{
    "body": "{\"foo\": \"bar\"}",
    "type": "http.request"
}

https://github.com/django/asgiref/blob/master/specs/www.rst

@sirex ASGI está estável agora. Não tenho certeza se você está dizendo que a daphne segue ou não as especificações?

o link do django é o último sobre a "especificação" ASGI, ou há mais alguma coisa que descreva o fluxo?

@andrewgodwin Eu estava tentando demonstrar que, se o Daphne suporta ASGI, então o ASGI deve estar pronto para ser adotado por outras estruturas / servidores.

@benoitc existem duas páginas de especificações ASGI:

https://github.com/django/asgiref/blob/master/specs/asgi.rst - especificação ASGI geral.

https://github.com/django/asgiref/blob/master/specs/www.rst - especificações que descrevem os protocolos HTTP e WebSockets e compatibilidade com WSGI.

@sirex obrigado. Embora essas especificações não sejam muito úteis quando se trata de implementação.

De qualquer forma, encontrei https://channels.readthedocs.io/en/latest/ que está okish. Acho que preferiria um pep, mas podemos propor algo que suporte asgi assim que removermos o suporte do python 2.

A propósito, excluí o último comentário, pois não está relacionado a essa discussão.

Não mudei para fazer do ASGI um PEP, pois quero ter certeza de que ele tem suporte geral suficiente primeiro (e esse processo exige muito tempo e esforço), mas essa é a intenção e deve ser escrito como tal.

podemos propor algo que suporte asgi assim que removermos o suporte a python 2.

Se você começar a pensar na implementação, vale a pena começar com uvicorn , que cola gunicorn, uvloop e httptools. Pode muito bem fazer sentido que esse trabalho volte ao gunicorn como uma classe operária suportada em algum ponto.

(Pode ser bom para o uvicorn se tornar uma opção mínima, sem o monitoramento de processo etc. que o gunicorn fornece.)

A documentação de especificação ASGI agora está disponível aqui: https://asgi.readthedocs.io/en/latest/.

Ok, cuide disso agora. (Como uma classe de trabalhadores terceirizada.)

O Uvicorn 0.2 não depende mais do gunicorn para executá-lo diretamente, mas inclui duas classes de trabalho do gunicorn para executar aplicativos ASGI.

Para o desenvolvedor local, ou casos em que você não se preocupa o suficiente com a supervisão do processo, você pode simplesmente executar o uvicorn diretamente. Para produção, documentamos usando uma classe gunicorn como opção preferida.

http://www.uvicorn.org/#running -with-gunicorn

Execute o aplicativo ASGI do gunicorn, usando uvloop e httptools:

gunicorn app:App -w 4 -k uvicorn.workers.UvicornWorker

Execute o aplicativo ASGI do gunicorn, usando asyncio e h11 (para compatibilidade com pypy):

gunicorn app:App -w 4 -k uvicorn.workers.UvicornH11Worker

Se houver qualquer desejo de trazer qualquer uma das implementações de protocolo para o pacote principal do gunicorn, estou muito aberto a considerar isso.

Agora que gunicorn não suporta mais python 2 , é tecnicamente factível adicionar suporte para ASGI

@tomchristie Estou interessado em como seria. Como alternativa, talvez extraindo os protocolos como um pacote ou pacotes separados?

Estou interessado em como seria. Como alternativa, talvez extraindo os protocolos como um pacote ou pacotes separados?

Eu acho que uma classe de trabalho em gunicorn que dependia de uvicorn para os protocolos h11 e / ou httptools. Ou então duplique a implementação aqui.

A duplicação de uma parte limitada da implementação para fornecer suporte ASGI HTTP integrado ao Gunicorn com uma dependência h11 pode ser uma boa linha de base?

talvez extraindo os protocolos como um pacote ou pacotes separados?

Não há realmente muito para extrair de uvicorn - Se descartássemos click e apenas usássemos argparse e ajustássemos um pouco nossas dependências setup.py, então ele teria zero dependências rígidas, com várias opções para diferentes implementações de HTTP, implementações de WS, loops de eventos.

Eu gostaria de suporte ASGI de primeira classe, quer isso signifique adicionar dependências extras no Gunicorn, um stub worker que informa o que instalar, documentação ou algo mais.

sim por favor. prestes a mudar para daphne de gunicorn .. se gunicorn pudesse apenas suportar asgi
isso me pouparia muito tempo.

@japrogramer http://www.uvicorn.org/#running -with-gunicorn

Django 3.0 (com lançamento previsto para dezembro de 2019) terá suporte ASGI fora da caixa , então esse será outro grande motivo para gunicorn suportá-lo diretamente. Provavelmente veremos um grande aumento no interesse do usuário após o lançamento.

@johnthagen que está no tubo. Porém, precisamos esclarecer um pouco os ingressos e fazer um lançamento este mês antes de começar.