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.
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 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).
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.
Extensões headless: uma extensão de carrinho embutida personalizada e uma extensão SaaS para pesquisa.
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

Quando pensamos em importar, a primeira coisa que vem em nossas mentes é taxa de importação. Porém a importação é algo que movimenta muito o país, justamente por causa dos impostos. Sim, existem muitos impostos na importação e isso é mais um detalhe que assusta os brasileiros.
Porém por mais que haja riscos de ser “taxado” e haja muitos impostos, a importação é algo que mantém muitas famílias no Brasil. Pois muitos brasileiros importam produtos, que não estejam disponíveis no nosso mercado para distribuir nacionalmente e com isso gerar muitas receitas.
O comércio internacional basicamente evolui em torno da doutrina de custo e vantagens comparativas. Os países tendem a produzir produtos que têm custo e vantagem de qualidade e os vendem para países que não possuem as referidas vantagens. Na realidade, porém, tem uma Dinâmica muito complicada.
O comércio internacional não envolve apenas troca de bens e serviços entre dois países, mas também envolve troca de moedas. Como o comprador e o vendedor são de dois países diferentes, há também um elemento de incerteza. Para o Importador (comprador) sobre a qualidade e quantidade de bens; e para o vendedor (Exportador) em relação ao pagamento.
Várias normas e regras internacionais são implementadas para reduzir essa tensão. UCPDC é o principal.
O ponto de partida de um comércio internacional é o inquérito gerado por um comprador a um potencial fornecedor. É seguido de troca de catálogo, especificações, amostras, em certos casos inspeção física de materiais e colocação de pedidos. Seguem-se os embarques e a liquidação de pagamentos.
As câmaras de comércio, os conselhos de promoção de exportação dos países desempenham um papel vital na facilitação do comércio. Os bancos desempenham um papel ainda maior no gerenciamento de documentos e no pagamento de pagamentos.