Esta é a segunda parte de um artigo composto por duas partes. Confira a primeira aqui.

Experiências unificadas com omnichannel headless

No caso do headless, as plataformas não processam HTML, nem processam formulários em HTML – a API JSON é tudo que a plataforma fornece e qualquer interface do usuário precisa usá-la. Não há alternativa. Essa abordagem, também conhecida como API-first ou API-only, reforça a necessidade de que cada recurso único esteja disponível por meio da API.

Em contraste, em plataformas híbridas, o uso da API é *opcional* e, portanto, acaba sendo considerado apenas um bom add-on para conectar sistemas ou interfaces de usuário adicionais à plataforma; como resultado, isso muito raramente expõe cada recurso que já está presente no site principal e, com o tempo, com a necessidade de adicionar novos recursos ao site, ele também se torna desatualizado.

O que uma experiência unificada significa exatamente?

Vamos considerar que uma empresa B2C oferece várias ações transacionais (T1, T2, …, Tn) possíveis para seus clientes por meio de vários canais diferentes, como fazer um pedido, devolver um item ou solicitar assistência por e-mail.

Cada ação transacional pode ser dividida em etapas atômicas, como adicionar um item ao carrinho, salvar algo na lista de desejos para mais tarde, selecionar um item a ser devolvido sem concluir o processo, selecionar um método de pagamento etc. A fim de completar qualquer ação T, todas as suas etapas S devem ser executadas em sequência.

Podemos dizer que existe uma experiência unificada e contínua quando o cliente é capaz de executar qualquer uma das ações transacionais disponíveis (T1, T2, …, Tn) completando seus passos atômicos (S1, S2, …, Sn) através de diferentes canais ( C1, C2, …, Cn).

Por exemplo, um cliente pode iniciar uma ação T1 (que tem 4 etapas) completando as etapas 1 e 2 pelo canal C1 (por exemplo, website) e concluir a ação completando as etapas 3 e 4 no canal C2 (por exemplo, aplicativo móvel). Aqui estão alguns exemplos:

• Um cliente adiciona dois itens por meio de um app mobile e, posteriormente, acessa o site via desktop, adiciona um terceiro item e, no dia seguinte, conclui a compra por meio de um aplicativo para dispositivos móveis.
• Um cliente inicia um processo de devolução via aplicativo móvel, leva o item a uma loja física e conclui o processo por meio do sistema de PDV.
• Um cliente adiciona um item à lista de desejos, vai a uma loja física, identifica-se através do sistema de PDV e consegue concluir facilmente a compra desse item salvo.

Headless em sistemas de PDV de lojas físicas

Em lojas físicas, o sistema de Ponto de Venda geralmente é conectado ao ERP no local e, se um cliente quiser usar, por exemplo, um código de cupom promocional (que foi recebido por e-mail depois de ter visitado o site) na loja, o ERP teria que conter exatamente as mesmas promoções configuradas que o site, o que pode ser alcançado por um processo manual de configuração de promoções na plataforma de e-commerce e no ERP, ou através de uma integração de sistemas entre ambos.

Além disso, se um cliente quiser comprar um produto que foi visto online, mas não está disponível na loja física, o catálogo de produtos no ERP deve estar em sincronia com o que está disponível no site. Essas integrações de sistemas podem ser complexas para serem desenvolvidas e difíceis de manter (diz-se que uma simples integração de sistemas é quase sempre um oxímoro).

Uma solução mais simples é ter o sistema de PDV conectado diretamente (como em tempo real/online) à plataforma de e-commerce, como uma interface de usuário thin client, para que todas as promoções e produtos vistos no PDV sejam os mesmos da plataforma de e-commerce.

Com uma plataforma de e-commerce headless e um PDV feito para se conectar a essa plataforma como um thin client via API, isso deve ser mais direto do que ter que desenvolver e monitorar uma integração de sistemas entre a plataforma de e-commerce e o ERP/PDV.

Headless em aplicativos móveis nativos

Headless em aplicativos móveis é direto porque é assim que os apps mobile funcionam por padrão. Em qualquer aplicativo nativo, o layout geral do app já está embutido no aplicativo, e apenas os dados (geralmente JSON) são trocados com o servidor.

Embora seja possível fazer com que os aplicativos renderizem HTML ou até mesmo tenham um navegador web integrado ao aplicativo (com Web Views), a capacidade de resposta geral resultante não é ideal e, na verdade, anula todo o seu propósito.

Dito isso, há vários aplicativos móveis que apenas carregam HTML do servidor por meio de visualizações da web (deixar webviews?), não apenas porque é muito mais rápido e fácil de implementar, mas porque a plataforma não é headless, e a abordagem de aplicativo móvel nativo baseada em API não é viável.

Headless em sites de marketplace

Headless em sites de marketplace é conceitualmente possível, mas praticamente inexistente. Isso poderia ser possível se o marketplace conseguisse se conectar à API de e-commerce do fornecedor em tempo real e, assim, replicar a experiência do fornecedor (promoções, pesquisa, opções de envio etc.).

