WSGI e o Pipe Dream plugável – Parte 02

Nesta segunda e última parte do artigo, serão abordadas algumas sugestões para melhorar o WSGI, entre outros assuntos. A primeira parte você lê aqui.

?

Todo mundo quer uma revolução

O WSGI está longe de não ter falhas. Mas o problema é que na maior parte das vezes em que as pessoas tentam substituí-lo é quando elas também tentam corrigir outros problemas que ele tem. Assim, ao invés de um pequeno passo adiante, trata-se de uma proposta inteiramente nova. Por exemplo, minha proposta de fazer isso com o Python 3 foi tão ingenuamente errada, que gosto de pensar que não trabalhei em substituir a PEP pelo WSGI, em primeiro lugar. E posso dizer por que uma evolução pequena do WSGI não faz sentido e por que um grande passo seria ainda pior:

Vamos fazer a seguinte pergunta primeiro: por que desejaríamos melhorar o WSGI? Superficialmente porque há algumas coisas que não funcionam ou são desnecessariamente complexas. Aí vem o problema: por razões diferentes.

Metade das pessoas quer os piores detalhes melhorados para simplificar as implementações de servidores e de bibliotecas do cliente, enquanto outras querem uma simplificação e uma extensão para suportar aplicativos plugáveis. E é aí em que tudo complica.

Vejamos o que poderia ser melhorado no WSGI:

1. O ‘wsgi.input’ é mal especificado, mas na prática raramente causa problemas porque a) metade dos servidores já está estendendo o WSGI e b) mesmo que metade das bibliotecas estiver sofrendo violações, somente nos casos extremos haverá problemas, que são raros
2. Os headers não podem ser transmitidos, o que seria um problema com respostas que tenham uma grande quantidade de headers.
3. Os trailers não são especificados de forma nenhuma, exceto para “servers might do chunked responses”.
4. Dados de pedido truncados são totalmente não implementáveis acima da especificação atual devido à má especificação de entrada do WSGI.
5. O WSGI pode ser difícil de implementar em um ambiente em que você esteja processando dentro de um servidor como o Apache que já esteja executando filtros de requisição fora de seu controle. No servidor Web, o WSGI assume que você não tem privilégios de acesso ao HTTP.
6. O WSGI estende o ambiente CGI e herda o problema de que caminhos são decodificados com perda de informação.
7. O mecanismo do start_response() parece desnecessariamente complexo para o fato de que quase ninguém hoje em dia precisa mais do exc_info ou do write() chamável.
8. O ‘wsgi.file_wraper’ é um lixo completo, porque na prática não funciona desde que os middlewares estejam envolvidos nesses processos de respostas.

Mas sabe de uma coisa? WebOb, Werkzeug, Django e todos os outros frameworks se adaptaram ao WSGI como ele é, e assim isso funciona para nós. Há alguns casos específicos para os quais adoraríamos que fosse melhorado, como o caso do input, mas dificilmente isso justifica estilhaçar a API.

Já escrevemos o código, e criar um novo spec nesse ponto apenas sustenta o sentimento de que “a coisa boa a respeito de padrões é que há tantos que podemos simplesmente escolher”. Especialmente agora que o WSGI foi estendido para lidar com o comportamento do unicode do Python 3, temos que ser muito cuidadosos para não arranjarmos mais complexidades na codificação de todo mundo.

Acima de tudo, contudo, muitos gostariam de ver resolvidas um monte de coisas que faltam no WSGI:

1. Permissão para que um aplicativo notifique o servidor que ele deseja ser recarregado no próximo pedido.
2. Ter um local documentado no aplicativo que seja executado antes do primeiro pedido, da forma mais eficiente possível, mas ainda com informação à mão, que de outra forma somente estaria disponível durante o pedido (como: qual é afinal minha localização? Qual é minha URL base etc.).

Mas aí está o problema: mudar o WSGI agora significaria apenas que teríamos que substituir todos nossos servidores WSGI, as implementações WSGI de clientes, frameworks bridges e sabe-se mais lá o quê. Teríamos que substituir nossos middlewares para adotarem novos ambientes de servidores, trabalharem com bugs de navegador, que implementam as funcionalidades profiling e debugging que cuidam dos erros de logging etc., etc. Já temos um monte deles que fazem a interface com o WSGI e que sabem como lidar com o protocolo.

