Server Driven UI — Parte II

No ultimo artigo (clique aqui para conferir), abordamos as motivações e a parte conceitual do uso do Server Driven UI.

Vantagens e Desvantagens

Entre os grandes benefícios oferecidos pela implementação do conceito de Server Driven UI, gostaria de destacar o “Time to Market”. Embora existam várias abordagens de engenharia de software voltadas para reduzir gargalos, é geralmente o time de frontend que acaba absorvendo esses atrasos. Em muitos casos, ocorrem atrasos em todas as fases da produção, mas é comum que o time de frontend precise acelerar sua entrega para minimizar os atrasos das outras equipes. Isso pode incluir a área de negócios, que pode ter atrasado na definição dos requisitos, a equipe de UX, que pode ter enfrentado atrasos na criação dos testes com os usuários, ou a equipe de backend, que talvez não tenha conseguido entregar a API a tempo, entre outros. Você já passou por uma situação semelhante? Compartilhe suas experiências nos comentários.

Com essa abordagem, costumo seguir a seguinte premissa: “Se já possuímos componentes existentes, o frontend está pronto; caso contrário, devemos priorizar a construção de novos componentes que possam ser reutilizados posteriormente.”

Normalmente, quando aplicamos esse cenário à área de negócios, que busca entregar e testar soluções rapidamente, a escolha é utilizar as ferramentas disponíveis no momento. Se a solução demonstrar seu valor, podemos revisá-la posteriormente para melhorar a experiência do cliente. Já vivenciei situações em que uma solução foi lançada em produção, mas acabou sendo descontinuada porque não gerou o valor esperado.

Além do “Time to Market”, podemos destacar outras vantagens, conforme descrito abaixo:

• Time to Market: Como mencionado anteriormente.
• Componentização: Garantimos que, uma vez que um componente esteja pronto, ele pode ser reutilizado em toda a jornada do seu aplicativo ou página.
• Design System: Como mencionado anteriormente, podemos utilizar o Server Driven UI como ferramenta para implementar e assegurar o Design System.
• Redução de Custos: Temos a oportunidade de reduzir os custos de implementação, pois o tempo de desenvolvimento é reduzido praticamente a zero, uma vez que o componente já existe.

No entanto, também existem desvantagens:

• Conhecimento: Por ser uma tecnologia considerada “recente”, poucos desenvolvedores estão familiarizados com essa abordagem, o que pode resultar em gargalos iniciais na construção da solução.
• Restrição de Liberdade: Devido à padronização dos componentes, podemos observar uma certa resistência por parte de alguns desenvolvedores em adotar essa solução, uma vez que ela limita a flexibilidade criativa.

Arquitetura

Pensando em uma solução escalável e disponível para N clientes, iniciei um processo de estudos sobre como poderia expandir e oferecer a solução como um serviço (SaaS).

Quando um usuário acessa a plataforma, o frontend faz uma chamada ao microserviço de telas, que é encarregado de retornar uma experiência previamente cadastrada. Dentro dessa experiência, são parametrizadas as APIs que o usuário irá utilizar na tela. A partir do frontend, são feitas chamadas aos microserviços do produto conforme a parametrização. O produto, por sua vez, abrange toda a lógica de negócios da aplicação.

Ao receber a experiência, o mecanismo de renderização realiza chamadas assíncronas aos produtos e renderiza a experiência planejada usando a estratégia de Client Side Rendering (você pode obter mais informações sobre essa abordagem neste link).

Para assegurar uma experiência reutilizável, existem padrões de experiência gratuitos disponíveis, como o Ant Design, Bootstrap e outros frameworks que proporcionam uma experiência satisfatória para os usuários.

No próximo artigo, vou citar mais alguns pontos sobre a Arquitetura utilizada versão final do aplicativo, e próximos passos da construção de uma solução Server Driven As a Service.