Django, sendo um framework web, precisa de um servidor web para operar em um ambiente de produção. Como muitos servidores webs não “falam” nativamente a linguagem Python, é necessária uma interface para que o servidor web consiga servir um sistema desenvolvido em Django. Django 4 atualmente suporta duas interfaces: WSGI e ASGI. Em relação ao uso dessas interfaces, é correto afirmar:
- A)WSGI é uma interface que foi desenvolvida para substituir a antiga interface ASGI.
Errada, porque WSGI não foi criado para substituir ASGI; na verdade, ASGI é que veio depois para ampliar o modelo suportado.
- B)Um exemplo de servidor web WSGI é o Uvicorn, enquanto um exemplo de servidor ASGI é o Gunicorn.
Errada, porque Uvicorn é um servidor ASGI, enquanto Gunicorn é tradicionalmente associado a WSGI, embora possa operar com workers compatíveis.
- C)WSGI, também conhecida como “Web Socket Gateway Interface”, permite que o servidor web possa responder a requisições HTTP assim como o protocolo WebSocket.
Errada, porque WSGI significa Web Server Gateway Interface, não Web Socket Gateway Interface, e ele não foi criado para WebSocket.
- D)no Django, o comando “startproject”, executado a partir do “manage.py”, cria, automaticamente, o arquivo “asgi.py” contendo uma configuração default para servir a aplicação ASGI por um servidor web.
Certa, porque o startproject do Django cria automaticamente o arquivo asgi.py com configuração padrão para uso da aplicação em ambiente ASGI.
Gabarito: D
Para colocar um projeto Django em produção, voce precisa de uma ponte entre o servidor web e a aplicação Python. É aí que entram as interfaces como WSGI e ASGI: elas definem como o servidor conversa com o aplicativo. Pense nelas como um tradutor bem comportado, porque servidor web normalmente não entende Python nativamente. WSGI é a interface mais antiga e foi pensada para o modelo síncrono, tradicional, muito usada em aplicações web clássicas. Já a ASGI surgiu para ampliar esse cenário, permitindo suporte a assíncrono e a recursos modernos como WebSocket. Em resumo: WSGI é o caminho “tradicional”, ASGI é o caminho mais moderno e flexível. No Django, o comando startproject cria, automaticamente, entre outros arquivos, o asgi.py, que já vem com uma configuração padrão para expor a aplicação via ASGI. Esse arquivo serve justamente para facilitar a inicialização da aplicação em servidores compatíveis com ASGI, como parte da configuração padrão do projeto. Por isso, a alternativa D está correta: o Django realmente gera o arquivo asgi.py automaticamente, preparando a aplicação para uso em ambientes ASGI. Em provas, vale lembrar que WSGI e ASGI não são servidores, e sim interfaces de comunicação; os servidores é que implementam esse suporte.