Uma interface de agente não precisa escolher entre tudo nativo e tudo remoto

O Yelp adotou uma arquitetura híbrida no Yelp Assistant: navegação e entrada de mensagens permanecem nativas, enquanto a conversa é renderizada pelo framework CHAOS em web, iOS e Android.[10] A proposta é acelerar mudanças na apresentação suportada sem exigir uma nova distribuição do aplicativo para cada ajuste.[10] A escolha é interessante por preservar limites, não por eliminar o cliente.

O que muda para quem desenvolve

O CHAOS existente não oferecia todos os recursos necessários, incluindo entrada de texto e requisições de rede; ampliar o framework integralmente atrasaria a entrega.[10] A equipe manteve as partes nativas e usou renderização dirigida pelo servidor onde ela já atendia à necessidade.[10] Minha leitura: reaproveitamento pragmático pode ser melhor que exigir uma abstração universal antes de lançar o produto.

A configuração visual é buscada ao iniciar a conversa, enquanto mensagens posteriores atualizam um conjunto de eventos sem baixar essa configuração novamente.[10] O cliente continua responsável pelo estado interativo, como indicador de digitação, disponibilidade da entrada e tratamento de erros.[10] Compartilhar apresentação não faz essas responsabilidades desaparecerem.

Como aplicar

Em um protótipo de assistente, divida o contrato em três partes: configuração visual versionada, eventos persistentes e estados temporários. Defina explicitamente quem pode encerrar uma solicitação, habilitar entrada ou abrir um destino. Trate ações como operações permitidas por contrato, não como instruções arbitrárias vindas do servidor.

Uma prova de conceito útil começa com um único cartão de resultado. Preserve a composição de mensagens no cliente e troque apenas a configuração do cartão. Em seguida, simule eventos duplicados, resposta atrasada e componente desconhecido. Observe se a conversa permanece utilizável e se o estado pode ser reconstruído.

Inclua um comportamento alternativo para clientes antigos. Quando uma apresentação não for suportada, uma resposta textual clara pode ser preferível a bloquear toda a conversa. Registre também a relação entre versão do contrato e versão do cliente para facilitar diagnóstico.

Cuidados e limites

A reportagem aponta coordenação entre equipes, aprendizado dos dois componentes e diferenças entre plataformas como custos da abordagem.[10] Código compartilhado não garante comportamento idêntico.

Também não interprete renderização remota como autorização para o backend executar qualquer ação no dispositivo. Minha recomendação é manter uma lista explícita de capacidades, com validação local e confirmação quando houver efeito sensível.

O ganho depende de estabilidade do contrato e frequência real das mudanças. Se o produto tem poucas variações visuais, o custo de sustentar duas camadas pode superar a economia. A decisão deve começar pelo que precisa evoluir sem redistribuição, não pela vontade de transformar toda a interface em framework.

Fonte

[10] Fonte: InfoQ