Vale a pena dar uma olhada no Litestar

• Litestar é uma joia menos conhecida entre os frameworks web assíncronos de Python
• Graças à rápida escalabilidade e à arquitetura flexível, pode ser aplicado com facilidade a vários tipos de projeto
• Oferece modelagem de dados sem dependência de bibliotecas específicas, como Pydantic
• Tem uma excelente integração com SQLAlchemy, com pontos fortes na conexão e no gerenciamento de banco de dados
• Com recursos nativos práticos como autenticação, cache, logging e monitoramento, pode ser usado diretamente em projetos reais

---

Visão geral do Litestar

• Nos últimos anos, frameworks web Python async-first e baseados em type hints ganharam destaque, e o Litestar foi um deles escolhido para acumular experiência de uso
• À medida que foi adotado como framework principal em vários projetos reais, a confiança nessa escolha só aumentou
• Como muitos desenvolvedores web Python ainda não conhecem o Litestar, este texto apresenta suas principais vantagens e diferenciais

Exemplos e comparação com outros frameworks

• O Litestar permite escrever com facilidade até mesmo uma aplicação web de arquivo único muito simples

  • O route decorator é uma função independente, não vinculada ao objeto da aplicação
  • No código de exemplo, ao acessar /greet?name=Bob, o retorno é “Hi, Bob!”
  • Se um parâmetro obrigatório estiver ausente, uma resposta 400 é fornecida automaticamente

• Diferentemente de microframeworks Python tradicionais como Flask e FastAPI, o Litestar tem características estruturais que permitem escalar de forma natural em projetos de vários tamanhos

  • Em Flask ou FastAPI, os decorators de rota ficam vinculados ao objeto da aplicação, o que pode gerar problemas de importação circular ao separar em vários arquivos
  • Em geral, é preciso usar um registro de rotas subordinado (no Flask/Quart, blueprint; no FastAPI, APIRouter etc.), o que eleva a barreira de entrada ou exige mudanças na estrutura
  • Já no Litestar, como o decorator é uma função independente, a transição entre um app de arquivo único e uma estrutura distribuída de grande porte é bem mais simples

• Graças à arquitetura básica e à forma como a documentação é organizada no Litestar, é possível apresentar desde muito cedo os conceitos de roteadores e agrupamento de funcionalidades, o que facilita manter consistência mesmo em APIs complexas

  • Injeção de dependências, permissões e compartilhamento de config por rota são pontos fortes da sua composability
  • Também é possível registrar a mesma rota várias vezes para aplicar autenticação ou dependências diferentes conforme o ambiente

Modelagem sem dependência de Pydantic

• FastAPI e outros frameworks têm forte dependência de dados em Pydantic

  • O Pydantic é forte em validação e serialização de dados baseadas em tipos, mas a integração direta com ORM (SQLAlchemy) é difícil
  • Na prática, isso traz o incômodo de precisar escrever separadamente os modelos SQLAlchemy e os modelos Pydantic

• O Litestar oferece suporte genérico não só a Pydantic, mas também a dataclasses, msgspec, attrs e modelos SQLAlchemy, entre outros tipos

  • Conta com um protocolo de plugin de serialização, aumentando a extensibilidade
  • Inclui extração automática de DTO (objeto de transferência de dados), de modo que, ao alterar apenas a classe de dados original, o DTO é refletido automaticamente
  • Também é simples declarar exclusão ou inclusão parcial de campos, mapeamento de nomes e DTOs para atualização parcial
  • Assim, é possível evitar declarações duplicadas de campos de modelo e erros frequentes no processo de sincronização manual

Integração com SQLAlchemy e introdução ao Advanced Alchemy

• O SQLAlchemy ORM é, na prática, o padrão de fato para integração com banco de dados em Python

  • O Litestar se destaca muito em integração, com serialização automática de esquemas do SQLAlchemy, automação de DTO, plugin de gerenciamento de sessão e plugins compostos

• A biblioteca Advanced Alchemy (mantida pela equipe do Litestar) amplia os recursos do SQLAlchemy

  • Ela oferece várias melhorias de qualidade, como PKs grandes agnósticas ao banco, timestamps automáticos, chaves UUID, tipo JSON, integração com migrações Alembic e Seed/Export
  • Um recurso particularmente notável é o suporte à abstração de repository e service layer, fornecendo automaticamente várias funções de repositório, como CRUD e paginação
  • Em frameworks que, ao contrário do Django, oferecem menos orientação estrutural, isso cria uma forma de organização recomendável para adotar repository/service layer

Outras características e recursos nativos

