Nesta secção, irão ser abordadas as vantagens associadas ao conceito Headless aplicado a um CMS comparativamente ao seu módulo tradicional.
3.5.2.1. Flexibilidade e escalabilidade
Ao facto de falarmos de uma arquitetura que envolve o desacoplamento total de duas componentes que envolvem um CMS, estas podem trabalhar quase independentemente uma da outra. Cada uma destas pode ser modificada sem interferir com a outro, trazendo flexibilidade e escalabilidade ao ecossistema [25].
3.5.2.2. Redução de custos operacionais e tecnológicos
A arquitetura tradicional de um CMS indica que o backend e o frontend trabalham em conjunto como uma plataforma só. A relação associada a este tipo de metodologia trata- se de um para um, o que por outras palavras se pode traduzir que para cada CMS existe uma relação de um (backend) – um (frontend). Através do desacoplamento destes dois
componentes conseguimos fazer com que o nosso website consiga sofrer alterações numa destas componentes de maneira independente e com mais facilidade.
Para além da vantagem referida previamente, existe a redução de custos operacionais através da utilização do sistema de manuseamento de conteúdo, pelo que muitas das vezes deixa de ser necessária uma equipa especializada para tratar do conteúdo apresentado no
website [26].
3.5.2.3. Estrutura bem definida
O consumo de uma API é uma realidade completamente diferente para o frontend relativamente ao método tradicional, em que a própria estrutura HTML (HyperText Markup
Language) é enviada na própria resposta do servidor ou pedido a uma determinada página web.
Ao consumirmos uma API através do frontend, temos uma variedade maior de possibilidades a nível de estrutura e design da própria página web. Sabendo que o nosso pedido à API irá devolver uma determinada resposta (geralmente documentada) podemos rapidamente moldar-nos a esta resposta e apresentar facilmente o conteúdo pretendido [26].
3.5.3. Desvantagens
Nesta secção, irão ser abordadas as desvantagens associadas ao conceito headless comparativamente à metodologia tradicional de um CMS.
3.5.3.1. Ponto de falha comum
É relativamente fácil entender o principal problema e desvantagem associado à aplicação do conceito Headless ao nosso caso exemplo, representado pela Ilustração 13. Como os CMS deixaram de ter o seu backend dedicado e passaram a consumir uma API externa para tratamento de dados, estes passam a depender diretamente desse endpoint. Em caso de falha por parte da API, o website poderá ficar estagnado por completo, pois todo o processamento de lógica necessária não é efetuado.
Ilustração 13 - Exemplo em caso de falha da API
3.5.3.2. Bugs e falhas de segurança
O consumo de lógica entre várias aplicações ao mesmo endpoint poderá ser bastante problemático. No caso de haver bugs ou falhas de segurança do endpoint, todos os consumidores irão partilhar este tipo de situações não desejadas.
Imaginando que o serviço que é consumido contém uma falha de segurança que abre a porta a ataques através de SQL (Structured Query Language) injection, existe uma grande probabilidade dos endpoints que consumam este serviço estejam suscetíveis a sofrer ataques deste tipo.
Estado da arte
A experiência profissional obtida através da utilização de várias plataformas e/ou ferramentas associadas ao e-commerce permite-me afirmar que é praticamente impossível generalizar uma solução que englobe todas as necessidades (uma aplicação all-in-one) de uma loja. A diferenciação das especificações e pormenores associados à lógica de negócio de cada loja é por vezes, demasiado grande e especifica. Este tipo de pormenores envolve os vários processos internos efetuados por parte da aplicação, como por exemplo: criação de encomendas; envio de e-mails associados a campanhas promocionais; entre outros.
Este capítulo tem como principal objetivo a pesquisa e investigação de aplicações ou plataformas já existentes relativas ao tema de “Headless REST API associado a e-
commerce”. Será efetuada uma descrição de cada uma destas, de modo a tentar extrair as
suas possíveis vantagens e desvantagens. De modo a fazer parte desta lista, as soluções têm que ser complacentes com as seguintes características:
• Fornecem uma API com a possibilidade de trabalhar completamente desacoplada de um frontend (headless);
• Utilizam REST como modelo arquitetural; • Têm aplicabilidade ao comércio digital.
Foram escolhidas três situações de aplicações distintas, com algumas características interessantes associadas à sua maneira de utilização. É possível verificar que as soluções são apresentadas em dois tipos de opções:
• “Como serviço” – Toda a arquitetura e funcionalidade é “servida” através de uma entidade externa onde o cliente final é responsável pelo consumo destas funcionalidades. A entidade responsável por consumir o serviço não tem acesso ao código fonte e é “obrigada” a consumir o serviço tal como este é disponibilizado, sem possibilidade de efetuar alterações ao seu core;
• “Como plataforma” - Toda a arquitetura e funcionalidade é disponibilizada através do código fonte do projeto. A entidade que obtém este código fonte pode efetuar as alterações necessárias ao core da solução de modo a adaptá-la às suas necessidades. Existem alguns fatores que foram decididos como muito importantes na consideração das soluções descritas nos próximos tópicos. Estes fatores são:
• Documentação – Qualquer API depende de documentação concisa e bem escrita, de modo a que os programadores consigam integrar ou ajustar facilmente as funcionalidades à logica de negócio;
• Exemplos (oficiais) de código a utilizar a API – Os exemplos com integrações já efetuadas por parte da entidade associada à solução, são importantes para os programadores utilizarem-nos como ponto de referência ou até mesmo ponto de partida.
4.1. GetCandy
Solução de código aberto (Licença Apache-2.0) muito completa, construída através da utilização da framework Laravel (desenvolvido em PHP), com o objetivo de criar lojas
online, fornecendo um sistema de administração que permite controlo total sobre as
funcionalidades de cada uma das suas lojas [27]. Disponibiliza uma documentação bastante extensa com os passos necessários de instalação e de referências à utilização da API.
Em caso de necessidade, esta disponibiliza também de uma parte visual para associar à administração dos vários componentes, através da introdução de novos ficheiros disponíveis num dos repositórios criados pela mesma equipa, denominado de “Candy Hub” [28].
Sendo esta solução open-source, esta acaba por partilhar vantagens e desvantagens associadas às mesmas de um repositório com estas características:
• Vantagens:
o Solução grátis e utilizável em ambiente comercial;
o Fornece a possibilidade de implementação de novas funcionalidades, permitindo a adaptação aos requisitos necessários do utilizador da solução. • Desvantagens:
o Não sendo um serviço pago, não existe suporte dedicado ao cliente (como geralmente acontece com serviços pagos);
4.2. CommerceLayer
Solução que fornece uma API responsável por tratar de toda a lógica associada ao comércio digital de uma maneira mais “simplificada”. Esta simplificação ocorre devido ao facto de toda a lógica se encontrar previamente desenvolvida, sendo disponibilizada como “serviço”. A entidade que pretende utilizar esta solução necessita apenas de consumir este serviço de modo a integrá-lo no seu sistema.
A aplicação em si disponibiliza uma secção de manuseamento de conteúdo fornecido pela API onde poderemos adicionar categorias, compras efetuadas, métodos de pagamento, manutenção de stock, entre outros no seu próprio website. Todo este conteúdo é associado a uma loja, de modo a ser consumida posteriormente. Existe também a possibilidade de integração de aplicações “fora da caixa” ao próprio website, de modo a poder utilizar várias funcionalidades da mesma (exemplo - funcionalidades do “Twitter” ou “Dropbox”). Através da integração destas aplicações, podemos depois automatizar determinados processos, como exemplo, caso adicionássemos um serviço de e-mail, poderíamos configurar para que fosse enviado um e-mail sempre que exista uma nova compra efetuada [29].
• Vantagens:
o Oferece um plano flexivel para comerciantes de qualquer dimensão. Os preços de utilização do serviço começam nos 50€ mensais e escala dependendo de vários fatores como o número de encomendas, de produtos, entre outros;
o O serviço fornece uma API que poderá ser rapidamente integrada num cenário de uma loja online.
• Desvantagens:
o A flexibilidade de implementação de novas funcionalidades torna-se um pouco restrita, devido à solução ser disponibilizada como serviço. Não existe contacto direto com o código associado a esta;
o Muita da informação é guardada do lado do CommerceLayer, o que poderá trazer problemas a nível de segurança e regulação dos dados associados aos clientes.
4.3. Moltin
Solução poderosa semelhante ao “CommerceLayer”. Oferece um nível de customização maior [30], pois existe a possibilidade de adicionar novas propriedades a determinados componentes associados à plataforma [31] (como por exemplo os produtos), onde é possível definir o nome e o tipo de dados associado à propriedade (como por exemplo Boolean), que posteriormente poderá ser utilizado programaticamente, pois este passa a ser devolvido pela API.
Oferece planos a partir dos 1995$ por mês, um valor muito superior ao disponibilizado pelo “CommerceLayer”. É possível contactar os serviços internos para obter um preço associado aos requisitos da plataforma, no entanto, o nível de customização dos requisitos pretendidos não consegue ser efetuado no momento, como disponibilizado no “CommerceLayer”.
• Vantagens:
o Oferece um nível superior de customização associado aos vários endpoints; o O website oferece múltiplos exemplos (em várias linguagens) para se
começar um projeto. • Desvantagens:
o O preço alto associado ao plano inicial poderá obliterar a possibilidade de uma empresa mais pequena usar o serviço.
4.4. Comparação de soluções
Através das várias soluções encontradas, conseguimos extrair as várias caracteristicas associadas a cada uma das plataformas analisadas. nomeadamente:
• Licença – Licença associada ao código. Aplicável a soluções que disponibilizem código fonte;
• Preço – Preço aplicável para o uso da plataforma;
• Integrações out-of-the-box – Possibilidade de ativar integrações previamente feitas;
• Disponibilização do código fonte – O cliente final recebe o código fonte associado à solução;
• Suporte ao cliente – A entidade responsável pela solução presta suporte dedicado à entidade que se encontra a usar os seus serviços;
• Exemplos oficiais com a API – A entidade responsável pela plataforma fornece exemplos, a nível de programação, de aplicações que consomem o serviço; • Documentação da API – A entidade responsável pela plataforma fornece uma
documentação oficial sobre os vários endpoints da API;
• Disponibiliza biblioteca de endpoints – Existe uma biblioteca de endpoints que poderá ser importada em aplicações que permitem efetuar pedidos (Exemplo: Postman);
• Disponibiliza interface para gestão – A entidade responsável disponibiliza uma interface de gestão dos vários componentes (produtos, categorias, promoções, entre outros) da plataforma (o consumo da API não dependerá desta componente).
Tabela 1 - Comparação de vários componentes associados às soluções encontradas Solução
Componente
GetCandy CommerceLayer Moltin
Licença Apache-2.0 – –
Preço Grátis A partir de 50€ /
mês
A partir de 1995$ / mês
Integrações out-of-the-box? Não Sim Sim
Disponibilização do código fonte Sim Não Não
Suporte ao cliente Não Sim (*) Sim (**)
Exemplos oficiais com a API Não Sim Sim
Documentação da API Sim Sim Sim
Disponibiliza interface de gestão Sim (***) Sim Sim (*) apenas para planos “Enterprise”
(**) considerado feature adicional
Metodologia
A gestão e planeamento de um projeto são dois aspetos que permitem uma melhor organização de uma equipa relativamente ao plano de desenvolvimento. Neste capitulo irá ser feito uma descrição associada ao Scrum, framework de trabalho utilizada durante o desenvolvimento deste trabalho. Será também descrito o software utilizado para gestão de todas as tarefas que foram utilizadas como guideline.
5.1. Processo de desenvolvimento
A entidade responsável pelo projeto não especificou uma metodologia concreta para o desenvolvimento do deste, pelo que decidi utilizar a heurística e valores associados à
framework Scrum. Esta decisão foi tomada como a mais adequada devido à minha
experiência profissional e devido à Blue-Infinity utilizar este tipo de forma de desenvolvimento em alguns dos seus projetos.
O Scrum implementa metodologias de trabalho de maneira a resolver problemas complexos através da construção do produto final de maneira iterativa e incremental [32]. Isto indica que o resultado é obtido através de várias entregas do produto, que permitem obter uma visão mais objetiva do que é pretendido pelo cliente final. É comum um projeto ser entregue ao cliente quando completo, no entanto, poderão existir especificações mal interpretadas por qualquer uma das partes (cliente e entidade responsável pelo desenvolvimento), que acabam por necessitar de novas modificações. Tendo em conta que o Scrum permite entregas incrementais, as modificações ao projeto ou alterações das especificações podem ocorrer de uma de uma maneira continua, com o objetivo de responder à “visão do cliente”.
Os principais eventos associados a esta framework são [32]:
• Sprint - Intervalo de tempo associado à entrega de incrementos do produto. Com uma duração geralmente de 2 a 4 semanas. Este trabalho contou com sprints de 4 semanas;
• Reuniões (Scrums) diárias - Reuniões diárias de uma duração máxima de quinze minutos utilizada para sincronizar as atividades efetuadas e criar o plano de desenvolvimento das 24 horas seguintes. Estas reuniões devem ocorrer no mesmo local e à mesma hora de modo a facilitar este processo;
• Planeamento de sprints – Planeamento do trabalho a ser efetuado no sprint seguinte através da escolha de tarefas do backlog e do trabalho que poderá ser entregue na próxima iteração associada ao sprint [33];
• Sprint review – Evento que ocorre a cada fim de sprint de modo a verificar o incremento efetuado com o objetivo de adaptar o backlog se necessário [34].
O Scrum implementa várias funções entre os vários membros da equipa, sendo estas importantes para chegar a bom termo com o projeto. Conseguimos encontrar as seguintes funções numa equipa de Scrum [32]:
• Product owner - Cliente ou entidade responsável por gerir o backlog do produto. O
backlog é constituído pelas funcionalidades que o cliente pretende ver no produto
final. É representado neste projeto por um dos “responsáveis” pelo projeto já desenvolvido, descrito na secção 2.4;
• Equipa de desenvolvimento - Equipa responsável por desenvolver os incrementos do produto associados a um sprint;
• Scrum Master - Responsável por promover a teoria, práticas de desenvolvimento, regras e valores do Scrum.
De modo a percebermos algumas das razões pela qual esta forma de desenvolvimento foi escolhida, vão agora ser referenciadas algumas das vantagens e desvantagens associadas à utilização de Scrum [35]:
• Vantagens:
o As reuniões diárias, permitem que a equipa se encontre atualizada em relação aos desenvolvimentos efetuados previamente e ao trabalho futuro;
o As entregas incrementais permitem facilmente mudar o rumo de desenvolvimento, caso necessário.
• Desvantagens:
o Por vezes, torna-se complicado o Scrum Master planear, estruturar e organizar um projeto que não esteja bem definido;
o A constante mudança de especificações e rumo de desenvolvimento, pode levar por vezes a inconsistências e incertezas em relação ao produto final.
Existe a necessidade de referir que nem todas as regras associadas à framework Scrum foram seguidas “à risca”, pois não houve reuniões diárias e sprint reviews, uma vez que a equipa de desenvolvimento e Scrum master foram representados pela mesma pessoa.