Aplicativos headless, full-stack e SPAs

TLDR: resumo, principais sugestões e dicas

• O JavaScript permitiu o desenvolvimento de aplicativos de interface do usuário com recursos completos que são executados inteiramente em um navegador web, chamados single page apps.
• Os SPAs (Single Page Apps) precisam se comunicar via Ajax com um servidor web que executa um aplicativo de backend.
• Um aplicativo de servidor que expõe todos os seus recursos via API somente pode ser chamado de headless, e qualquer interface de usuário pode estar conectada a ele (talvez uma nomenclatura melhor seria multihead?)
• Muitas plataformas de e-commerce ainda usam uma abordagem full-stack ou uma híbrida.
• Existem prós e contras em usar full-stack ou headless – certifique-se de saber quais são.
• Se for uma rota multicanal, considere usar uma abordagem headless API-first.
• Headless é uma solução possível para o problema de inconsistência de experiência multicanal.
• A migração de um ou de um conjunto de plataformas full-stack para o headless é um grande esforço e requer investimentos de replanejamento consideráveis e o talento certo.
• Headless é uma ótima opção para as primeiras marcas DTC online que buscam proporcionar uma experiência de usuário unificada em vários canais.
• Ao avaliar as soluções SaaS para estender a funcionalidade da plataforma headless, verifique se o SaaS também é headless (ou pelo menos tem uma API muito abrangente).

Single page apps e a abordagem headless

Em 1991, ainda em suas origens, a web foi projetada para oferecer documentos completos em cada resposta do servidor. Após o clique de um link, o servidor retornaria um documento inteiro (em formato HTML), com todas as informações necessárias para o navegador web renderizar essa página.

Cada interação com a página web renderia uma página web totalmente nova, mesmo se o novo documento tivesse muito poucas alterações em comparação com a página anterior.

Em sua forma mais simples e tradicional, navegar na web é simplesmente solicitar o documento do servidor e permitir que o navegador o processe. No contexto do e-commerce, por exemplo, se gostaríamos de acessar o produto “123”, uma simples solicitação para “/product/123” poderia retornar um documento HTML contendo todas as informações sobre aquele produto junto com todo o layout de informações necessárias para o navegador exibi-lo bem.

Com o tempo, os navegadores web foram equipados com JavaScript e seu conjunto de tecnologias relacionadas (que ficou conhecido como Ajax ou Asynchronous JavaScript e XML), permitindo que a lógica de negócios (ou uma UI mais sofisticada renderizando lógica e eventos) fosse executada no navegador, e que dados parciais (XML ou JSON) fossem transferidos entre o navegador e o servidor.

Uma aplicação imediata disso foi permitir mudanças parciais de layout da página web (obtendo apenas o delta do servidor) sem ter que renderizar um novo documento inteiro novamente. Esse conjunto de tecnologias abriu o caminho para os modernos SPAs (Aplicativos de Página Única) atuais, que são aplicativos completos em execução no navegador e que se comunicam com o servidor *apenas*via Ajax (essencialmente eliminando o conceito original de hiperlinks).

Com os SPAs, o servidor não precisa mais retornar documentos HTML. Todo o layout e sua lógica residem no aplicativo JavaScript, e apenas os dados JSON são trocados com o servidor – indo com o Ajax completo. Como resultado, o aplicativo em execução no servidor não precisa mais se preocupar com a interface do usuário – que agora é totalmente gerenciada pelo SPA.

Isso está de acordo com o conceito de SoC (Separation of Concerns), no qual o frontend do SPA é responsável pela interface do usuário e pela comunicação com o servidor, e o servidor é responsável apenas pelos dados de computação que recebe.

A interface (entre o SPA e o aplicativo do servidor) pela qual essa comunicação ocorre é conhecida como API Web, e o formato de troca de dados é mais comumente JSON (JavaScript Object Notation), mas qualquer outro formato de dados pode ser usado.

Headless vs. full-stack

No contexto do e-commerce, a interface do usuário pode ser considerada a “cabeça” (head) da plataforma, porque é a parte tangível com a qual o cliente interage. Em muitas plataformas de e-commerce, o head ainda está fortemente ligado a toda a plataforma e não pode ser facilmente removido (grande parte da UI é renderizada pela plataforma rodando no servidor, produzindo um documento HTML completo como saída).

Na verdade, essas plataformas geralmente empregam uma abordagem híbrida, na qual muitas páginas são servidas pela maneira tradicional de fazer o servidor criar o documento HTML completo, e um aplicativo JavaScript em execução no navegador é responsável por fazer solicitações Ajax ao servidor e, assim, realizar alterações parciais nos documentos originais.

As plataformas de comércio eletrônico que fazem uso da lógica da interface do usuário do lado do servidor (integral ou híbrida) podem ser chamadas de “full-stack”, enquanto as plataformas de e-commerce que passaram pela rota SPA completa podem ser chamadas de “headless”.

Cada abordagem tem seus prós e contras. Vamos dar uma olhada em alguns.

Prós do full-stack

• Mais fácil de lidar com bots de SEO e web scraping em tempo real (Facebook, WhatsApp etc.)
• Não há necessidade de criar um aplicativo frontend a partir do zero, pois geralmente já vem junto com a plataforma de e-commerce.
• Requer menos desenvolvedores (somente um aplicativo precisa ser mantido, na verdade).
• Indiscutivelmente menos complexo, já que uma integração entre dois aplicativos não é necessária.

Contras do full-stack

