Server Driven UI — Parte I
Nos últimos cinco anos, iniciei alguns estudos de uma abordagem alternativa na construção de interfaces de usuário (frontend). Esse insight surgiu após enfrentar desafios significativos. No mundo da tecnologia, sempre nos deparamos com um grande desafio: conciliar as necessidades das áreas de negócio com as capacidades da engenharia. Em muitas empresas, é uma tarefa árdua encontrar sinergia entre essas duas áreas. Em certos momentos, o setor de negócios está ansioso por avanços, mas a equipe de engenharia não consegue entregar o fluxo necessário para atender às demandas a tempo. Em outros casos, a engenharia pode oferecer o suficiente, mas o setor de negócios não se desenvolve rapidamente o suficiente para gerar demandas para a equipe de tecnologia. Como solução sugerida, costumo dizer que “a comunicação é o recurso mais valioso deste século”.
Além disso, uma das maiores frustrações que enfrentei como líder na área de Mobile foi o tempo de aprovação nas lojas de aplicativos. Por exemplo, a Apple Store levava até três dias úteis para aprovar uma versão para liberação. Refletindo sobre isso, comecei a explorar possibilidades de criar uma plataforma genérica no frontend. Naquela época, eu não estava familiarizado com o termo técnico “Server Driven UI”, o qual foi apresentado por um desenvolvedor iOS que admiro muito, especialmente por sua habilidade analítica.
Conceito
Um dos principais desafios ao expandir equipes de TI é assegurar que o conhecimento necessário seja mantido e que a experiência do usuário permaneça coesa, a fim de evitar experiências fragmentadas. Você já se deparou com a situação de visitar um site e perceber que a experiência do usuário muda drasticamente durante a sua navegação? Deixe nos comentários quais sites você conhece com esse tipo de situação?
Em resposta a esse desafio, várias empresas começaram a adotar o Design System como uma maneira de padronizar a experiência do usuário.
Na literatura, temos:
Geralmente, a estrutura de equipes horizontais pode inadvertidamente resultar em soluções fragmentadas e inconsistentes, o que é frequentemente referido como “Franksteins”. O conceito de Server Driven UI surge como uma abordagem para incorporar o Design System em uma organização, acelerando o processo de desenvolvimento. Uma das primeiras divulgações desse conceito foi feita pela empresa Airbnb (mais informações).
Em resumo, esse conceito se concentra na subdivisão do Frontend em componentes menores, como ilustrado na imagem abaixo:
Esses microcomponentes podem ser reutilizados em qualquer parte da tela, garantindo a reutilização de código. Em resumo, isso implica em uma implementação de um mecanismo de renderização no Frontend, o que significa que, com base nas informações recebidas do Backend, determina-se qual componente deve ser apresentado ao usuário. Minha primeira implementação desse conceito foi realizada em um aplicativo Android (o qual removi da loja para fins de refatoração).
Vou usar esse aplicativo como exemplo para aprofundar o tópico. Durante o desenvolvimento do aplicativo, criei diversos tipos de elementos de interface, cada um proporcionando uma experiência distinta ao usuário, como ilustrado na imagem abaixo:
Cada Linha possui um identificador que define qual experiência será renderizada.
Para a API, foi necessário incluir um campo (__type) que define qual experiência o motor frontend irá renderizar.
Dessa maneira, podemos construir uma tela “dinâmica” com base nas respostas do backend. Ao conectarmos uma API de Produtos a esse frontend, possibilitamos o reuso em tempo real da experiência do usuário. Em outras palavras, é apenas necessário configurar o backend de acordo com o contrato de cada componente, e o frontend estará pronto para uso. Em resumo, o frontend oferece uma ampla variedade de componentes que podem ser reutilizados várias vezes em uma tela; o que varia é o conteúdo desses componentes, adaptando-se às necessidades do negócio.
Benchmarks
Antes de iniciar a implementação, realizei uma pesquisa para entender como algumas empresas aplicavam esse conceito. Após várias investigações, identifiquei empresas como Meta, LinkedIn, Instagram e Airbnb como referências nesse campo. Além disso, encontrei implementações disponíveis para testes, como o Beagle e o JudoApp.
Cada aplicação tem seu próprio modelo de uso e formato de implementação, adaptados às suas necessidades específicas. Na minha perspectiva, sempre dou prioridade ao princípio do “simples bem feito”. Portanto, durante a implementação, concentrei-me principalmente no parâmetro “__type” para evitar sobrecarregar a transferência de dados para o frontend, especialmente em um ambiente móvel. No contexto brasileiro, a economia de dados é valorizada, pois ninguém deseja um aplicativo que consuma excessivamente o pacote de dados sem necessidade.
No próximo artigo, vou citar mais alguns pontos sobre vantagens e desvantagens, arquitetura utilizada na versão final do aplicativo, e próximos passos da construção de uma solução Server Driven As a Service.
Se você chegou até aqui, agradeço pelo tempo dispensado nessa leitura, deixe seu feedback e me siga para mais dicas.
