A UI orientada a servidor está retornando ao anel Trial, pois vemos mais times encurtando com sucesso o caminho para produção. Ao separar a renderização em um contêiner genérico enquanto fornece estrutura e dados por meio do servidor, os times de mobile podem contornar os longos ciclos de revisão das lojas de aplicativos para cada iteração. Vimos que isso melhora significativamente o time to market, com formatos baseados em JSON permitindo atualizações em tempo real. Embora tenhamos alertado anteriormente contra as "bagunças horrendas e excessivamente configuráveis" que frameworks proprietários podem criar, o surgimento de padrões mais estáveis de empresas como Airbnb e Lyft tem ajudado a reduzir a complexidade. Nossa experiência mostra que o investimento substancial exigido para um framework proprietário agora é mais fácil de justificar para aplicações de grande escala. No entanto, isso ainda exige um forte caso de negócios e engenharia disciplinada para evitar a criação de um "protocolo deus" que se torna difícil de manter. Para times que buscam reduzir a complexidade no lado do cliente, essa abordagem fornece uma maneira poderosa de escalar entre os times e sincronizar a lógica em múltiplas plataformas. Recomendamos aplicá-la a áreas altamente dinâmicas de uma aplicação, em vez de usá-la como um substituto geral para todo o desenvolvimento de UI.
A interface de usuário orientada a servidor continua a ser um assunto polêmico nos círculos de discussão sobre dispositivos móveis, porque oferece às pessoas desenvolvedoras o potencial de aproveitar os ciclos de mudança mais rápidos sem entrar em conflito com as políticas das lojas de aplicativos sobre a revalidação do próprio aplicativo para dispositivos móveis. A interface de usuário orientada ao servidor separa a renderização em um contêiner genérico no aplicativo móvel, enquanto a estrutura e os dados de cada visualização são fornecidos pelo servidor. Isso significa que as alterações que antes exigiam um percurso de ida e volta a uma loja de aplicativos agora podem ser realizadas por meio de alterações simples nas respostas que o servidor envia. Embora alguns times de aplicativos móveis muito grandes tenham obtido bastante sucesso com essa técnica, isso também exige um investimento substancial na construção e manutenção de um framework proprietário complexo. Tal investimento requer um caso de negócio convincente. Até que haja bons argumentos, talvez seja melhor proceder com cautela. Na verdade, nós tivemos algumas experiências com bagunças terríveis e excessivamente configuráveis que não entregaram os benefícios prometidos. Mas com o apoio de gigantes como Airbnb e Lyft, podemos verdadeiramente ver surgir alguns frameworks úteis capazes de ajudar a domar a complexidade. Fique de olho nesse espaço.
Quando criamos uma nova edição do Radar, muitas vezes experimentamos uma sensação de déjà vu. A técnica de UI orientada a servidor é um caso particularmente sólido, com o advento de frameworks que permitem que pessoas desenvolvedoras mobile se beneficiem de ciclos de mudança mais rápidos, sem infringir nenhuma das políticas da loja de aplicativos em relação à revalidação do aplicativo móvel em si. Já abordamos isso anteriormente sob a perspectiva de permitir que o desenvolvimento para dispositivos móveis seja escalado entre os times. A interface de usuário orientada a servidor separa a renderização em um contêiner genérico no aplicativo móvel, enquanto a estrutura e os dados de cada visualização são fornecidos pelo servidor. Isso significa que as alterações que antes exigiam uma viagem de ida e volta à loja de aplicativos agora podem ser realizadas por meio de alterações simples nas respostas que o servidor envia. Observe que não estamos recomendando essa abordagem para todo o desenvolvimento de UI. Na verdade, tivemos experiências com algumas bagunças terríveis e excessivamente configuráveis, mas, com o apoio de gigantes como AirBnB e Lyft, suspeitamos que não sejamos apenas nós da Thoughtworks que nos cansamos de tudo sendo feito do lado do cliente. Fique de olho nesse espaço.