• Menos controle sobre alterações de UI/UX
• Mais difícil de manter, já que a Separation of Concerns entre a interface do usuário e as regras de negócios não está clara.
• Pouca capacidade de resposta da IU (dica: isso pode ser melhorado usando Turbolinks)

Prós do headless

• Capacidade de ter várias interfaces de usuário para o mesmo aplicativo (um site, um aplicativo móvel nativo etc.).
• O Clear SoC facilita a manutenção e a evolução de uma equipe de frontend dedicada.
• Capacidade de resposta da interface do usuário muito melhor.
• Permite uma experiência omnichannel mais unificada e consistente.

Contras do headless

• Mais difícil de lidar com bots de SEO e web scraping em tempo real (Facebook, WhatsApp etc.).
• Geralmente requer mais desenvolvedores para manter dois aplicativos separados.
• Indiscutivelmente mais complexo, já que dois aplicativos separados são integrados via http.

Uma analogia comum é comparar a abordagem full-stack aos agora extintos combos TV + videocassete – embora haja um valor óbvio em ter os dois integrados em um único produto (por exemplo, não há necessidade de se preocupar em conectar dois dispositivos separados via cabos ), era muito improvável que um desses combos oferecesse a melhor TV e o melhor videocassete em um único produto, já que os avanços na tecnologia de TV e videocassete aconteciam em ritmos diferentes, sem mencionar que em pouco tempo os videocassetes seriam substituídos por um tecnologia inteiramente nova.

Com o combo, certamente se obteria um produto all-in-one fácil de usar, mas ao custo de não ter a tecnologia mais avançada em cada componente individual. O headless pode ser mais complicado de configurar, mas suas partes podem evoluir em ritmos distintos e até serem totalmente substituídas, se necessário.

Omnichannel, mas com experiências inconsistentes

Para qualquer empresa B2C, é natural que, com o tempo, ela amplie seus canais para onde for possível, de modo a alcançar um número maior de clientes em potencial. Com o advento dos smartphones, o m-commerce como um canal adicional nasceu rapidamente.

Seja por meio de aplicativos móveis nativos ou por meio de um navegador web mobile, as empresas precisavam adaptar suas plataformas de e-commerce para oferecer essa opção adicional aos clientes. Antes que os layouts de resposta fossem algo importante e a largura de banda móvel estivesse acima da largura de banda de desktop, uma tentativa inicial de muitas empresas foi simplesmente implementar outra plataforma, em um subdomínio m (como em m.company.com), para exibir páginas web móveis, que eram versões reduzidas das originais do desktop.

Desenecessário dizer que isso criou mais problemas do que soluções; empresas que já tinham muito trabalho gerenciando a plataforma desktop (fazendo o upload de produtos, imagens e banners, configurando promoções e cupons etc.), agora também tinham que gerenciar uma plataforma móvel completamente diferente, o que resultou em muito trabalho redundante.

Essa abordagem não só não foi sustentável devido ao trabalho duplo envolvido, mas também forneceu experiências muito distintas entre os dois canais. Com o tempo, as técnicas de layout responsivo chegaram para ajeitar as coisas, permitindo que um único documento HTML fosse exibido tanto para dispositivos móveis quanto para computadores, e que os navegadores o ajustassem ao tamanho da tela de acordo com as regras programadas (CSS). Isso levou à centralização de plataformas e à extinção do infame subdomínio m ou m-site.

A principal vantagem que obtemos disso é que a implementação de novas plataformas para qualquer canal adicional inevitavelmente leva a experiências de usuário inconsistentes, além de uma carga de trabalho insustentável para a empresa.

Com a recente expansão de muitas empresas B2C para o offline (lojas físicas), o aumento de aplicativos móveis nativos (iOS e Android) e a ascensão dos mercados online, isso novamente criou um problema semelhante de sobrecarga de canais, com os seguintes novos sistemas sendo exigidos:

Lojas físicas:

Um sistema PDV de loja física, atendendo a todos os requisitos fiscais do PDV e fornecendo a mesma experiência do cliente que o canal online, além de regras comerciais específicas para a experiência do cliente na loja.

Apps móveis nativos:

Uma plataforma de e-commerce que fornece *todos* os recursos existentes via API, porque os aplicativos móveis nativos são headless por natureza (o layout dos aplicativos nativos não é descrito em HTML, daí a necessidade de se comunicar com servidores via API JSON).

Marketplaces online:

Uma plataforma de e-commerce que fornece todos os recursos existentes via API, para que os marketplaces de terceiros possam usá-los para promoções, leitura de preços e estoque de produtos, e envio de pedidos (na verdade, devido à falta de padronização da API de e-commerce, o oposto prevaleceu, e os marketplaces são os que fornecem tais APIs).

Não é incomum que as empresas tenham sistemas de PDV em uma plataforma completamente diferente para suas lojas físicas (geralmente é uma interface de usuário para o sistema ERP), e também não é incomum que os aplicativos móveis nativos fiquem em cima de uma API que fornece apenas um *subconjunto* de todos os recursos disponíveis no site.

Essa abordagem permite um mundo multicanal, mas também cria o problema de inconsistência de experiência e carga de trabalho redundante. Mas podemos fazer melhor? Seria possível unificar isso o máximo possível (como aconteceu com o m-site)? É aqui que o headless pode entrar em jogo.

***

Artigo escrito por Roberto Thiele e traduzido pela redação iMasters com a permissão da equipe AMARO. O original está em: https://medium.com/amaro-tech/delivering-a-unified-omnichannel-experience-using-headless-commerce-51c62bebe9c7