• O Litestar também fornece internamente sistema de autenticação (funções guard, middleware), cache (stores), logging, respostas de erro padronizadas, métricas baseadas em Prometheus/OpenTelemetry e suporte a htmx
• Ao contrário de outros microframeworks, em algumas implementações não é necessário procurar bibliotecas externas separadas nem escrever glue code customizado
• Mantendo a simplicidade de um "microframework", ele ainda permite usar imediatamente extensões ou recursos adicionais quando necessário
• Mais do que um substituto para Django/Flask, a ideia é incorporar de forma Pythonic pontos fortes de frameworks de outras linguagens, como o Java Spring Boot (estrutura inicial + conveniência)
• No geral, é uma opção com alta produtividade e vantagens estruturais para desenvolvimento web em Python no mundo real

Conclusão

• O Litestar surge como um framework que qualquer desenvolvedor Python web deveria considerar pelo menos uma vez, graças ao seu modelo assíncrono, tipado, com expansão flexível, modelagem de dados menos acoplada, excelente ORM e recursos nativos robustos
• Com o uso repetido em projetos reais, foi possível confirmar sua alta produtividade e manutenibilidade em diversos contextos, incluindo startups
• A expectativa é que desenvolvedores considerem o Litestar como uma das opções ao planejar seu próximo projeto web em Python

[minhoryang]

A questão do "import circular" em Python não tem uma solução bem definida? Fica um pouco difícil considerar isso um problema grave.

[GN⁺]

Comentário no Hacker News

• Nos últimos 12 meses venho desenvolvendo um projeto de backend de grande porte com FastAPI. Comecei seguindo o estilo do tutorial oficial, mas me incomodou o template oficial do FastAPI mandar colocar todo o CRUD em um único arquivo e a forma como a gestão de dependências é feita. Ao usar SQLModel, também encontrei várias limitações, como a falta de suporte a modelos polimórficos, e isso me fez questionar se a manutenção do projeto está realmente em dia, já que mesmo PRs de melhoria enviados pela comunidade ficavam meses sem sequer revisão. A documentação também carecia de referências realmente úteis para uso prático, então no fim eu tive que vasculhar até o código-fonte. Para criar CRUDs rapidamente ele até serve, mas para construir sistemas complexos parece mais colocar outro framework em cima do framework, então não pretendo recomendá-lo. A partir de amanhã, planejo migrar para o Litestar
  • Se você quiser estudar um caso realista de app grande em FastAPI, acho que vale a pena olhar o código do servidor no repositório polarsource/polar. Há bons exemplos reais de autenticação, testes e escala, então pretendo aprender acompanhando a forma como esse repositório foi implementado
  • Estou começando a aprender sobre arquitetura e ferramentas para projetar apps centrados em API, e aprendi muitos pontos que eu não tinha considerado neste texto. Também estou pensando em experimentar o Litestar. Obrigado pelas observações e pelo texto útil
  • Não concordo que o SQLModel receba ênfase excessiva no tutorial oficial do FastAPI. Na tela inicial ele nem é mencionado, e só aparece na página que explica conexão com banco de dados relacional. Usar um ORM específico no tutorial é uma escolha natural, e se SQLModel não servir, acho que cabe ao usuário escolher outra opção. Eu mesmo, ao ver o tutorial, decidi usar SQLAlchemy puro
  • Lendo a documentação do Litestar, vi que ele também já traz um sistema de eventos embutido. É algo que levei semanas para implementar separadamente no FastAPI, mas no Litestar já vem pronto desde o início
  • Fico pensando se o Litestar também não teria algumas limitações. Mesmo tendo menos comunidade, documentação e discussão do que o FastAPI, você acha que ele ainda é mais adequado para aplicações complexas? Queria ouvir sua opinião
• O Litestar é excelente para construir backends de API. Eu uso diretamente e recomendo fortemente. O Advanced Alchemy também está ficando cada vez melhor. Dá para criar tranquilamente até sites antigos com renderização de template no servidor usando Litestar, e ele também já inclui plugin para HTMX. Ainda assim, os padrões voltados ao design de endpoints de API ficam um pouco estranhos em endpoints tradicionais renderizados no servidor, com validação de formulário, redirecionamento e afins. O Litestar em si não tem um recurso de processamento de formulários no sentido mais completo, então é difícil lidar direito com erros por campo individual do formulário. O padrão usando @post("/route", exception_handlers={...}) parece meio estranho. Espero que no futuro haja ferramentas nativas melhores e uma experiência de desenvolvimento mais refinada
  • Nunca usei o Litestar diretamente, mas talvez desse para resolver toda a parte de formulário criando um decorator próprio como @postform
