FastUI: crie interfaces web melhores e mais rápidas com Python

• O FastUI é uma nova forma de construir interfaces de usuário para aplicações web com código Python declarativo
• Um conjunto de modelos Pydantic e interfaces TypeScript que definem a interface de usuário
• Se você é desenvolvedor Python, pode criar webapps reativos com React sem usar JavaScript nem npm
• Desenvolvedores frontend podem se concentrar em criar componentes reutilizáveis sem precisar copiar e colar toda vez
• Para todos os usuários, isso permite uma separação real de responsabilidades, em que o backend define toda a aplicação e o frontend implementa apenas a interface de usuário
• Fornece diversos componentes prontos: autenticação baseada em token, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm

Como usar na prática

• O FastUI é composto por quatro partes:
  • Pacote PyPI fastui: fornece modelos Pydantic e utilitários para componentes de UI. Funciona muito bem com FastAPI, mas não depende de FastAPI e também pode ser usado com outros frameworks web em Python.
  • Pacote npm @pydantic/fastui: um pacote React TypeScript que permite reutilizar a infraestrutura e os tipos do FastUI ao implementar seus próprios componentes.
  • Pacote npm @pydantic/fastui-bootstrap: implementa/personaliza todos os componentes do FastUI usando Bootstrap.
  • Pacote npm @pydantic/fastui-prebuilt: fornece uma versão pré-compilada do app React do FastUI sem necessidade de instalar pacotes npm nem compilar nada manualmente. O pacote Python fornece uma página HTML simples para servir esse app.

Princípios (versão longa)

• O FastUI é uma implementação dos princípios RESTful, mas não no sentido em que costumam ser entendidos, e sim conforme definidos na tese de doutorado de Roy Fielding.
• De acordo com os princípios RESTful, o frontend não precisa conhecer a aplicação que está sendo construída; ele só precisa fornecer todos os componentes necessários para compor a interface.
• Construir aplicações dessa forma traz várias vantagens importantes:
  • É preciso escrever código em apenas um lugar para criar novas funcionalidades.
  • É possível separar completamente o deploy do frontend e do backend.
  • É possível reutilizar um conjunto de componentes open source, já que eles não precisam conhecer o contexto em que serão usados.
  • É possível garantir, com Pydantic, TypeScript e JSON Schema, que ambos os lados estejam se comunicando com um esquema acordado.

Além de Python e React

• Esse princípio não se limita a aplicações em Python e React; ele pode ser usado em qualquer frontend e backend que implementem o esquema, desde que se comuniquem usando o mesmo esquema e a mesma codificação acordados.

Opinião do GN⁺

• O FastUI tem potencial para simplificar o processo de desenvolvimento ao oferecer uma forma eficiente de desenvolvedores backend expandirem aplicações sem depender de desenvolvimento frontend.
• Essa tecnologia deixa mais clara a divisão de papéis entre frontend e backend, criando um ambiente em que a especialidade de cada lado pode ser melhor aproveitada.
• Como o FastUI ainda é um projeto em andamento, é preciso avaliar cuidadosamente sua estabilidade e funcionalidade antes de usá-lo em um ambiente real de produção.
• Ao adotar o FastUI, é importante considerar a compatibilidade com o fluxo de desenvolvimento frontend existente, a reutilização e a escalabilidade dos componentes, além da manutenção de longo prazo do projeto.
• Os benefícios dessa escolha podem incluir menor tempo de desenvolvimento e um fluxo centrado no backend, mas em contrapartida a flexibilidade do frontend pode ficar limitada, e o suporte da comunidade e a disponibilidade de materiais ainda podem ser relativamente escassos.

[GN⁺]

Opiniões do Hacker News

• Opinião sobre o acoplamento entre a camada de apresentação e o código

  • Acoplamento entre a camada de apresentação e o código: a camada de apresentação não deve estar conectada de forma excessivamente estreita ao código. Uma linguagem de templates, em vez de Python, seria mais adequada, e seria melhor poder renderizar templates em várias linguagens.

• Experiência de desenvolvimento de apps com FastUI e Streamlit

  • Uso de FastUI e Streamlit: foi feito prototipagem com Streamlit, mas às vezes ele pareceu incômodo. O FastUI ainda tem pontos a melhorar, mas foi usado para apps leves e apresentou tempos de resposta mais rápidos que o Streamlit.

• Opinião sobre Django e HTMX

  • Django e HTMX: a combinação de Django e HTMX é elegante e funciona rápido. Ela envia apenas o código renderizado para o frontend e permite gerenciar o banco de dados quando a aplicação cresce.

• Utilidade prática de apps internos para lidar com eventos no lado do servidor

  • Tratamento de eventos no lado do servidor: esse conceito não é novo, e há outros exemplos como o Solara, baseado em React, e o NiceGUI, baseado em Vue. É muito prático para apps internos, mas é preciso aceitar um pouco de latência ao tratar eventos de todos os controles no servidor.

• Aumento de frameworks de frontend que exigem um servidor backend

  • Complexidade dos frameworks de frontend: muitos frameworks de frontend precisam executar um servidor backend para renderizar HTML básico. Fica a dúvida se os recursos oferecidos por esses frameworks realmente justificam essa complexidade.

• Comparação entre as experiências com FastUI e NiceGUI

  • FastUI e NiceGUI: o NiceGUI oferece uma experiência boa de usar desde o primeiro momento. O FastUI parece ser principalmente um adaptador de formulários para modelos Pydantic.

• Impacto do avanço da IA nos casos de uso desses projetos

  • IA e desenvolvimento frontend: a ideia de permitir que desenvolvedores backend criem UIs rapidamente na própria linguagem continua válida, mas a necessidade desses projetos pode enfraquecer, já que hoje é possível usar IA por algumas horas para gerar uma UI básica.

• Experiência de desenvolvimento de side projects com Dart/Flutter

  • Uso de Dart/Flutter: escrever side projects em Dart/Flutter reduz o atrito e dá menos trabalho. Se fosse necessário criar um app web e o Flutter não fosse adequado, a escolha seria o HTMX.

• Comparação com Java Server Faces e limites da abstração no lado do servidor

  • Experiência com Java Server Faces: isso parece semelhante ao Java Server Faces. Tentar transferir as sutilezas do desenvolvimento frontend para abstrações no lado do servidor provavelmente só funcionará em um conjunto limitado de aplicações, como interfaces de administração.

• Questionamento sobre se o round trip com o servidor é adequado para construir interfaces de usuário

  • Round trip com o servidor: levanta-se a dúvida se fazer uma ida e volta ao servidor a cada interação do cliente é realmente uma boa ideia para construir interfaces de usuário.