Naturalmente, se pudéssemos chegar a um novo WSGI a partir do zero, faríamos diferente. Mas seria mais plugável? Provavelmente não, e aí vai o porquê.

O plug mágico

Adoro pequenos aplicativos que trabalham juntos. E a camada que permite que trabalhem juntos se chama HTTP. Mas não acredito nesse plug mágico chamado “aplicação plugável de framework independente”.

Não sei de onde apareceu a ideia de que isso possa funcionar, mas não pode. A ideia de que se pode reutilizar códigos em cima do WSGI para trabalhar como o Framework 1 e o Framework 2 não está funcionando. Se estiverem realmente divididos, naturalmente pode-se usar o WSGI como uma camada para conversar com ambos apps, dependendo de um pedido HTTP que tenha vindo para uma central de despachos.

Se o usuário desejar que 0 /app1 possa ser enviado para a aplicação 1, se o usuário for para o /app2, basta indicá-los para a aplicação 2. Mas isso é uma coisa que já posso fazer.

Mas é disso que se trata, não? Geralmente, a ideia é que se pode pegar qualquer valor de retorno de qualquer aplicativo WSGI e então ajustá-lo de forma a encaixar em nosso ambiente. A ideia é que um middleware possa olhar para dados de formulários que tenham sido fornecidos e os processar, ou faça qualquer coisa que não seja atualmente possível de fazer com o WSGI.

O que é necessário nesse ponto não é um novo WSGI: é necessário um mecanismo totalmente novo que lide com muito mais coisas do que o HTTP. Porque hoje fazemos muito mais do que há alguns anos.

Se quisermos substituir o WSGI, não seria o caso de substituir, mas de colocar uma nova camada por cima dele. Uma que tenha conhecimento pleno a respeito de tudo que acontece. Haveria uma biblioteca de pedido/resposta padronizada cobrindo qualquer caso que é atualmente necessário, e que seja extensível de forma a lidar com casos futuros.

Se tivéssemos feito o design de um objeto de pedido/resposta quando o WSGI foi criado em 2004, ele seria muito diferente do que sabemos a respeito de aplicativos web hoje. Naquela época, provavelmente teria suportado URL codificada nos dados do formulário e Xforms (que é a última moda). Hoje sabemos que ninguém usa Xforms, mas sim dados codificados em JSON, o que é muito comum hoje, ambos em entrada e em saída.

Há também a tendência generalizada em direção a servidores assíncronos e a frameworks. Isso é incrível, mas todos estão considerando o WSGI um obstáculo, e estão desviando dele. O que de novo significa que uma camada por cima dele não seria esse plug mágico, mesmo porque não trabalharia em ambientes “não WSGI”. Se quisermos caminhar nessa direção, o WSGI precisaria de uma atualização para fazer com que funcionasse melhor em ambientes assíncronos.

Para que lado ir?

De vez em quando, aparece alguém com uma ideia para substituir o WSGI. No final, entretanto, cada nova especificação não resolve o que as pessoas desejam: fazer os frameworks funcionarem melhor uns com os outros. Acho que a cola que juntará tudo não será no lado do servidor.

Não seria uma nova versão do WSGI, mas um client side JavaScript que sincronizasse a autenticação de uma parte do aplicativo com outra, sem que o usuário percebesse. Seria um JavaScript que fala com diversos servidores backend escritos em diferentes frameworks com linguagem compatível e então faria uma renderização disso para o cliente no que fosse necessário.

Pessoalmente, tenho bastante certeza de que o WSGI não tem mais a importância que tinha há alguns anos. Penso que não faz mais sentido fundir diferentes aplicativos em nível WSGI. Isso deve ser feito em um nível superior, e o JavaScript é uma forma bacana de fazer isso.

Pense na barra cinza do Google. Você pode colocar essa barra por cima de partes diferentes e independentes do aplicativo fazendo um pouco de JavaScript gerar essa barra e gerenciar sua sessão do usuário.

Em geral, o JSON via HTTP ou zeromq é muito mais bacana e flexível do que o WSGI poderia ser. Penso que se aceitarmos isso como um caminho possível na construção de aplicativos sem componentes e iniciarmos experiências com isso, poderíamos fazer algo realmente bom.

Mas isso é o pouco que tenho dizer a respeito sobre este tópico.

?

Texto original disponível em http://lucumr.pocoo.org/2011/7/27/the-pluggable-pipedream/