• Litestar é um framework web em Python. Deixo essa informação primeiro para quem estiver curioso
  • Teve até gente dizendo que isso já fez economizar tempo
• Há mais de um ano estou servindo juntos JSON e HTML baseado em templates com Litestar. Ele é mais rápido que o FastAPI e é um framework async em Python leve, mas com recursos essenciais bem cobertos, como autenticação e sessão. Gostei especialmente do suporte a msgspec e ao roteamento aninhado baseado em Controller. Recomendo fortemente
  • Eu também migrei um projeto novo de FastAPI para Litestar e estou usando sem arrependimentos. Só a base padrão do Litestar já me transmitiu uma sensação clara de solidez e confiabilidade
  • Uso FastAPI há alguns anos, mas o Litestar certamente parece algo que vale muito a pena experimentar pelo menos uma vez
• Desenvolvendo aplicações com FastAPI por alguns anos, senti frustrações parecidas. Muita gente diz que a documentação do FastAPI, focada em tutoriais e exemplos, fica distante da realidade do desenvolvimento prático e da medição real da qualidade de uma API. Surpreende ver como esse ponto é criticado com certa frequência
  • Ultimamente tem sido uma grande decepção ver que toda a documentação de frameworks Python está parecendo documentação de biblioteca JavaScript, algo como “tutorial + blog prolixo”, mas sem referência suficiente sobre detalhes da API e explicação de parâmetros. Precisamos de documentação de referência de API de verdade. Quero opções detalhadas por método, parâmetros organizados, e que as opções sejam descritas corretamente em vez de frases jogadas em comentários. É muito incômodo ter que ir até o código-fonte sempre que se quer uma informação realmente clara
• O FastAPI também é utilizável, mas tem bastantes limites quando se tenta construir apps complexos. Às vezes me surpreende como o ecossistema Python de microframeworks parece estar redescobrindo, com atraso, problemas que o JavaEE já tinha enfrentado 15 anos atrás. O Litestar parece bem interessante. Também tenho curiosidade sobre práticas para lidar com casos de erro em streaming
• O FastAPI é popular, mas em projetos pequenos eu fiquei muito satisfeito usando só Starlette. Não tem tudo, mas para serviços simples não falta nada. O Litestar parece estar em uma faixa mais próxima de FastAPI ou Django
  • Ultimamente tenho feito APIs só com Starlette, e ele é limpo, conciso e tem documentação oficial boa, então escala bem independentemente do tamanho do projeto
• Sempre tive interesse no Litestar, mas ainda não usei na prática. Já uso FastAPI há bastante tempo, e acho um pouco exagerada a ideia de que é difícil gerenciar uma base de código grande com FastAPI. Separando as rotas em vários arquivos e importando para formar uma estrutura em árvore grande, já consegui escalar bem. Ainda assim, concordo que falta orientação oficial na documentação sobre estruturação em grande escala. Seguindo boas práticas e dividindo arquivos por módulos conforme preferência pessoal, dá para garantir boa escalabilidade. Nunca usei SQLAlchemy diretamente com FastAPI, então talvez eu não consiga me identificar com esse tipo de dor
• O texto acertou em cheio em pontos importantes do desenvolvimento de apps no mundo real. O design do Litestar é realmente atraente. Também fiquei no aguardo da opinião sobre o padrão de repositório. Seria ótimo ver isso desenvolvido em um post separado
• O texto foi bem interessante. SQLAlchemy é difícil de lidar e tem um estado interno complexo, com muitas coisas surpreendentes, então fico curioso se algumas pessoas simplesmente desenvolvem sem usá-lo
  • Recentemente usei peewee em um projeto pessoal e, embora não tenha muitos recursos extras, ele faz bem o trabalho dele
  • Há uma diferença grande entre o SQLAlchemy tradicional e o Advanced Alchemy do Litestar, que também é baseado em SQLAlchemy. Antes eu usava SQL puro ou SQLAlchemy, mas ao migrar do django ninja para Litestar venho reduzindo bastante o uso direto de SQLAlchemy
  • O ponto mais interessante desse projeto é que ele parece compensar, até certo ponto, as desvantagens do SQLAlchemy. Sempre que começo um projeto que precisa de banco de dados, acabo voltando para Django. SQLAlchemy e Alembic são dores que eu realmente preferia evitar
  • Acho que a forma mais realista de usar SQLAlchemy é definir esquema e migrações com modelos e Alembic, e fazer consultas e transações reais direto em SQL. Gasta-se tempo demais tentando reconstruir queries com ORM
  • Eu uso bastante asyncpg