No entanto, geralmente o marketplace fornece apenas uma API de sincronização para que o fornecedor possa sincronizar continuamente os produtos no marketplace e ler os pedidos feitos a partir dela. É compreensível, já que essa abordagem é muito mais escalável para o marketplace, e é de seu interesse proporcionar uma experiência unificada ao cliente final, e não uma experiência diferente para cada fornecedor listado.

Nesse caso, um marketplace não pode ser considerado como parte de uma arquitetura omnichannel verdadeiramente unificada, mas é, no entanto, um canal adicional muito estratégico para qualquer fornecedor.

Juntando tudo: uma arquitetura headless unificada

Headless traz a liberdade de ter várias heads (frontends), cada uma sendo feita sob medida para um público específico. Como todos os frontends usam a mesma camada de serviço da API, o resultado é uma experiência de usuário consistente e unificada em todos os canais.

Uma abordagem alternativa: plataformas distribuídas integradas no local para experiências offline

Uma desvantagem óbvia da abordagem headless é que todos os clientes da interface do usuário (ou frontends, thin clients etc.) devem ter acesso à Internet em todos os momentos. A comunicação com a API acontece em tempo real e, como o servidor reside na nuvem, uma conexão à Internet é sempre necessária.

Essa armadilha deve se tornar de menor importância com o tempo, à medida que a Internet se torna onipresente e todos os dispositivos estão sempre conectados. Mas e se quisermos alcançar os clientes onde a Internet não está prontamente disponível ou não é muito confiável?

Uma solução possível é ter o frontend em execução no dispositivo do cliente para ser um pouco mais do que apenas uma interface do usuário – ele teria todas as funcionalidades mínimas necessárias para fechar um pedido. Essa plataforma frontend deve ter um armazenamento de dados para poder armazenar todos os produtos, promoções etc., permitindo que a pessoa a utilize para fazer pedidos offline.

Os pedidos seriam então sincronizados com a plataforma em nuvem (junto com os preços dos produtos, estoque etc.) assim que uma conexão com a Internet fosse disponibilizada. Se o processamento do pagamento no local for necessário, ele poderá ser resolvido através de transações via dinheiro ou através de uma rede móvel conectada ao pinpad.

Obtemos a capacidade de colocar pedidos offline ao custo de ter dados eventualmente consistentes, o que significa que não há garantia de que o pedido poderá ser atendido (já que não teremos necessariamente as informações de estoque mais atualizadas no fechamento do pedido).

Estendendo a funcionalidade do comércio headless: recursos personalizados e SaaS

Headless realmente brilha quando se trata de estender a funcionalidade, porque qualquer novo recurso só precisa ser desenvolvido uma vez na plataforma principal (e, claro, exposto via API) para se tornar instantaneamente disponível para todos os frontends usarem.

Em contraste, a abordagem tradicional full-stack requer que o novo recurso seja desenvolvido em cada plataforma diferente. Com o headless, a UI precisa ser desenvolvida, o que pode não ser uma tarefa trivial, mas ainda é muito menos complexa do que ter que desenvolver todo o recurso do zero em todas as plataformas full-stack.

Estender a camada de serviço da plataforma (APIs disponíveis para frontends) pode ser feito através de uma abordagem mais monolítica (estendendo o comportamento atual dos serviços) ou girando mais serviços separados e independentes que fornecem pequenos serviços muito específicos e compostos, também conhecidos como microsserviços.

Antes de seguir qualquer rota, certifique-se de conhecer os prós e contras de cada um – para ler depois: não é possível não recomendar os excelentes materiais de Martin Fowler sobre os tópicos.

Além disso, ao estender sistemas, seja através de extensões monolíticas orientadas a objeto, microsserviços dependentes de rede ou soluções SaaS de terceiros, é sempre uma boa ideia manter as coisas o mais simples possível (se houver muitas maneiras de resolver um problema, use a abordagem mais simples primeiro e adicione complexidade depois, somente se for realmente necessário), e continuamente refatorar, revisar e simplificar as extensões e integrações de sistemas (empregando um Enterprise Service Bus, por exemplo), para não se ver em extensões e integrações infernais depois de um tempo.

Outra maneira de estender uma plataforma headless é por meio de soluções SaaS de terceiros. Para que isso funcione corretamente com o headless, o SaaS precisa ter uma API de frontend (preferencialmente, API-only) e, na maioria dos casos, também uma API de backend para sincronizar dados entre sistemas.

Os frontends, nesse caso, precisam ser ajustados para se conectarem a essas APIs de terceiros, além da API da plataforma padrão. Essa extensibilidade é muito útil em casos em que a funcionalidade recém-fornecida pelo SaaS é muito independente de qualquer outra funcionalidade na API principal (senão, caso as funcionalidades sejam dependentes umas das outras, é mais difícil para os aplicativos frontend orquestrarem corretamente chamadas de API e usarem o recurso corretamente), e adotar essa abordagem pode economizar muito esforço e tempo.

Comércio headless na AMARO

Na AMARO, temos três aplicativos voltados para o cliente: um aplicativo para iOS escrito em Swift, um aplicativo para Android escrito em Java e um aplicativo web escrito em JavaScript/React. Todos estão conectados a plataformas headless, conforme ilustrado abaixo.

 

***

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/part-2-delivering-a-unified-omnichannel-experience-using-headless-commerce-a5774bd7ae5f