Plataforma Web para Criação de Produtos Customizados Utilizando Arquitetura de Microserviços Com Docker

UNIVERSIDADE REGIONAL INTEGRADA DO ALTO URUGUAI E DAS MISSÕES
CAMPUS DE ERECHIM
DEPARTAMENTO DE ENGENHARIAS E CIÊNCIA DA COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ANDERSON EDUARDO BARBERINI
PLATAFORMA WEB PARA CRIAÇÃO DE PRODUTOS CUSTOMIZADOS

UTILIZANDO ARQUITETURA DE MICROSERVIÇOS COM DOCKER
ERECHIM - RS
2017
ANDERSON EDUARDO BARBERINI
PLATAFORMA WEB PARA CRIAÇÃO DE PRODUTOS CUSTOMIZADOS

UTILIZANDO ARQUITETURA DE MICROSERVIÇOS COM DOCKER
Trabalho de conclusão de curso,

apresentado ao Departamento de Ciência da
Computação da Universidade Regional
Integrada do Alto Uruguai e das Missões -
Campus de Erechim – como requisito à
obtenção do grau de bacharel em Ciência da
Computação.
Orientador: Marcos A. Lucas
ERECHIM - RS
2017
AGRADECIMENTOS
Aos meus pais, Marcos e Isolete, que são meus maiores exemplos de superação e sempre
me incentivaram e me deram forças em toda essa jornada. Às minhas irmãs, Andressa e Adrielli
que sempre foram compreensíveis e pacientes durante todo o processo.
A minha namorada Marilei, por todo apoio e carinho prestado durante muitas horas de
estudo e dedicação necessários para chegar até aqui.
A Deus, por ter me dado saúde e força para superar as dificuldades.
A todos os professores que de alguma forma colaboraram, transmitindo conhecimento
e experiência ao longo de todo curso. Em especial, ao professor Marcos Lucas, pela orientação
deste trabalho.
A todos os meus amigos que estiveram ao meu lado e entenderam as minhas ausências
nos momentos necessários.
Aos colegas de trabalho, pelas dicas e sugestões que foram muito importantes para
diversas decisões das minhas atividades acadêmicas.
RESUMO
O objetivo deste trabalho é implementar uma arquitetura de microserviços utilizando a

tecnologia de containers e Docker, para construção de uma API REST a fim de oferecer
recursos para controle de clientes, empresas e pedidos. Com base na API, desenvolver uma
plataforma web de alta experiência, onde os usuários, através de uma ferramenta exclusiva
oferecida por uma empresa, possam criar um produto personalizado, inserindo elementos como
imagens, textos, entre outros. Para as empresas, disponibilizar um sistema para gestão de
clientes e pedidos, possibilitando assim, um controle interno e facilitado de todo o negócio. O
trabalho foi proposto através de uma análise no mercado atual, onde foi possível identificar um
grande aumento no número de pessoas e microempresas trabalhando no segmento de criação
de produtos customizados. Sendo assim, o sistema tem como propósito de ajudar a entrada
destas empresas no mercado, facilitando sua organização e gestão além de oferecer uma
ferramenta onde os clientes possam interagir com os serviços oferecidos pelo negócio.
Palavras-chave: Arquitetura de microserviços. Containers. Docker. API REST. Plataforma

web para customização de produtos.
ABSTRACT
The objective of this paper is to implement a microservice architecture using container

technology and Docker to construct a REST API to provide resources for controlling customers,
companies and orders. Based on the API, develop a high experience web platform, where users,
through an exclusive tool offered by a company, can create a personalized product, inserting
elements such as images, texts, among others. For the companies, to provide a system for
management of customers and orders, thus enabling an internal and facilitated control of the
entire business. The project was proposed through an analysis in the current market, where it
was possible to identify a large increase in the number of people and micro enterprises working
in the segment of creation of customized products. Therefore, the system aims to help these
companies enter the market, facilitating their organization and management, as well as offering
a tool where customers can interact with the services offered by the business.
Key-words: Microservice architecture. Containers. Docker. REST API. Web platform for
product customization.
LISTA DE ILUSTRAÇÕES
Figura 1 - Arquitetura monolítica vs. arquitetura de microserviços ......................................... 13

Figura 2 - Diferença entre máquinas virtuais e containers ....................................................... 15
Figura 3 - Exemplo de uma API Gateway em uma arquitetura de microserviços ................... 19
Figura 4 - Exemplo de requisição HTTP .................................................................................. 30
Figura 5 - Definição do arquivo Dockerfile para os microserviços .......................................... 33
Figura 6 - Docker Compose do serviço de clientes .................................................................. 34
Figura 7 - Informações dos containers do Docker em execução .............................................. 35
Figura 8 - Modelo Entidade - Relacionamento do serviço de autenticação ............................. 36
Figura 9 - Diagrama de sequência do serviço de autenticação ................................................. 38
Figura 10 - Model Entidade - Relacionamento do serviço de clientes ..................................... 39
Figura 11 - Diagrama de sequência do serviço de clientes...................................................... 40
Figura 12 - Model Entidade - Relacionamento do serviço de empresas .................................. 41
Figura 13 - Diagrama de sequência do serviço de empresas .................................................... 42
Figura 14 - Modelo Entidade - Relacionamento do serviço de pedidos ................................... 43
Figura 15 - Diagrama de sequência do serviço de pedidos ...................................................... 44
Figura 16 - Docker Compose do Kong API Gateway .............................................................. 45
Figura 17 - Caso de uso geral da aplicação .............................................................................. 47
Figura 18 - Arquitetura de microserviços da aplicação ............................................................ 48
Figura 19 - Docker Compose da aplicação ............................................................................... 49
Figura 20 - Mogg - Tela inicial ................................................................................................ 50
Figura 21 - Mogg - Tela inicial da empresa ............................................................................. 51
Figura 22 - Mogg - Tela de identificação para área restrita do cliente ..................................... 52
Figura 23 - Mogg - Área restrita do cliente .............................................................................. 53
Figura 24 - Mogg - Customização de produtos ........................................................................ 54
Figura 25 - Mogg - Autenticação do painel administrativo...................................................... 55
Figura 26 - Mogg - Módulo de clientes do painel administrativo ............................................ 55
Figura 27 - Mogg - Módulo de pedidos do painel administrativo ............................................ 56
Figura 28 - Mogg - Detalhes de um pedido do painel administrativo ...................................... 57
Figura 29 - Mogg - Módulo de configurações do painel administrativo .................................. 57
LISTA DE TABELAS
Tabela 1 - Serviços expostos pela API de autenticação ........................................................... 37

Tabela 2 - Serviços expostos pela API de clientes .................................................................. 39
Tabela 3 - Serviços expostos pela API de empresas ................................................................ 41
Tabela 4 - Serviços expostos pela API de pedidos ................................................................... 43
Tabela 5 - Mapeamento das APIs no Kong API Gateway ....................................................... 46
LISTA DE ABREVIATURAS E SIGLAS
API - Application Programming Interface

CORS – Cross-Origin Resource Sharing
CSS - Cascading Style Sheets
DEVOPS – Development Operations
DDL - Data Manipulation Language
DML - Data Definition Language
HTML - HyperText Markup Language
HTTP - Hypertext Transfer Protocol
HTTPS - Hyper Text Transfer Protocol Secure
JSON - JavaScript Object Notation
LXC - Linux Containers
MB - Megabyte
MVC - Model-view-controller
MVVM - Model View ViewModel
ORM - Object Relational Mapping
PHP - PHP: Hypertext Preprocessor
REST - Representational State Transfer
SASS - Syntactically Awesome Stylesheets
SGBD - Sistema Gerenciador de Banco de Dados
SQL - Structured Query Language
URI - Uniform Resource Identifier
VM - Virtual Machine
XML - Extensible Markup Language
YAML - YAML Ain’t Markup Language
SUMÁRIO
1 INTRODUÇÃO................................................................................................................... 10
2 ARQUITETURA DA APLICAÇÃO ................................................................................ 12
2.1 Microserviços ................................................................................................................... 12
2.2 Containers ........................................................................................................................ 15
2.2.1 Docker ............................................................................................................................. 16
2.3 RESTful ............................................................................................................................ 17
2.4 API Gateway .................................................................................................................... 18
2.4.1 Kong API Gateway ......................................................................................................... 19
2.5 Autenticação e autorização ............................................................................................. 20
2.5.1 JWT ................................................................................................................................. 21
3 TECNOLOGIAS................................................................................................................. 22
3.1 HTML ............................................................................................................................... 22
3.2 CSS .................................................................................................................................... 23
3.3 JavaScript......................................................................................................................... 24
3.3.1 VueJS .............................................................................................................................. 25
3.4 PHP ................................................................................................................................... 25
3.4.1 Laravel............................................................................................................................. 26
3.4.2 Lumen ............................................................................................................................. 27
3.5 Banco de dados ................................................................................................................ 28
3.5.1 MySQL............................................................................................................................ 29
3.6 Servidor HTTP ................................................................................................................ 30
3.6.1 Nginx ............................................................................................................................... 31
4 IMPLEMENTAÇÃO DOS MICROSERVIÇOS............................................................. 32
4.1 Configuração dos containers .......................................................................................... 32
4.2 Serviço de Autenticação .................................................................................................. 35
4.2.1 Modelo Entidade - Relacionamento ................................................................................ 35
4.2.2 Serviços da API ............................................................................................................... 37
4.2.3 Diagrama de sequência ................................................................................................... 37
4.3 Serviço de Clientes ........................................................................................................... 38
4.3.1 Modelo Entidade – Relacionamento ............................................................................... 38
4.3.2 Serviços da API ............................................................................................................... 39
4.4 Serviço de Empresas ....................................................................................................... 40
4.4.2 Serviços da API ............................................................................................................... 41
4.5 Serviço de Pedidos ........................................................................................................... 42
4.5.2 Serviços da API ............................................................................................................... 43
4.6 Kong API Gateway .......................................................................................................... 44
5 DESENVOLVIMENTO DA APLICAÇÃO ..................................................................... 47
5.1 Descrição do sistema ....................................................................................................... 47
5.2 Configuração dos containers .......................................................................................... 48
5.3 Plataforma para customização ....................................................................................... 49
5.3.1 Página inicial ................................................................................................................... 50
5.3.2 Página da empresa ........................................................................................................... 50
5.3.3 Área restrita do cliente .................................................................................................... 51
5.3.4 Ferramenta de personalização ......................................................................................... 53
5.4 Painel administrativo ...................................................................................................... 54
5.4.1 Módulo de clientes .......................................................................................................... 55
5.4.2 Módulo de pedidos .......................................................................................................... 56
5.4.3 Módulo de configurações ................................................................................................ 57
6 CONCLUSÃO E TRABALHOS FUTUROS ................................................................... 58
REFERÊNCIAS ..................................................................................................................... 60
APÊNDICE A – DOCUMENTAÇÃO DA API ................................................................... 64
10
1 INTRODUÇÃO
O segmento de produtos customizados cresce a cada dia. O desejo de se diferenciar das

demais pessoas faz com que cada vez mais os clientes optem por customizações. Pode-se
destacar como exemplos cotidianos, canecas, camisetas, chinelos, almofadas, capas de
celulares, entre muitos outros. E essa demanda de produtos e a gama de possibilidades de
personalizações faz com que cada dia novas empresas aderem a esse mercado promissor.
Conforme uma publicação da revista Pequenas Empresas Grandes Negócios em
dezembro de 2016 (PEGN TV, 2016), é destacado um grande entusiasmo com o ramo e uma
tendência para 2017:
“Os negócios em casa são uma tendência para 2017 e uma saída
para momentos difíceis, afirma o consultor Milton dos Santos. É uma
tendência por conta das oportunidades todas que a tecnologia tem
permitido em relação a novas máquinas, novas aplicações. É um
negócio que exige pouco investimento, então ele é aberto a uma
quantidade grande de pessoas, e a gente não pode esquecer do fator crise
também que tem impulsionado esse tipo de negócio. ”
Além disso, conforme a repórter Fonseca (2017), a Feira do Empreendedor, organizada

pelo Sebrae, em São Paulo, trouxe opções de investimento voltados para quem quer empreender
com pouco capital disponível. Nesta categoria, estão equipamentos para operar na própria casa,
como máquinas de estampar canecas, camisetas, entre outros.
As máquinas, na maioria de pequeno porte, podem variar bastante, diferenciando-se
principalmente entre modelo e o preço. É possível adquirir uma máquina e customizar os mais
diversos tipos de itens e poder comercializar com parentes, amigos e vizinhos, por exemplo.
Outro aspecto interessante deste semento é que não é necessário um ponto comercial ou
estabelecimento, pois pode-se montar um “mini escritório” em casa mesmo.
No entanto, levar a empresa para o espaço virtual, na web, pode ter um certo custo.
Ferramentas e sistemas tornam-se um gasto que muitas empresas não abrem mão para investir.
O objetivo principal deste trabalho é, através de uma arquitetura de microserviços,
oferecer aos clientes de uma empresa uma página exclusiva, disponível através de um endereço
na web. A página irá possuir informações sobre a empresa e também uma ferramenta para
customização de produtos. Através desta ferramenta, é possível inserir elementos como
11
imagens e textos. Por fim, através de um formulário de autenticação ou de cadastro, o cliente

poderá finalizar o pedido. Os pedidos estarão disponíveis na área restrita, sendo possível
acompanhar qual o andamento em que cada um se encontra.
Em complemento a plataforma, outro objetivo deste trabalho é oferecer para as empresas
um sistema para consulta e gerenciamento de clientes e pedidos, visando um maior controle
sobre as vendas e um histórico dos clientes que estão cadastrados, reunindo informações
importantes para prospecção, como nome, e-mail e telefone.
O conteúdo deste trabalho está organizado em seis capítulos, além deste.
No segundo capítulo, é apresentado a arquitetura da aplicação, abordando os temas de
microserviços, containers e a estrutura de comunicação entre os serviços, utilizando o a
abordagem REST. Ainda neste, é descrito o funcionamento da autenticação e autorização de
todo o sistema e a utilização de uma API Gateway para centralizar os pontos de acesso e
oferecer uma camada adicional de segurança.
O terceiro capítulo apresenta quais foram as tecnologias utilizadas para o
desenvolvimento deste trabalho, descrevendo as linguagens de programação, os frameworks, o
banco de dados e o servidor HTTP.
O quarto capítulo refere-se à implementação da cada um dos serviços e os
procedimentos para a instalação e configuração dos containers através da plataforma do Docker.
O capítulo cinco apresenta o desenvolvimento da aplicação, descrevendo os módulos da
plataforma e também as capturas de tela das funcionalidades.
O capítulo seis conclui este trabalho, apresentando as considerações finais e as propostas
para os trabalhos futuros.
12
2 ARQUITETURA DA APLICAÇÃO
Neste capítulo serão apresentadas as principais tecnologias que foram utilizadas na

arquitetura do projeto, o formato de comunicação entre os serviços e o modelo desenvolvido
para garantir a segurança de cada recurso, através da autenticação e autorização.
2.1 Microserviços
Atualmente, o modelo natural de desenvolvimento de sistemas é baseado em uma

arquitetura conhecida como monolítica. Ela tem como principal característica um conjunto de
componentes que se encontram dentro de uma mesma unidade de implantação. Conforme o
sistema cresce, a complexidade aumenta, consumindo cada vez mais recursos.
Aplicações monolíticas podem ser bem-sucedidas, porém, cada vez mais, as pessoas
estão se sentindo frustradas com essa arquitetura, principalmente quando se trata de
implantação na nuvem. Os ciclos de mudanças exigem uma reconstrução e implantação
completa do software, tornando assim, difícil de manter uma boa estrutura modular. (LEWIS;
FOWLER, 2014)
Anita (2016), descreve em sua publicação o modelo tradicional de design de software
monolítico, onde as aplicações são desenvolvidas como uma única entidade. Geralmente os
aplicativos consistem de três partes: uma interface do lado do cliente que é acessada através do
navegador, um banco de dados, e uma aplicação monolítica do lado do servidor.
As aplicações monolíticas, embora possam ser atraentes, apresentam desafios à medida
que sua complexidade cresce. A escalabilidade da aplicação apresenta problemas, pois o
aplicativo por completo deve ser escalado. Além disso, mudanças e atualizações exigem que
todo o software seja reconstruído e redistribuindo, custando um tempo e esforço valioso. Esse
foi uma das principais motivações para o surgimento dos microserviços. (ANITA, 2016)
De acordo com os autores Fowler e Lewis (2014), o termo “Arquitetura de
Microserviços” surgiu nos últimos anos para descrever um modelo de projetar aplicativos de
software como uma suíte de serviços independentemente implantáveis.
Para Newman (2015), os microserviços são pequenos serviços autônomos que
trabalham em conjunto, desenvolvidos sobre princípio de responsabilidade única, separando as
coisas que mudam pelo mesmo motivo, e as coisas que mudam por motivos diferentes.
Microserviço é uma abordagem para desenvolver um único aplicativo como um
conjunto de pequenos serviços, cada um funcionando em seu próprio processo e se
13
comunicando através mecanismos leves, como uma API de recursos HTTP. Esses serviços são
desenvolvidos em torno de capacidades de negócios e implementados independentemente. São
de baixo acoplamento, podem ser escritos em diferentes linguagens de programação e utilizar
diferentes tecnologias para persistência de dados individualmente. (LEWIS; FOWLER, 2014)
A Figura 1 ilustra um comparativo entre uma arquitetura monolítica e uma arquitetura
de microserviços.
Figura 1 - Arquitetura monolítica vs. arquitetura de microserviços
Fonte: ANITA (2016)
Para Newman (2015), os benefícios dos microserviços podem ser muitos e variados. Os
principais que ele destaca são:
 Tecnologia heterogênea, pois nos permite escolher a ferramenta certa para cada
trabalho sem depender da abordagem mais padronizada, que muitas vezes, acaba
sendo de menor domínio comum.
 Resiliência, pois se um componente do sistema falhar, pode-se isolar o problema e

o resto da aplicação vai continuar funcionando.
 Escalonamento, pois com serviços menores, pode-se escalar estes serviços que
precisam ser dimensionados permitido que outras partes do sistema executem em
hardware menos poderoso.
14
 Facilidade de implantação, pois é possível fazer uma mudança para um único serviço
e implantá-lo independentemente. Este processo se torna muito mais rápido e muito
mais seguro do que implantar uma aplicação inteira. Esta é uma das principais razões
para organizações com Amazon e Netflix usarem arquitetura de microserviços.
 Alinhamento organizacional, pois permite trabalhar com equipes distribuídas, de

menor tamanho, possibilitando também que uma equipe específica seja responsável
por um determinado serviço.
 Composição, que aborda o conceito de reutilização das funcionalidades. Isso é

importante especialmente quando se pensa sobre as diversas origens de acesso,
como web, mobile, aplicativos nativos, tablets, wearable devices e até à terceiros.
 Otimização para substituição, pois permite uma maior facilidade de substituir um

sistema legado e desagradável. Com microserviços as barreiras para reescrever ou
remover serviços são muito mais baixas e de menores custos.
Contudo, uma arquitetura baseada em microserviços introduz uma certa complexidade

no desenvolvimento e ciclo de vida do projeto. Fowler (2015), descreve os três principais
desafios:
 Distribuição: performance é a primeira. Quando um serviço precisa realizar diversas

chamadas a outros serviços remotos, acaba-se elevando o tempo de respostas e a
latência. Em segundo, as chamadas assíncronas são difíceis e também complicadas
de se depurar. Outro ponto, é a confiabilidade. Chamadas remotas podem falhar e
você precisa projetar um sistema que seja tolerante.
 Consistência Eventual: a gestão descentralizada de dados dos microserviços pode

causar certos problemas de consistência. Isto requer vários recursos para atualização
de dados, visto que transações distribuídas não são vistas como uma boa opção.
 Complexidade Operacional: Não há maneira fácil de lidar com dezenas de serviços

sem automação e a colaboração que a entrega contínua oferece. Com isso, a
demanda de gerenciamento e monitoramento cresce. Para isso, é requerido uma série
de novas habilidades e ferramentas e principalmente, introduzir a cultura de devops:
maior colaboração entre desenvolvedores, operações e todos os envolvidos na
entrega de software.
15
2.2 Containers
Containers estão revolucionando a forma de desenvolver, distribuir e executar

softwares. A aplicação roda identicamente, independentemente do ambiente do host, seja num
laptop ou um cluster na nuvem. De primeira vista, eles aparentam ser uma forma leve de
máquinas virtuais (VMs), porém funcionam de maneira diferente. (MOUAT, 2015)
Donda (2015) define que a principal diferença entre os containers e máquinas virtuais,
é que os containers são totalmente isolados e são executados dentro do mesmo sistema
operacional base, compartilhando o mesmo kernel. Na máquina virtual, cada VM tem seu
próprio sistema operacional. Essa diferença torna os containers muito mais eficientes
considerando uma arquitetura de microserviços. Na Figura 2 é possível visualizar graficamente
essa diferença;
Figura 2 - Diferença entre máquinas virtuais e containers
Fonte: DONDA (2015)
Para Mouat (2015), as principais vantagens dos containers são:
 Compartilham os recursos com o sistema operacional host, o que os torna mais

eficientes. Podem ser iniciados ou terminados em uma fração de um segundo. O
aplicativo executado nos containers tem pouco ou nenhum overhead comparado
com os que são executados nativamente no sistema operacional.
16
 A portabilidade dos containers elimina vários problemas causados por mudanças

sutis no ambiente de execução. Poderia até mesmo acabar com a famosa frase, "mas
na minha máquina funciona!".
 Containers são leves e isso nos permite executar dezenas deles ao mesmo tempo,
tornando possível emular um sistema distribuído pronto para produção.
 Permite que usuários executem aplicativos complexos sem precisar gastar horas em
problemas de configuração e instalação de ambientes.
Contudo Mouat (2015) ainda afirma: container é um conceito antigo. Por décadas os
sistemas UNIX já tinham um suporte ao chroot, que fornece uma forma de isolamento do
sistema de arquivos. Complementando, Clark (2014) relembra que o Google iniciou o
desenvolvimento do cgroups para o Linux. Esta tecnologia permite limitar o uso de recursos
para um conjunto de processo. Então, em meados dos anos 2000, eles começaram a mover toda
sua infraestrutura para containers. Tais tecnologias foram cruciais para o início do projeto Linux
Containers (LXC), que começou em 2008 e visava fornecer uma solução para conteinerização.
2.2.1 Docker
Docker é a principal plataforma de container de software do mundo. O Docker

automatiza as tarefas repetitivas de configurar ambientes de desenvolvimento, deixando o
desenvolvedor focado no que interessa: na construção de software. (DOCKER, 2017)
Clark (2014), cita em uma publicação um trecho onde Ben Golub, chefe-executivo do
Docker, fala sobre os containers: “A tecnologia não era acessível / útil para os desenvolvedores,
os containers não eram portáteis entre diferentes ambientes, e não havia ecossistema ou
conjunto de recipientes padrão”. A inovação inicial do Docker foi justamente abordar estas
questões. Oferecer uma API para facilitar o uso de containers, de tal forma que a comunidade
possa colaborar, trabalhando com containers portáteis em todos os ambientes.
Docker é uma plataforma open source escrita em GO, que é uma linguagem de
programação de algo desempenho desenvolvida dentro da Google. Docker utiliza a tecnologia
LXC e oferece uma solução completa para criação, execução e distribuição de containers.
Possui uma comunidade que, através de um repositório chamado Docker Hub, são
disponibilizados milhares de imagens prontas. Usando a API que a ferramenta nos fornece, é
possível criar de maneira fácil e com poucas linhas, um ambiente completo usando imagens
17
que estão disponíveis no Docker Hub ou criando novas imagens a partir de arquivos de
definição chamados Dockerfiles. (DIEDRICH, 2015)
O Docker Engine é quem fornece esta interface para execução dos containers. Além
disso, outras ferramentas foram desenvolvidas, o Docker Swarm, para gerenciamento de
cluster; Kitematic, uma GUI para trabalhar com containers e a Docker Machine, um utilitário
por linha de comando para provisionamento de hosts Docker. (MOUAT, 2015)
2.3 RESTful
Segundo Fielding (2000), Representational State Transfer, ou simplesmente REST,

pode ser definido como um estilo arquitetônico no qual é aplicado um conjunto de restrições
aos recursos que compões a arquitetura. Ele ainda cita que um dos principais objetivos teste
modelo é apoiar a implantação gradual e fragmentada de mudanças dentro de uma arquitetura
já implantada.
O conjunto de restrições arquitetônicas do REST enfatizam a escalabilidade de
interações de componentes, a generalidade de interfaces, a implantação independente de
componentes e o uso de componentes intermediários para reduzir a latência, reforçar a
segurança e encapsular sistemas legados. (FIELDING, 2000)
Rodriguez (2015) descreve que o termo RESTful refere-se à implementação de um
serviço web que utiliza o modelo REST. O autor ainda enfatiza que uma implementação
concreta deve seguir quatro princípios básicos de design: usar métodos HTTP, ser stateless,
URIs em estrutura de diretórios e formato de dados.
Usar explicitamente métodos HTTP, segundo Rodriguez (2015) é uma das
características chaves de um serviço RESTful. Os métodos HTTP devem ser explícitos e seguir
o protocolo definido pelo RFC 2616. A URI de uma solicitação deve identificar um recurso
específico. Esse identificador deve ser um substantivo e não verbo. Afim de se obter uma
interface uniforme, para definir uma ação sobre uma solicitação, é importante usar os métodos
oferecidos pelo protocolo HTTP, como o GET para recuperar um recurso, POST para criar um
recurso, PUT para alterar o estado de um recurso ou atualiza-lo e DELETE para remover ou
excluir um recurso.
Requisições stateless são essenciais para conseguir manter a demanda de escalar
serviços em clusters, com recursos de balanceamento de carga e gateways, é crucial que as
solicitações sejam completas e independentes, define Rodriguez (2015). Ou seja, deve ser
possível enviar solicitações que incluem todos os dados necessários para que os componentes
18
dos servidores possam encaminhar, rotear e balancear sem que nenhum estado seja mantido
localmente entre as solicitações. Uma requisição stateless melhora o desempenho do serviço e
simplifica o design e a implementação de componentes do lado do servidor, visto que a ausência
do estado no servidor elimina a necessidade de sincronizar os dados da sessão com um
aplicativo externo.
O terceiro princípio definido por Rodriguez (2015), enfatiza que os URIs de serviços da
Web devem ser intuitivos a ponto de serem fáceis de adivinhar. Para isso, a estrutura de um
URI deve ser direta, previsível e facilmente compreensível. Uma maneira de atingir esse nível
de usabilidade é definir URIs de forma hierárquica, utilizando estrutura de diretórios. Para isso,
deve-se seguir algumas diretrizes como: ocultar a extensão do arquivo de script (.php, .jsp,
.asp), sempre manter tudo em minúsculo e usar hifens ao invés de espaços.
Por fim, o autor (RODRIGUEZ, 2015) define como quarto princípio a utilização de
XML, JSON ou ambos como formato de dados usado na troca de informações entre a aplicação
e os serviços. É importante que os serviços tenham a capacidade de suportar mais de um tipo
de MINE, como XML e JSON. Isso permite que a aplicação que for usar estes serviços utilize
o formato que seja mais adequado para o desenvolvimento.
2.4 API Gateway
Uma API Gateway é um único ponto de entrada de um sistema e é responsável pelo

roteamento das solicitações. Todas as requisições solicitadas precisam passar primeiro no
gateway para depois serem roteadas ao serviço apropriado. Também atua como filtro para
tráfego de chamadas e como um dispositivo de segurança para o controle de acesso.
(MALAVASI, 2016).
Segundo os autores Richardson e Smith (2016), o API Gateway encapsula a arquitetura
interna do sistema e fornece uma API adaptada a cada cliente. Ele pode ter outras
responsabilidades, como autenticação, monitoramento, balanceamento de carga, cache,
solicitação de modelagem e gerenciamento e manipulação de resposta estática. A Figura 3,
exemplifica o uso de uma API Gateway em uma arquitetura de microserviços.
19
Figura 3 - Exemplo de uma API Gateway em uma arquitetura de microserviços
Fonte: (RICHARDSON; SMITH, 2016)
Malavasi (2016) descreve que uma API Gateway é umas das ferramentas no mercado
mais efetivas para segurança, controle e desenvolvimento de APIs, principalmente por
contemplar os conceitos de CID, formado por três pilares: confidencialidade, integridade e
disponibilidade. Além disso, o Gateway vai atuar em uma camada separada da aplicação, onde
é possível separar claramente APIs e microserviços implementados. Outro benefício é a
possibilidade de antecipar e rastrear erros através de logs, já que todas as chamadas aos serviços
irão passar pelo Gateway.
2.4.1 Kong API Gateway
O Kong é uma API layer escalável e de código aberto (também conhecida como gateway
API ou API Middleware). É executado na frente de qualquer API RESTful e é estendido através
de plugins, que fornecem funcionalidade extras, como autenticação, monitoramento, segurança,
20
controle de trafego, entre outros. Toda solicitação feita para a API atingirá primeiro o Kong e,
em seguida, será processada para a API final. Entre pedidos e respostas, o Kong irá executar
qualquer plugin que você tenha decidido instalar. Kong efetivamente se torna o ponto de entrada
para cada solicitação realizada. (KONG, 2017)
Neste projeto, a principal função da API Gateway vai ser oferecer uma camada para
autenticação, visto que determinados serviços só serão acessíveis por usuários autenticados.
Também simplificar o roteamento das chamadas RESTful, encapsulando a arquitetura interna
do sistema. A escolha desta ferramenta foi definida analisando três fatores: ser uma ferramenta
open source, possuir grande contribuição pela comunidade de desenvolvedores e a quantidade
de recursos / plugins que a ferramenta oferece.
2.5 Autenticação e autorização
Autenticação e autorização são conceitos fundamentais quando se trata de pessoas e

coisas que interagem com o nosso sistema. No contexto de segurança, autenticação é o processo
pelo qual o usuário confirma sua identidade, por meio de comparação de credenciais, como
usuário e senha. A autorização é o mecanismo onde é mapeado as ações permitidas a um
usuário, ou seja, os privilégios atribuídos ao sujeito autenticado. (NEWMAN, 2015)
Ao se usar uma arquitetura monolítica tradicional, o mecanismo de autenticação é
simplificado, onde um único servidor contém todos os dados de um usuário, podendo verificar
e criar uma sessão HTTP quando o usuário é autenticado. Porém, em uma arquitetura de
microserviços, que segue o princípio de stateless, distribuir estes dados entre os servidores
torna-se um problema difícil, visto que cada um precisa saber quando um usuário está
autenticado e quem ele é. (LOENERT, 2016)
Loenert (2016) destaca entre as principais abordagens para resolver este problema o uso
de tokens do lado do cliente. Quando o usuário é autenticado, um token é criado e assinado por
um serviço de autenticação. Esse token possui informações suficientes para que a identidade do
usuário seja reconhecida em todos os microserviços. A autora ainda enfatiza, que em
complemento com uma API Gateway, é possível estabelecer um tempo de vida para cada chave
gerada ou até mesmo excluir ela do sistema, possibilitando assim uma forma de logout.
A solução como mecanismo de criação e validação de tokens foi através de JSON Web
Tokens (JWT), devido a simplicidade e facilidade de utilizar, contando ainda com um bom
suporte de bibliotecas para diversas linguagens de programação. Outro ponto forte é que o Kong
API Gateway já oferece um plugin para autorização via JWT.
21
2.5.1 JWT
JSON Web Token (JWT) é um padrão aberto especificado pela RFC 7519 que define
um modo compacto e autocontido para a transmissão segura de informações entre as partes
como um objeto JSON. Essas informações podem ser verificadas e confiáveis porque são
assinadas digitalmente. Os JWTs podem ser assinados usando um uma chave secreta (com o
algoritmo HMAC) ou um par de chaves público / privado usando o RSA. (JWT, 2017)
Os termos compacto e autocontido, segundo JWT (2017), são definidos por:
 Compacto, devido ao seu tamanho menor, sendo possível ser enviado em uma URL
com parâmetros POST ou dentro de um cabeçalho HTTP. Com o tamanho menor, a
transmissão é mais rápida.
 Autocontido, pois a carga contém todas as informações necessárias sobre o usuário,

evitando a necessidade de consultar o banco de dados mais de uma vez.
De acordo com o site oficial, JWT (2017), a estrutura do token é formada por 3 partes:
header, payload e signature. Todas elas são encodadas em Base64.
O header normalmente consiste em duas partes: o tipo de token, que no caso é o JWT,
e o algoritmo usado, como o HMAC SHA256, utilizado para este trabalho.
O payload contém os meta-dados, ou claims, que definem por exemplo, a entidade do
usuário. Nos claims é possível também definir o tempo de expiração do token.
Para criar o signature é preciso do header, payload, um secret e o algoritmo
especificado. No caso do HMAC SHA256, o signature é criado da seguinte maneira:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
O resultado da signature é o token, que terá uma estrutura semelhante ao exemplo

abaixo, onde é possível notar a separação de cada uma das partes através de um ponto:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIi
wiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
22
3 TECNOLOGIAS
Neste capítulo serão apresentadas as principais tecnologias utilizadas para o

desenvolvimento da aplicação. A estrutura front-end, que corresponde a interface que o usuário
interage, foi implementada através das linguagens HTML, CSS e JavaScript. Para suporte desta
camada, foi utilizado o framework VueJS para facilitar a manipulação e exibição dos dados.
No contexto do back-end, foi utilizado a linguagem PHP com dois frameworks: o
Laravel, responsável por dar todo o suporte a plataforma web e o Lumen, um micro-framework
baseado no Laravel que, de acordo com os motivos expostos na sessão 3.4.2, foi usado como
solução para construção de microserviços.
Todas as informações são armazenadas em um banco de dados relacional, o MySQL.
Tanto a aplicação quanto os microserviços utilizam como servidor HTTP o Nginx.
3.1 HTML
HyperText Markup Language, ou HTML, uma linguagem para descrever a estrutura das
páginas da Web. Ela possibilita a criação de diversos elementos, como títulos, textos tabelas,
listas, formulários, figuras e principalmente links. (W3C, 2017)
De acordo com os autores Eis e Ferreira (2012), a primeira versão do HTML foi
desenvolvida por Tim Berners-Lee, em 1990. Entre 1993 e 1995, o HTML ganhou as versões
HTML+, HTML2.0 e HTML3.0. Cada uma delas possuíam diversas mudanças que
enriqueciam cada vez mais as possibilidades da linguagem. Até aqui o HTML ainda não era
tratado como um padrão. A partir de 1997, com o surgimento da W3C, grupo de trabalho
fundado por Berners-Lee, que tinha como objetivo manter o padrão do código, trabalhou nas
versões 3.2 do HTML fazendo com que ela fosse tratada como prática comum.
Em 2004, desenvolvedores de empresas como Apple, Mozilla e Opera, descontentes
com os rumos adotados pela W3C, fundaram a WHATWG (Web Hypertext Application
Technology Working Group), onde se propuseram a desenvolver as especificações para uma
nova linguagem, que seria chamado hoje de HTML 5. (SILVA, 2014)
O HTML4, não trazia grandes evoluções para a semântica de código e também não
facilitava a manipulação de elementos via CSS ou JavaScript. O HTML5 tinha como principal
objetivo facilitar a manipulação de elementos, possibilitando o desenvolvedor modificar as
características dos objetos de forma não intrusiva e de maneira transparente para o usuário final.
23
Em outubro de 2006, Tim Berners-Lee anunciou que trabalharia juntamente com o

WHATWG na produção do HTML5, que passou a ser conhecido pelo mundo e principalmente
pelo W3C. O HTML5 modifica o formato com que se codifica e se organiza as informações na
página. Sua semântica reduz as linhas de códigos, possibilita mais interatividade sem perda de
performance e sem a necessidade do uso de plugins. É retro compatível com as versões
anteriores e também com os browsers recentes, possibilitando a utilização de novas
características imediatamente. (EIS; FERREIRA, 2012)
Eis e Ferreira (2012) trazem uma abordagem onde o desenvolvimento cliente-side é
dividido em três camadas principais: informação, formatação e comportamento. Informação é
a mais importante. Vem antes de todas as outras e fica sob o controle do HTML, que marca a
informação dando-lhe significado. Este significado é reconhecido por robôs, sistemas,
aplicações ou outros meios que possam vir a reutilizar a informação publicada.
A segunda camada, conforme apresentado por Eis e Ferreira (2017), é a Formatação,
que é responsável por controlar o visual da informação exibida pelo HTML. Atualmente essa
camada é mantida pelo CSS. O CSS é responsável por formatar a informação para que ela seja
consumida em qualquer outro meio de acesso de forma simples.
A última camada definida por Eis e Ferreira (2017) é o comportamento, que define quais
serão os comportamentos dos elementos do HTML. O JavaScript é o principal responsável por
esta camada. Com JavaScript é possível manipular características dos elementos pelo CSS.
3.2 CSS
Cascading Style Sheet ou CSS, é uma linguagem para descrever a apresentação das
páginas web, incluindo cores, layout e fontes. Também permite adaptar o a tela para diferentes
dispositivos, como telas grandes, pequenas ou até para impressas. O CSS é independente do
HTML e pode ser usado com qualquer linguagem de marcação baseada em XML. (W3C, 2017)
Essa camada da web é muito importante. Ela quem define a aparência do documento,
através de características adicionadas aos elementos através de regras. Uma regra CSS é
composta de duas partes: o seletor e a declaração. O seletor é o alvo da regra e a declaração
determina os parâmetros para estilização. Os parâmetros são constituídos de uma propriedade,
que define qual a característica a ser estilizada e o valor, que quantifica ou qualifica a
propriedade. (SILVA, 2011)
Segundo Alvarez (2008), a primeira versão do CSS (CSS1) foi desenvolvida em 1995,
porém foi lançada em 1996 como recomendação oficial do W3C. Ela trouxe grandes avanços
24
para o visual das páginas, oferecendo controle aos elementos existentes no documento. Porém,
conforme a evolução do design, se existia a necessidade cada vez maior de customizações que
o CSS não suportava.
Surgiu então a segunda versão, o CSS2. Com sua chegada, muitas novidades foram
incorporadas, melhorando a qualidade das páginas desenvolvidas. E da mesma forma que a
versão anterior, com o passar do tempo, o CSS2 não estava mais suprindo as novas
necessidades, e era preciso fazer o uso de truques ou hacks e utilizar o apoio de outras
ferramentas para se chegar no resultado esperado. Atualmente a versão mais recente é a CSS3.
Nela, foram incorporadas novos seletores, recursos e diversas funcionalidades que
revolucionaram a forma com que se estiliza páginas. (ALVAREZ, 2008)
Rabelo (2017) destaca que, com a evolução do CSS, surgiu ferramentas para auxiliar no
desenvolvimento, como os pré-processadores. SASS é uma destas ferramentas. Ela permite
adicionar lógica, variáveis, aninhação de seletores, entre diversos outros recursos. Isso traz um
ganho enorme em produtividade e mantem uma boa organização nos códigos. No fim, os
arquivos SASS são processados, e produzem uma versão compilada contendo o CSS puro.
3.3 JavaScript
JavaScript é uma linguagem de programação web. Ela está presente na maioria dos sites
modernos todos os navegadores modernos, inclusive consoles, tablets e smartphones incluem
interpretadores JavaScript, o que torna a linguagem mais onipresente da história. Conforme
comentado nos capítulos anteriores, HTML é usado para especificar o conteúdo, CSS para
especificar a apresentação de páginas e o JavaScript para especificar o comportamento das
páginas. É uma linguagem de programação interpretada de alto nível, dinâmica e não tipada.
(FLANAGAN, 2011)
JavaScript tem uma biblioteca padrão de objetos e um conjunto de elementos que
formam o núcleo da linguagem. Pode-se estender o núcleo em dois lados, cliente-side e server-
side. (MOZILLA DEVELOPER NETWORK, 2017)
 Client-side: Usado para aplicações do lado do cliente. Fornece objetos para controlar
um navegador web e seu Document Object Model (DOM).
 Server-side: Usado para aplicação do lado do servidor. Fornece objetos relevantes a

execução em um servidor, permitindo comunicação com banco de dados,
manipulação de arquivos, entre outros.
25
3.3.1 VueJS
VueJS é uma biblioteca para construção de interfaces web interativas. Também é

definido como um framework progressivo para a construção de interfaces de usuário e seu
design foi inspirado no padrão MVVM. O Vue conecta o View e o Model através de data
bindings, e a manipulação e formatação dos dados é feito através de diretivas e filtros. (VUE,
2017)
Filipova (2016), define MVVM (Model View ViewModel) como um padrão de
arquitetura cujo ponto central é o ViewModel, que no caso, é garantido pelo Vue. O model
contém dados e algumas lógicas de negócio, e o view é responsável pela representação destes
dados. E então, o ViewModel é responsável por essa ligação dos dados, garantido que os dados
sejam propagados entre essas duas camadas, conceito conhecido como reatividade.
O sistema de componentes é outro conceito importante no Vue, pois ele permite a
construção de aplicativos em larga escala composto por pequenos componentes, autônomos e
muitas vezes reutilizáveis. São representados como se fosse um elemento nativo do HTML,
com alguns atributos especiais. (VUE, 2017)
O VueJS possui suporte a diversas bibliotecas. A mais conhecida é a Vuex, uma
arquitetura de aplicações para gerenciamento de estado centralizado em aplicações Vue. Ela é
uma solução para compartilhamento de dados entre os componentes, dispondo de vários
recursos conhecidos como states, actions, mutations e getters responsáveis por recuperar e
armazenar os dados em uma única fonte de dados. (FILIPOVA, 2016)
A biblioteca ainda oferece suporte à criação de plugins, que acrescentam
funcionalidades ao Vue em nível global. Os plugins podem ser dos mais variados tipos, pois
não possuem um escopo estrido e definido. Atualmente, existem diversas implementações,
como por exemplo o vue-router, utilizada como solução para roteamento de páginas web.
(VUE, 2017)
3.4 PHP
O PHP (PHP: Hypertext Preprocessor) é uma linguagem de script open source de uso
geral, utilizada especialmente para o desenvolvimento web e que pode ser embutida dentro do
HTML. (PHP, 2017)
A linguagem de programação PHP foi criada em 1994, por Rasmus Lerdorf, e
significava Personal Home Page Tools. Ela era formada por um conjunto de scripts escritos em
26
linguagem C, que eram voltados a criação de páginas dinâmicas. Com o tempo, mais pessoas
passaram a utilizar a linguagem, e Rasmus adicionou vários recursos, como a interação com
banco de dados. Em 1995 o código-fonte do PHP foi liberado e com isso mais desenvolvedores
colaboraram para o projeto.
Ao longo do tempo o PHP passou por várias reescritas de código e foi evoluindo cada
vez mais. Por volta de 1998, sua sigla mudou para PHP: Hypertext Preprocessor e já estava
presente em cerca de 10% dos domínios da internet. Apesar de toda evolução, o PHP ainda
necessitava de maior suporte à orientação a objetos. Esses recursos foram trazidos pelo PHP 5,
em julho de 2004. Ao longo de mais de uma década, o PHP continua adicionando novos
recursos e é considerada como uma das linguagens de programação orientadas a objetos que
mais crescem no mundo. Estima-se que o PHP seja utilizado em mais de 80% dos servidores
web existentes, tornando-a disparadamente a linguagem mais utilizada para desenvolvimento
web. (DALL’OGLIO, 2015)
Segundo Gilmore (2008), o PHP possui quatro características chaves que conduzem a
linguagem a uma posição de destaque no mercado de desenvolvimento:
 Praticidade: a linguagem que permite ao usuário construir aplicações poderosas

mesmo com um mínimo de conhecimento. Ela também oferece uma solidez em se
tratando de aninhamento de funções, como no exemplo de código a seguir:
$randomString = substr(md5(microtime()), 0, 5);
 Poder: os desenvolvedores PHP têm mais de 180 bibliotecas à disposição, que ao

total, somam mais de 1.000 funções.
 Possibilidade: desenvolvedores PHP raramente estão atrelados a uma única solução

de implementação, e oferece desde um suporte nativo à mais de 25 produtos de
banco de dados, até a escolha entre programação procedural ou orientada a objetos.
 Preço: PHP é uma linguagem open source e é disponibilizada gratuitamente.
3.4.1 Laravel
Laravel é um framework PHP para desenvolvimento aplicações web, com sintaxe

expressiva e elegante. Ele facilita tarefas comuns usadas na maioria dos projetos da web, como
autenticação, roteamento, armazenamento em sessões e cache, mapeamento objeto relacional
(ORM), processamento de jobs em background, entre outros. (LARAVEL, 2017)
27
A Laravel reutiliza e monta os componentes existentes visando proporcionar uma

camada coesa sobre a qual pode-se construir aplicações web de uma forma mais estruturada e
pragmática. Inspirando-se em demais frameworks populares, não apenas no PHP, mas também
em outras linguagens de programação, a Laravel oferece um robusto conjunto de ferramentas e
uma arquitetura de aplicativos que incorpora muitos dos melhores recursos de frameworks
como CodeIgniter, Yii, ASP.NET MVC, Ruby on Rails, Sinatra entre outros. (BEAN, 2015)
Bean (2015) descreve diversos recursos podem ajudar a aumentar a produtividade
utilizando Laravel, em especial, a versão 5:
 Modularidade: Laravel foi construído em cima de mais de 20 bibliotecas diferentes

e é dividido em módulos individuais. Integrado com Composer, um gerenciador de
dependências para PHP, esses componentes podem ser atualizados com facilidade.
 Testabilidade: o framework foi desenvolvido para facilitar os testes,

disponibilizando diversos helpers que fornecem suporte para a criação deles.
 Roteamento: permite muita flexibilidade para definir as rotas da aplicação.
 Gerenciamento de configuração: oferece um suporte para criar configurações

baseadas em diferentes ambientes, como por exemplo, local, testes e produção.
 Banco de dados: Laravel vem com um conjunto de ferramentas que possibilitam

definir o esquema do banco de dados através de código e, com isso, acompanhar e
executar todas as mudanças feitas de maneira simples. Também é possível realizar
a população de dados de uma tabela através dos recursos oferecido pelo framework.
 Templates: utiliza um templage engine conhecido por Blade, uma linguagem leve,
onde é possível criar layouts hierárquicos com blocos predefinidos nos quais o
conteúdo é injetado dinamicamente.
 Autenticação: o framework vem com uma estrutura pronta para implementação de

registro, autenticação e até mesmo enviar lembretes de senha aos usuários.
3.4.2 Lumen
Lumen é um micro framework baseado em Laravel incrivelmente rápido. É uma ótima

solução para a construção de microserviços e APIs, que utiliza os recursos disponíveis no
framework Laravel. (LUMEN, 2017)
28
Conforme Barnes (2016) descreve em sua publicação, Lumen é uma ótima escolha
quando se precisa de velocidade. E caso de necessidade de mais poder, migrar do Lumen para
o Laravel é um processo simples e facilitado.
O autor Redmond (2016) cita o micro-framework Lumen como uma oportunidade para
melhorar o fluxo de trabalho dos desenvolvedores PHP, possibilitando a padronização em torno
de um conjunto poderoso: Laravel e Lumen. O Lumen pode ser tão minimalista quanto precise.
Ele é rápido e, mas mais importante, ele ajuda a ser produtivo.
3.5 Banco de dados
Um sistema de banco de dados é simplesmente um sistema computadorizado que tem

por finalidade armazenar informações e permitir que usuários realizem diversas operações
sobre estas informações, como por exemplo, inserir, buscar, excluir e alterar dados. As
informações contidas no banco de dados podem ser qualquer coisa que tenha algum significado
ao indivíduo ou a organização na qual o sistema deve servir. Um banco de dados por si só é
uma coleção de dados persistentes que são utilizados por uma determinada aplicação. (DATE,
2004)
Segundo os autores Silberschatz, Korth e Sudarshan (2010), um sistema de
gerenciamento de banco de dados (SGBD) é uma coleção de dados inter-relacionados e um
conjunto de programas responsáveis por acessar esses dados. A coleção de dados é referida
como o banco de dados, que contém informações relevantes para uma organização. O principal
objetivo de um SGBD é fornecer recursos para armazenamento e recuperação das informações,
garantindo sobre tudo, a segurança dos dados armazenados.
Por baixo da estrutura de um banco de dados está o modelo de dados. O modelo é
definido por uma coleção de ferramentas conceituais para descrever os dados, relacionamentos
e semânticas dos dados e restrições de consistência. (SILBERSCHATZ; KORTH;
SUDARSHAN, 2010)
Date (2004) conceitua modelo de dados como uma definição abstrata, autônoma e lógica
dos objetos, operadores e outros elementos com qual os usuários interagem, sendo os objetos
responsáveis por modelar a estrutura dos dados, e os operadores por modelar o seu
comportamento.
Os modelos de dados normalmente utilizados pelos SGBD’s são: modelo hierárquico,
modelo em redes, modelo orientado a objetos e o modelo relacional, amplamente usado. O
modelo relacional usa uma coleção de tabelas para representar os dados e as relações entre eles.
29
Cada tabela, é composta por colunas que possuem um nome exclusivo. Os dados são
armazenados na tabela em forma de registros, onde cada um possui seus atributos. Para se
referir a uma tabela, usa-se o termo relação ou entidade. O termo tupla é usado para se referir a
uma linha, e o termo atributo para se referir a coluna de uma tabela. (DATE, 2004)
Um sistema de banco de dados fornece uma linguagem de definição de dados (DDL)
para especificar seu esquema e uma linguagem de manipulação de dados (DML) para expressar
suas consultas e atualizações. Dentre as diversas linguagens em uso, a amplamente utilizada é
o SQL. O SQL (Structured Query Language). (SILBERSCHATZ; KORTH; SUDARSHAN,
2010)
3.5.1 MySQL
Segundo a Oracle (2017), o MySQL é o sistema de gerenciamento de banco de dados

de código aberto mais popular do mundo. Ele se tornou a principal escolha devido ao seu
desempenho, confiabilidade e facilidade de uso.
MySQL é conhecido devido a sua fácil utilização. É um SGBD que utiliza o modelo
relacional, e a linguagem SQL. Foi inicialmente desenvolvido para trabalhar com projetos de
pequeno e médio porte, porém, com a evolução de suas versões, ultrapassou os limites de
capacidade e é usado por empresas que trabalham com grandes volumes de dados, como NASA,
Bradesco, HP, Sony entre outras. (RICARDO, 2017)
Ricardo (2017) ainda destaca os princípios da licença GNU/GLP, onde o MySQL foi
desenvolvido e distribuído:
 Utilização: permite a utilização do software para qualquer finalidade.
 Distribuição: permite a livre distribuição entre quaisquer pessoas.
 Didática: permite que seu funcionamento seja estudado através do seu código fonte.
 Colaboração: permite a alteração do seu código-fonte a fim de propor evoluções na

ferramenta, desde que o novo código permaneça sendo livre seguindo essa licença.
A Oracle (2017), define que dentre as características do MySQL, as mais importantes

são: a portabilidade, a segurança, a escalabilidade e as ferramentas. O software foi escrito em
C e C++ e tem suporte a uma grande variedade de plataformas e compiladores. Possui módulos
de interface para diversas linguagens, tais como PHP, Ruby, Python, Java, entre outras. Para
segurança, possui sistema de privilégios e senhas muito flexível e seguro, oferecendo
criptografia para todo o tráfego realizado no servidor. Em se tratando de escalabilidade, pode
30
suportar grande volume de dados, equivalentes a terabytes, possibilitando diversos tipos de

armazenamento, onde cada um tem suas próprias características. Possui diversas ferramentas
de suporte interno para instruções SQL para verificar, otimizar e reparar tabelas.
3.6 Servidor HTTP
Conforme definido pela RFC 2616 por Fielding et al. (1999), Hypertext Transfer
Protocol (HTTP) é um protocolo do nível de aplicação para sistemas de informação de
hipermídia, distribuídos e colaborativos. Permite um conjunto aberto de métodos e cabeçalhos
que indicam o propósito de uma requisição.
Um servidor web pode-se referir a hardware ou software, ambos trabalhando juntos. Do
lado do hardware, um servidor web é um computador que armazena os arquivos de uma
aplicação e os entrega ao usuário final. Do lado do software o servidor web é responsável por
controlar como os usuários acessam os arquivos, através de um servidor HTTP. A Figura 4
ilustra a comunicação entre o cliente e o servidor. (MOZILLA DEVELOPER NETWORK,
2017)
Figura 4 - Exemplo de requisição HTTP
Fonte: MOZILLA DEVELOPER NETWORK (2017)
Um servidor web se comunica com um navegador da Web usando o HTTP. O conteúdo

da maioria das páginas da web é no formato HTML, e pode ser estático (por exemplo, texto e
imagens) ou dinâmico (por exemplo, informações provindas de um banco de dados). Para
oferecer conteúdo dinâmico, os servidores web suportam linguagens de script do lado do
servidor para codificar a lógica de negócios na comunicação, como por exemplo, o PHP.
(NGINX, 2017)
31
3.6.1 Nginx
Nginx é um servidor HTTP de código aberto. Ele é conhecido por seu alto desempenho,
estabilidade, conjunto de recursos ricos, configuração simples e baixo consumo de recursos.
Ao contrário dos servidores tradicionais, o Nginx não depende de threads para processar
pedidos. Em vez disso, ele usa uma arquitetura muito mais escalável orientada a eventos
(assíncrona). Mesmo se você não necessite lidar com milhares de solicitações simultâneas, você
pode se beneficiar por seu baixo consumo de memória. (NGINX, 2017)
De acordo com a W3Techs (2017), site especializado em dados estatísticos de
tecnologias da web, o servidor Nginx compões uma fatia de 35,7% do mercado. Contudo, é
possível restringir esses dados somente aos sites mais visitados, segundo o ranking da Alexa.
Considerando apenas os 1.000 sites mais visitados, o Nginx conta com uma fatia 56,4% do
mercado, passando a ser o mais popular.
A sua performance e a popularidade de uso nos principais sites foram os fatores
determinando para definir o Nginx como o servidor HTTP padrão para este trabalho.
32
4 IMPLEMENTAÇÃO DOS MICROSERVIÇOS
O objetivo desta sessão é descrever e documentar a implementação dos serviços

necessários para o funcionamento do sistema, bem como as configurações e imagens utilizadas
para a criação containers, através da plataforma Docker. Cada serviço implementado possui seu
próprio container, com suas configurações essenciais. Conforme a documentação do Docker
(2017), um container é uma imagem leve, independente e executável de um software, que inclui
tudo o que é necessário para executá-lo.
As imagens são criadas a partir de um arquivo de definição chamado Dockerfile. O
arquivo contém instruções que devem ser usadas de acordo com os comandos pré-definidos
pelo Docker.
Cada microserviço tem sua API definida e exposta através da arquitetura REST. Seu
acesso é via protocolo HTTP. Como retorno de dados, foi definido a utilização de JSON, pois
é o modelo mais adequado devido as tecnologias utilizadas neste trabalho, como por exemplo
o JavaScript.
Para este trabalho, foram utilizados quatro microserviços, que serão descritos nos
próximos capítulos: AuthService, CompanyService, ClientService e OrderService.
Também é abordado a instalação do Kong API Gateway, bem como as configurações
necessárias para o funcionamento dos microserviços junto com o plugin de autenticação JWT.
4.1 Configuração dos containers
Cada serviço desenvolvido é executado em um container criado a partir de uma imagem

específica. Devido a todos os microserviços deste trabalho utilizarem a mesma estrutura,
tecnologias e recursos, o Dockerfile é igual para todos.
As imagens foram construídas com base na imagem do Alpine, versão 3.5. Conforme o
site oficial, Alpine (2017) é uma distribuição Linux independente, não comercial e de propósito
geral, projetada para usuários avançados que apreciam segurança e eficiência de recursos.
Possui seu próprio gerenciador de pacotes, requer uma instalação mínima de 130MB de
armazenamento e ocupa menos que 8MB de memória para execução de um container.
Seu minimalismo e eficiência tornam a imagem uma ótima escolha para criação de
containers para os microserviços do sistema proposto neste trabalho.
A imagem baseada no Alpine conta com a instalação do PHP, na versão 7, e as
bibliotecas básicas necessárias para funcionamento do framework Lumen. Na mesma imagem
33
foi incluído a instalação do servidor Nginx e também do supervidor, responsável por controlar
e monitorar os processos do sistema. É através deste controlador que os serviços do PHP e do
Nginx são iniciados e monitorados.
A Figura 5 representa o Dockerfile em uma versão simplificada, com os comandos
necessários para a construção da imagem para os microserviços, de acordo com as
características mencionadas anteriormente.
Figura 5 - Definição do arquivo Dockerfile para os microserviços
FROM alpine:3.5
MAINTAINER Anderson Barberini <anderson.aeb@gmail.com>
RUN apk --no-cache add \

php7 \
php7-pdo_mysql \
php7-json \
php7-dom \
php7-xml \
php7-mcrypt \
php7-curl \
php7-json \
php7-fpm \
php7-phar \
php7-openssl \
php7-mysqli \
php7-ctype \
php7-opcache \
php7-mbstring \
php7-posix \
nginx \
nginx-mod-http-headers-more \
supervisor \
curl
ADD conf/nginx/nginx.conf /etc/nginx/nginx.conf

ADD conf/php/conf.d /etc/php7/conf.d/
ADD conf/supervisord/supervisord.conf /etc/supervisord/
EXPOSE 80 443
CMD ["/bin/sh", "/start.sh"]
Fonte: Autor
Contudo, o banco de dados utilizado nos serviços é executado em um container

separado. Com isso, pode-se escalar somente a aplicação individualmente, mantendo a base de
dados em um único container, ou vice-versa.
34
Para aproveitar as vantagens oferecidas pela arquitetura de microserviços, cada serviço

possui seu próprio banco de dados. Essa abordagem mantém o baixo acoplamento entre os
serviços e evita a dependência entre eles.
Com os arquivos de definição criados, construir e executar um container na plataforma
Docker é relativamente simples e podem ser feitos através de dois comandos:
docker build –t client

docker run –p 8082:80 client
O comando build é responsável por gerar uma imagem a partir do arquivo Dockerfile
que está dentro do diretório client. O comando run é responsável por executar esta imagem.
Porém, executar esse processo para todos os serviços do sistema se torna um processo oneroso
e diminui a produtividade. Como solução para isso, foi utilizado um recurso do Docker
chamado Docker Compose.
Conforme a Docker (2017) descreve, o Docker Compose é uma ferramenta para definir
e executar aplicativos do Docker com vários containers. Utilizando um arquivo YAML, todos
os serviços são configurados e com um único comando todos eles são criados e iniciados.
A Figura 6 representa a definição do Docker Compose utilizado para o serviço de
clientes, abordado nas próximas sessões. Nela é possível identificar a configuração de dois
containers, um para o serviço e outro para o banco de dados.
Figura 6 - Docker Compose do serviço de clientes
client:
build: ./client-service/docker/api
image: client.service.api
depends_on:
- client_db
volumes:
- ./client-service/src:/var/www/client
ports:
- 8082:80
client_db:
image: mysql
ports:
- 3307:3306
environment:
- MYSQL_ROOT_PASSWORD=12345
volumes:
- ./data/client:/var/lib/mysql
Fonte: Autor
35
O serviço tem sua imagem gerada a partir do arquivo de definição Dockerfile no local
especificado pela propriedade build, e o outro container que usa a imagem oficial do MySQL.
Com um único comando, a imagem é construída e os containers iniciados:
docker-compose up -d
Com todos os serviços definidos, após executar o comando do docker-compose up, o

resultado é todos os containers rodando, conforme apresentado na Figura 7. Como já descrito
anteriormente, os quatro serviços, company, auth, cliente e order usam a mesma estrutura do
Docker. A figura também apresenta a API Gateway Kong, tratada no capítulo 4.6.
Figura 7 - Informações dos containers do Docker em execução
Fonte: Autor
4.2 Serviço de Autenticação
O serviço de autenticação, denominado AuthService, é responsável por manter e

gerenciar as credenciais dos usuários de todo o sistema, incluindo empresas, clientes e demais
níveis de acessos. É neste serviço que as funções para login e logout são realizadas, através da
criação e exclusão de credenciais na API Gateway.
4.2.1 Modelo Entidade - Relacionamento
O banco de dados do serviço de autenticação é constituído de três tabelas. Cada uma é

responsável por armazenar as credenciais de cada tipo de usuário que o sistema vai possuir.
A tabela auth_companies tem a função de guardar as credenciais das empresas que
utilizam o sistema. A tabela de auth_clients irá armazenar as credenciais dos clientes de uma
determinada empresa. E a tabela auth_partner é responsável por armazenar as credenciais de
36
parceiros e demais acessos necessários, com por exemplo a aplicação. Na Figura 8 é possível
visualizar esta estrutura.
Figura 8 - Modelo Entidade - Relacionamento do serviço de

autenticação
Fonte: Autor
Nota-se que as tabelas não possuem relação com entidades externas. É uma
característica dos microserviços, enfatizada por autores influentes na evolução desta
abordagem. Fowler (2017), cita em seu site, um comentário do Werner Vogels, CTO da
Amazon falando sobre esse aspecto. Ele define que o serviço deve encapsular os dados e ser
acessível somente através de uma interface publicada do serviço. Nenhum acesso direto ao
banco de dados é permitido fora do serviço e não há compartilhamento de dados entre os
serviços.
O próprio Fowler (2015), relatou essa abordagem, definindo que uma das principais
características dos microserviços é que cada serviço gerencia seu próprio banco de dados e
qualquer outro serviço deve passar pela API para chegar até ele. Esta característica é refletida
em todos os serviços implementados neste trabalho.
37
4.2.2 Serviços da API
O serviço de autenticação provê três funções básicas: login, logout e cadastro das
credenciais dos usuários, contendo o usuário e senha.
No processo de login, as credenciais são validadas de acordo com o tipo de usuário, ou
seja, se é cliente, empresa ou parceiro. Porém, o fluxo depende do Kong API Gateway, abordada
no capítulo 4.6. Cada usuário do sistema deve estar cadastrado no gateway, através de um
consumer - e após, persistido no banco de dados, através da coluna consumer_id - e com base
nas informações retornadas, um token é criado através das credenciais JWT geradas pelo Kong.
Um consumer pode ter várias credenciais JWT, cada uma correspondente a um token
cadastrado, ou seja, um usuário pode ter vários logins em diferentes dispositivos.
No processo de logout, as credenciais JWT geradas para um usuário são excluídas. Com
isso, quando um request chegar ao gateway, não será mais aceito, pois o token será inválido.
Os endereços expostos pela API de autenticação estão descritos na Tabela 1
Tabela 1 - Serviços expostos pela API de autenticação
Path Recurso HTTP Descrição

/api/v1/auth/login POST Executa o processo de login
/api/v1/auth/logout POST Executa o processo de logout
/api/v1/auth/clients POST Persiste as credenciais de um cliente
/api/v1/auth/companies POST Persiste as credenciais de uma empresa
Fonte: Autor
4.2.3 Diagrama de sequência
Conforme descrito na Tabela 1, existem dois fluxos que são responsáveis por persistir
as credenciais de um cliente ou empresa no banco de dados. Estes dois recursos são chamados
internamente por outros serviços, após o cadastro de um usuário, sem necessidade de passar
pelo Kong. Porém, os fluxos de login e logout dependem diretamente do gateway, visto que
todas as chamadas externas terão que passar por ele, conforme descrito na sessão 4.6. Na Figura
9 é representado através do diagrama de sequência o processo de login e logout.
38
Figura 9 - Diagrama de sequência do serviço de autenticação
Fonte: Autor
4.3 Serviço de Clientes
Este serviço, denominado ClientService é responsável por manter, atualizar e exibir os

clientes de uma determinada empresa. Todo cliente deve obrigatoriamente estar vinculado a
uma empresa.
4.3.1 Modelo Entidade – Relacionamento
O banco de dados para o ClientService é relativamente simples, contendo apenas uma

tabela para armazenar as informações pessoais de cada cliente. Também possui uma coluna,
company_id, que identifica a qual empresa o usuário pertence. A Figura 10 demonstra o modelo
entidade relacionamento para esta estrutura.
39
Figura 10 - Model Entidade - Relacionamento

do serviço de clientes
Fonte: Autor
Alguns serviços desta API são dependentes do token, que deve ser enviado junto com a
requisição. É em seu payload que é extraído a empresa que está requisitando o recurso. É o caso
do serviço para listar os clientes e também as estatísticas, pois para esses dois processos, é
necessário saber quem é a empresa para então saber quem são os clientes.
Os endereços expostos pela API de clientes estão listados na Tabela 2.
Tabela 2 - Serviços expostos pela API de clientes

/api/v1/clients GET Retorna os clientes de uma empresa
/api/v1/clients/:id GET Retorna um cliente específico
/api/v1/clients POST Cadastra um novo cliente de uma empresa
/api/v1/clients/:id PUT Atualiza um cliente específico
/api/v1/clientes/statistics GET Retorna estatísticas de clientes da empresa
Fonte: Autor
Os fluxos dos serviços expostos pela API de clientes, conforme já mencionado nos
capítulos anteriores, dependem do gateway, pois todas as requisições feitas por um usuário são
enviadas ao Kong. Apenas o fluxo de cadastro depende de outro serviço, que é o AuthService,
40
para o controle das credenciais. Essa comunicação ocorre internamente entre os microserviços,
conforme apresentado no diagrama de sequência apresentado na Figura 11. Para os demais
serviços da API, a comunicação é semelhante ao que ocorre com a busca de clientes: o usuário
solicita a requisição, o sistema envia para o gateway que chama o serviço e retorna as
informações.
Figura 11 - Diagrama de sequência do serviço de clientes.
Fonte: Autor
4.4 Serviço de Empresas
O serviço de empresas, denominado CompanyService é responsável por manter,

atualizar e exibir as informações de uma determinada empresa. Este serviço também guarda
informações sobre a plataforma que os clientes irão acessar, através de uma URL específica
definida por cada empresa.
O banco de dados do serviço de empresas é composto de apenas uma tabela, onde são
armazenadas as informações sobre a empresa e também configurações para a página acessada
pelos clientes. A Figura 12 demonstra o modelo entidade relacionamento para esta estrutura.
41
Figura 12 - Model Entidade -

Relacionamento do serviço de empresas
Fonte: Autor
A API de empresas compões três funções básicas, que são: cadastro, listagem e
atualização. Os endereços expostos por ela estão definidos na Tabela 3.
Tabela 3 - Serviços expostos pela API de empresas

/api/v1/companies GET Retorna as empresas cadastradas
/api/v1/companies/:id GET Retorna uma empresa específica
/api/v1/ companies POST Cadastra uma nova empresa
/api/v1/companies/:id PUT Atualiza uma empresa específica
Fonte: Autor
Os fluxos de mensagens do serviço de empresas é semelhante ao serviço de clientes,

definido pelo diagrama apresentado no capítulo 4.3.3. Todas as requisições são solicitadas ao
Kong e após enviadas para o CompanyService. A Figura 13 descreve através do diagrama de
sequência este fluxo.
42
Figura 13 - Diagrama de sequência do serviço de empresas
Fonte: Autor
4.5 Serviço de Pedidos
O serviço de pedidos, denominado OrderService é responsável por gerenciar os pedidos

dos clientes, sendo possível exibir informações detalhadas e também alterar o status de cada
pedido.
O banco de dados deste serviço é constituído de duas tabelas, orders e orders_items. A

tabela de orders tem como objetivo armazenar as informações básicas do pedido, como o
cliente, o status e o preço total. Já a orders_items guarda os produtos que compões determinada
ordem, possuindo informações de preço, quantidade e um campo para guardar o arquivo
utilizado para a impressão da arte gráfica, nomeado de file_name.
A coluna file_name é utilizada no momento em que um cliente realiza um pedido pelo
site, após criar a imagem para seu produto customizado. A arte é salva em uma pasta específica
e então a referência é armazenada neste campo, para ser utilizada em um próximo momento
pela empresa.
A estrutura descrita pode ser visualizada através do modelo entidade relacionamento,
representado pela Figura 14.
43
Figura 14 - Modelo Entidade - Relacionamento do serviço de pedidos
Fonte: Autor
Da mesma forma que a API de clientes, alguns serviços desta API também são
dependentes do token. Essa arquitetura é necessária pois é preciso saber quem está requisitando
o recurso. É o caso da listagem de pedidos. Se for uma empresa, lista todos os pedidos da
empresa, caso for um cliente, lista apenas os pedidos daquele cliente específico.
Os endereços expostos pela API de pedidos estão descritos na Tabela 4.
Tabela 4 - Serviços expostos pela API de pedidos

/api/v1/orders GET Retorna os pedidos de uma empresa ou cliente
/api/v1/orders POST Cadastra um novo pedido
/api/v1/orders/:id GET Retorna um pedido específico
/api/v1/orders/:id/items GET Retorna os itens de um pedido específico
/api/v1/orders/:id/status PUT Atualiza o status de um pedido específico
/api/v1/orders/statistics GET Estatísticas de pedidos de uma empresa
Fonte: Autor
44
O serviço de pedidos não depende de outros microserviços. As requisições enviadas ao

gateway são encaminhadas para o OrderService, que realiza as operações necessárias. A Figura
15 representa o diagrama de sequência deste serviço.
Figura 15 - Diagrama de sequência do serviço de pedidos
Fonte: Autor
4.6 Kong API Gateway
O Kong API Gateway é o ponto central de todas as requisições solicitadas ao sistema.

Todos os microserviços estão cadastrados em seu banco de dados, e a cada nova solicitação, o
Kong encaminha para o serviço relacionado. Dessa forma, é possível criar uma nova camada
de segurança, adicionando diversos recursos como a autenticação via JWT.
O gateway suporta dois tipos de SGBDs, o Cassandra e o Postgress. O Casandra é
bastante robusto e com isso tem um consumo de memória mais elevado que o Postgress. Por
esse motivo foi adotado o segundo como o padrão para o Kong.
Seu uso com o Docker é simples e depende de dois containers, um para rodar a aplicação
do Kong e outro para o banco de dados. A Figura 16 representa o Docker Compose para essa
estrutura.
45
Figura 16 - Docker Compose do Kong API Gateway
kong:
image: kong:0.10
depends_on:
- kong_db
ports:
- 8000:8000
- 8443:8443
- 8001:8001
environment:
- KONG_DATABASE=postgres
- KONG_PG_HOST=kong_db
- SERVICE_NAME=kong
kong_db:
image: postgres:9.4
ports:
- 5432:5432
environment:
- POSTGRES_USER=kong
- POSTGRES_DB=kong
- SERVICE_NAME=kong_db
volumes:
- kong_db:/var/lib/postgresql/data
Fonte: Autor
O funcionamento do Kong é basicamente definido por duas interfaces: uma para

administrador, responsável polo gerenciamento das APIs e demais funcionalidades do gateway
e outra para acesso aos serviços da aplicação.
É através da interface de administrador que são cadastrados os serviços e instalados os
plugins. Ela é disponibilizada através da porta 8001, para tráfego HTTP e na porta 8444 para
tráfego HTTPS. Por exemplo, o comando abaixo envia uma requisição para o Kong solicitando
o cadastro da API de clientes. O path de acesso é informado no parâmetro uris e o destino da
requisição no parâmetro upstream_url:
curl -i -X POST \
--url http://localhost:8001/apis/ \
--data 'name=clients' \
--data 'uris=/v1/clients' \
--data 'upstream_url=http://client/api/v1/clients'
É também pela interface de administrador que os plugins são instalados. Sua instalação
pode ser feita em uma API específica ou de âmbito global. Para este trabalho foram utilizados
dois plugins, um para autenticação via JWT e outro para o módulo CORS, responsável por
permitir que as APIs recebam solicitações de um domínio diferente. No caso, o primeiro é
utilizado individualmente, para cada API, e o segundo é global.
46
A instalação de um plugin é feita através de uma solicitação ao administrador do Kong,

informando o parâmetro name, que corresponde ao identificador do plugin, conforme
demonstrado no comando abaixo.
curl -i -X POST \
--url http://localhost:8001/apis/clients/plugins \
--data 'name=jwt'
Após rodar o comando acima, a API de clientes estará com o plugin do JWT instalado
e a partir disso, toda requisição deverá conter um cabeçalho informando o token de acesso. O
exemplo abaixo demonstra esse cabeçalho com um token real.
Authorization: Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIi
wiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
A interface de aplicação é mapeada através da porta 8000, para tráfego HTTP e na porta
8443, para tráfego HTTPS. Ao enviar uma requisição, deve-se informar qual é o serviço que
está sendo solicitado, para então, o gateway encaminhar a chamada ao destino. Porém, antes de
fazer este roteamento, os plugins instalados são executados, podendo assim, negar a requisição
antes mesmo de encaminhá-la ao destino. Um exemplo deste caso é o uso da autenticação por
JWT, onde se o sistema não informar o token de acesso, o gateway nega a requisição antes
mesmo de chegar ao serviço. Abaixo segue um exemplo de requisição para a interface da
aplicação, solicitando o serviço de clientes através do URI informado no cadastro da API:
curl -X GET http://localhost:8000/v1/clients
As APIs cadastradas no Gateway foram mapeadas de acordo com a Tabela 5.
Tabela 5 - Mapeamento das APIs no Kong API Gateway
Serviço URI Upstream URL

Autenticação /v1/auth http://auth/api/v1/auth
Empresas /v1/companies http://company/api/v1/companies
Clientes /v1/clientes http://client/api/v1/clients
Pedidos /v1/orders http://order/api/v1/orders
Fonte: Autor
47
5 DESENVOLVIMENTO DA APLICAÇÃO
Este capítulo apresenta as funcionalidades desenvolvidas para o painel administrativo e

também para a plataforma de customização. Também é descrito as delimitações de cada tipo de
usuário, empresa ou cliente e uma visão geral do funcionamento e comunicação de toda a
aplicação.
O nome escolhido para a aplicação foi Mogg. A escolha se baseou em dois fatores, uma
palavra de poucos caracteres e fácil de ser lembrada. Possui uma derivação da palavra mug,
termo em inglês que significa caneca, que é o produto alvo deste trabalho.
5.1 Descrição do sistema
O funcionamento do sistema é dividido em dois níveis de usuários: as empresas e os

clientes. A empresa possui a capacidade se cadastrar na aplicação e, através do painel
administrativo, gerenciar seus clientes, criar e atualizar pedidos e controlar algumas
configurações na plataforma. O cliente, ao acessar a plataforma da empresa, também tem a
possibilidade de se cadastrar e realizar novos pedidos, que após finalizados, estarão disponíveis
em sua área restrita. Tais capacidades estão representadas na Figura 17, que representa o caso
de uso geral da aplicação.
Figura 17 - Caso de uso geral da aplicação
Fonte: Autor
48
Quanto a arquitetura de microserviços, representado pela Figura 18, é possível visualizar

o fluxo de mensagens e todos os componentes envolvidos no sistema, que estão divididos em
três camadas: aplicação, API Gateway e serviços. É através da camada de aplicação que o
usuário interage com o sistema. Sua estrutura é composta de dois componentes, a plataforma
web e o painel administrativo. Para ter acesso às informações, as solicitações são encaminhadas
para a camada da API Gateway.
A segunda camada é a API Gateway. Ela é a porta de entrada para qualquer acesso aos
serviços, sendo responsável também pela segurança, caso protegido, negando o acesso a
usuários que não possuem token. O Gateway recebe as solicitações da camada anterior e envia
para o serviço destino, localizado na camada dos serviços. Os serviços protegidos estão
identificados na figura através da sigla JWT. Nota-se que o serviço AuthService não está
protegido, pois é através dele que o usuário se autentica para obter um token.
Na camada final estão os microserviços, cada um com seu banco de dados próprio. Para
ter acesso a qualquer informação no banco de dados, deve-se requisitar ao serviço responsável.
Uma característica importante é que os internamente, é possível estabelecer uma comunicação
entre os serviços, representados através das linhas de comunicação tracejadas, na Figura 18.
Figura 18 - Arquitetura de microserviços da aplicação
Fonte: Autor
5.2 Configuração dos containers
Diferente dos microserviços onde o container de cada serviço é executado através de

uma única imagem com o PHP e o Nginx, na aplicação são dois containers separados, um para
49
o PHP e outro para o Nginx. Essa abordagem foi arquitetada pois é a parte da aplicação onde
todas as requisições são resolvidas, então as possibilidades de escalabilidade ficam mais
amplas, dependendo da demanda.
Sendo assim, foi definido através do Docker Compose dois serviços que, na definição
do Dockerfile, utilizam as imagens oficiais do php:7-fpm e da última versão do Nginx. A Figura
19 representa o YAML desta estrutura.
Figura 19 - Docker Compose da aplicação
web:
build: ./docker/nginx
ports:
- 80:80
- 443:443
volumes:
- ./app:/var/www/app
-./panel:/var/www/panel
- ./docker/nginx/conf:/etc/nginx/conf.d
depends_on:
- app
app:
build: ./docker/php
volumes:
- ./app:/var/www/app
Fonte: Autor
5.3 Plataforma para customização
A plataforma para customização é composta de três módulos: uma página com conteúdo
sobre a empresa, uma área restrita do cliente, onde é possível visualizar os seus pedidos e a
ferramenta para personalizar produtos. Esta plataforma é oferecida pela empresa que se
cadastrou na Mogg através do endereço principal da aplicação, definido no endereço abaixo.
http://www.mogg.com.br
Ao realizar o cadastro, a empresa define um subdomínio para seus clientes utilizarem a

plataforma. Um exemplo para este endereço é a URL abaixo:
http://nivel1.mogg.com.br
As sessões a seguir apresentam a tela inicial da aplicação, o cadastro de empresas e os

três módulos da plataforma descritos anteriormente.
50
5.3.1 Página inicial
A página inicial da Mogg é composta de dois elementos importantes: um link para o

painel administrativo e um formulário para cadastro. Ao clicar no link ACESSAR O PAINEL,
o usuário é redirecionado para uma URL referente a esse sistema. Caso ainda não possuir conta,
é possível realizar o cadastro através do formulário, e após concluir, será redirecionado para a
página do painel. A Figura 20 apresenta a tela desta página.
Figura 20 - Mogg - Tela inicial
Fonte: Autor
5.3.2 Página da empresa
Ao aderir ao serviço, a empresa irá possuir uma página exclusiva, onde poderá incluir
um texto falando sobre ela. O nome que aparece no topo da página também é editável,
juntamente com o subdomínio usado na URL de acesso. A tela, conforme apresentado na
Figura 21, possui três menus: um para acesso a página inicial, outro para a plataforma de
customização e o último para a área restrita do cliente.
51
Figura 21 - Mogg - Tela inicial da empresa
Fonte: Autor
5.3.3 Área restrita do cliente
Os clientes da empresa dispões de uma área restrita para visualizar os pedidos

realizados, tanto por conta própria, através da ferramenta de personalização, como também as
que foram geradas através do painel administrativo pela empresa.
O acesso a este módulo é realizado mediante a identificação, através de um formulário
de autenticação, com usuário e senha. É possível também realizar um cadastro clicando no item
Quero criar minha conta localizado abaixo do login, conforme apresentado na Figura 22.
52
Figura 22 - Mogg - Tela de identificação para área restrita do cliente
Fonte: Autor
Um ponto importante é que todo cadastro fica vinculado a uma empresa específica.
Desse modo, o usuário pode ter cadastro em outras empresas, onde os dados não são
compartilhados. Este requisito é importante para manter de forma isolada os clientes que cada
empresa possui.
Após se autenticar ou se cadastrar, o usuário será enviado para a tela que ele solicitou
anteriormente. Um exemplo deste fluxo é o momento em que o cliente acessa a ferramenta da
empresa e é redirecionado para a autenticação. Após completar, volta para a página da
ferramenta já autenticado.
Acessando a área restrita, por meio do menu MINHA CONTA, é possível visualizar o
status de cada pedido e conferir qual o valor e data da compra. Esta tela está representada na
Figura 23.
53
Figura 23 - Mogg - Área restrita do cliente
Fonte: Autor
5.3.4 Ferramenta de personalização
O acesso a esta página é feito através do menu CRIAR localizado no topo da aplicação.
Porém, para visualizar seu conteúdo, é necessário estar autenticado como cliente, que foi
descrito no capítulo 5.3.3. Então, após se identificar, a tela de personalização é exibida. Nela o
cliente pode customizar apenas canecas, requisito para que o trabalho não ficasse tão extenso.
Ainda na tela, são exibidas informações sobre o preço, informado pela empresa, e o botão para
fechar o pedido, após o cliente estar satisfeito com seu produto. Após finalizar o pedido, o
usuário é redirecionado para a área restrita, onde são exibidas as últimas ordens realizadas.
Conforme apresentado na Figura 24 a ferramenta possui dois recursos principais: textos
e imagens. O cliente pode inserir diversos textos, com opções de mudar a fonte da letra e
também as cores. Quanto as imagens, é possível enviar fotos e ajusta-las conforme necessário.
Os dois tipos de elementos podem ser excluídos, rotacionados ou redimensionados de acordo
com a preferência.
54
Figura 24 - Mogg - Customização de produtos
Fonte: Autor
5.4 Painel administrativo
O painel administrativo é composto de três módulos: clientes, pedidos e configurações.

A empresa tem seu acesso através de uma página de autenticação, onde deve informar as
credenciais cadastradas no momento da adesão.
O acesso ao painel é feito através do botão ACESSAR PAINEL que se encontra na tela
inicial da aplicação, descrita no capítulo 5.3.1, ou informando diretamente a seguinte url:
http://panel.mogg.com.br
A tela inicial de autenticação é apresentada na Figura 25. Após o login, o usuário é

redirecionado para uma tela de dashboard, onde a empresa pode visualizar algumas estatísticas
como o a quantidade de clientes e pedidos e o valor total de vendas.
55
Figura 25 - Mogg - Autenticação do painel administrativo
Fonte: Autor
5.4.1 Módulo de clientes
Este módulo é responsável por manter os clientes da empresa. Nele, é possível visualizar
as informações de cada cliente e também alterar caso for necessário. A empresa tem a opção de
adicionar novos clientes, podendo assim, usar o sistema como um controle interno do negócio.
Na tela de clientes, apresentada na Figura 26, é exibido um datagrid listando os clientes
e as informações mais pertinentes, sendo o identificador, nome e-mail e telefone e os botões
para alterar ou incluir novos clientes.
Figura 26 - Mogg - Módulo de clientes do painel administrativo
Fonte: Autor
56
5.4.2 Módulo de pedidos
O módulo de pedidos é onde as empresas conseguem visualizar as ordens que foram

finalizadas pelos clientes e também com a possibilidade de incluir novos pedidos. Essa
flexibilidade permite as empresas um maior controle interno, já que essa mesma opção também
é disponibilizada na parte dos clientes.
Da mesma forma que o módulo de clientes, a tela inicial deste módulo é representada
por um datagrid listando as informações mais importantes do pedido, conforme pode-se
visualizar na Figura 27. Em cada linha, estão dispostos dois botões, sendo o primeiro para
alterar o status da ordem e o segundo para visualizar informações detalhadas do pedido.
Figura 27 - Mogg - Módulo de pedidos do painel administrativo
Fonte: Autor
Ao clicar no botão de detalhes, é exibido todas as informações da ordem, como o cliente,

data do pedido, o status atual e o valor total. Também são listados os produtos que compões o
pedido, conforme apresentado na Figura 28. Um ponto importante é o botão para baixar o
arquivo de impressão, localizado no produto da ordem, ao lado do Nome do item. Esse botão
é exibido para pedidos fechados pelo cliente através da plataforma, e a imagem gerada é salva
em um diretório e disponibilizada para a empresa baixar através deste botão. Essa imagem é
em alta resolução e já está em um formato pronto para a plotagem na caneca.
57
Figura 28 - Mogg - Detalhes de um pedido do painel administrativo
Fonte: Autor
5.4.3 Módulo de configurações
É através do módulo de configurações que a empresa informa algumas informações para

a plataforma, como o nome, um texto sobre a empresa e o preço do produto, que no caso é a
caneca. É possível também alterar o subdomínio de acesso, através do campo path. O módulo
é disponibilizado através do menu Configurações, conforme mostra a Figura 29.
Figura 29 - Mogg - Módulo de configurações do painel administrativo
Fonte: Autor
58
6 CONCLUSÃO E TRABALHOS FUTUROS
O desenvolvimento deste trabalho permitiu ao autor aprofundar seus conhecimentos

técnicos em diversas tecnologias e também conhecer novos frameworks, tendo sido de grande
valia para sua formação pessoal e profissional. O estudo e desenvolvimento da arquitetura de
microserviços proporcionou um avanço significativo nos conhecimentos de infraestrutura,
comunicação e modelagem de sistemas, pois foram aplicados paradigmas totalmente diferentes
dos usados nas aplicações convencionais.
A aplicação se mostrou muito promissora, pois permite a uma empresa ter um maior
controle interno e traz ao cliente um diferencial, permitindo que ele faça a customização
conforme sua criatividade. Outro fator importante é permitir a empresa estar no mercado online,
pois facilita a prospecção de novos clientes, que passam a conhecer a empresa através do site
na web.
A arquitetura de microserviços se mostrou muito eficiente, pois permite o isolamento
de cada serviço, e principalmente, manter a manutenção com essa característica se torna muito
mais produtivo, visto que o desenvolvedor não precisa necessariamente conhecer toda a
aplicação, logo aumentar a equipe se torna muito mais fácil. Outra grande vantagem foi que
devido a essa abordagem, escalar serviços para manter a disponibilidade é uma tarefa fácil e
gera menos custos. Exemplo disto é se caso o serviço de pedidos venha a ter problemas de
demora nas repostas, é possível escalar mais containers para ele, mantendo assim o restante do
sistema sem alteração.
Um fato que chamou a atenção foi o consumo de memória do banco de dados MySQL.
Como a API Gateway Kong funciona com o PostgreSQL, foi possível comparar o consumo
entre eles. Notou-se que o MySQL consome muito mais memória do que o PostgreSQL, que
numa arquitetura onde cada serviço tem seu próprio banco é um fator importante a se
considerar. Visto este cenário, possivelmente o banco de dados será migrado para o
PostgreSQL.
Com uma estrutura escalável e disponível e uma aplicação promissora, foram
considerados diversos trabalhos futuros a serem implementados, que vão oferecer ao sistema
mais eficiência para atender as necessidades das empresas. A primeira delas é incrementar as
ferramentas e opções utilizadas na personalização de produtos, como galeria de imagens, filtros,
e mais opções para textos. Aprimorando a ferramenta, o próximo passo é aumentar as opções
de produtos, não limitando somente a canecas. Este será um novo serviço a ser desenvolvido
59
além de um novo módulo no painel administrativo para a empresa gerenciar todos os produtos
disponíveis para personalização.
Entre os trabalhos futuros também está a criação de um serviço de e-mail para enviar
aos clientes e empresas mensagens de boas-vindas, pedidos realizados, status de pedidos, entre
outros. Em complemento, permitir a empresa mais opções de apresentar aos seus clientes seus
serviços, através de banners, novas páginas, galeria de trabalhos, entre outros.
60
REFERÊNCIAS
ALVAREZ, Miguel. Introdução a CSS3, 2008. Disponível em:

<http://www.criarweb.com/artigos/introducao-a-css3.html>. Acesso em: 18 mai. 2017.
ANITA. What Are Microservices?, 2016. Disponível em:

<https://www.weave.works/blog/what-are-microservices>. Acesso em: 30 mai. 2017.
APLINE. About Apline Linux. Disponível em: <https://alpinelinux.org/about>. Acesso em:

31 out. 2017.
BARNES, Eric. Announcing Lumen, 2016. Disponível em <https://laravel-

news.com/lumen>. Acesso em: 28 mai. 2017.
BEAN, MARTIN. Laravel 5 Essentials: Explore the fundamentals of Laravel, one of the
most expressive and robust PHP frameworks available. Birmingham: Packt Publishing Ltd.,
2015.
CLARK, Jack; Google: ‘EVERYTHING at Google runs in a container’, 2014. Disponível

em: <https://www.theregister.co.uk/2014/05/23/google_containerization_two_billion>.
Acesso em: 14 mai. 2017.
DALL’OGLIO, Pablo. PHP Programando com Orientação a Objetos. 3. Ed. Novatec,

2015.
DATE, C. J. Introdução à Sistema de Banco de Dados. Elsevier Editora, 2004
DIEDRICH, Cristiano. O que é Docker, 2015. Disponível em:

<http://www.mundodocker.com.br/o-que-e-docker>. Acesso em: 30 out. 2017
DOCKER. What is Docker. Disponível em: <https://www.docker.com/what-docker>.

Acesso em: 30 mai. 2017.
______. What is a Container. Disponível em: <https://www.docker.com/what-container>.

Acesso em: 31 out. 2017.
______. Overview of Docker Compose. Disponível em:

<https://docs.docker.com/compose/overview>. Acesso em: 1 nov. 2017.
DONDA, Daniel. O que são containers?, 2015. Disponível em

<http://mcsesolution.com.br/blog/2015/11/15/containers/>. Acesso em: 30 mai. 2017.
EIS, Diego; FERREIRA, Elcio. HTML5 e CSS 3 - Com Farinha e Pimenta. São Paulo:
Tableless, 2012.
FIELDING, Roy Thomas. Architectural styles and the design of networked-based

software architectures. Dissertação de Doutorado, University of California, Irvine (2000)
61
FIELDING Roy Thomas et al. Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, 1999.
Disponível em: <https://www.ietf.org/rfc/rfc2616.txt>. Acesso em: 04 nov. 2017.
FILIPOVA, Olga. Learning Vue.js 2. Packt Publishing Ltd, 2016.
FLANAGAN, David. JavaScript: The Definitive Guide, Sixth Edition. O'Reilly Media,
2011.
FONSECA, Marina. 10 máquinas para abrir um negócio em casa a partir de 630 reais,
2017. Acesso em: 11 abr. 2017. Disponível em: <https://exame.abril.com.br/pme/10-maquinas-
para-abrir-um-negocio-em-casa-a-partir-de-630-reais>.
FOWLER, Martin. Microservice Trade-Offs, 2015. Disponível em:

<https://martinfowler.com/articles/microservice-trade-offs.html>. Acesso em: 11 mai. 2017.
______. Microservices Resource Guide, 2017. Disponível em:

<https://martinfowler.com/microservices>. Acesso em 04 nov. 2017.
GILMORE, W. Jason. Dominando PHP e MySQL: do iniciante ao profissional. Rio de

Janeiro: Alta Books, 2008.
JWT, Introduction to JSON Web Tokens. <https://jwt.io/introduction/>. Acesso em: 16

mai. 2017.
KONG, What is Kong. Disponível em: <https://getkong.org/about>. Acesso em: 16 mai.

2017.
LARAVEL, About Laravel. Disponível em <https://github.com/laravel/laravel>. Acesso em:

28 mai. 2017.
LEWIS, James; FOWLER, Martin. Microservices, 2014. Disponível em:

<https://martinfowler.com/articles/microservices.html>. Acesso em: 10 mai. 2017.
LOENERT, Laura. Estratégias de autenticação em sistemas de microserviços, 2016.

Disponível em: <http://blog.rivendel.com.br/2016/12/12/estrategias-de-autenticacao-em-
sistemas-de-microservicos>. Acesso em: 30 out. 2017.
LUMEN. Lumen. Disponível em <https://lumen.laravel.com>. Acesso em: 28 mai. 2017.
MALAVASI, Eike. API Gateway governando a arquitetura de Microservices, 2016.

Disponível em: <https://sensedia.com/blog/apis/api-gateway-governando-a-arquitetura-de-
microservices>. Acesso em: 30 out. 2017.
MOUAT, Adrian. Using Docker: Developing and Deploying Software with Containers. First
Edition. O'Reilly Media, 2015.
MOZILLA DEVELOPER NETWORK, Introdução – JavaScript. Disponível em:

<https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Guide/Introduction>. Acesso em:
19 mai. 2017.
62
______. What is a web server?. Disponível em: <https://developer.mozilla.org/en-

US/docs/Learn/Common_questions/What_is_a_web_server>. Acesso em: 30 mai. 2017.
NEWMAN, Sam. Building Microservices: Designing Fine-grained Systems. First Edition.

O'Reilly Media, 2015.
NGINX. Fast and scalable web serving. Disponível em:

<https://www.nginx.com/resources/wiki>. Acesso em: 30 mai. 2017.
______. What is a Web Server?. Disponível em:

<https://www.nginx.com/resources/glossary/web-server/>. Acesso em: 30 mai. 2017.
ORACLE. What is MySQL?. Disponível em:

<https://dev.mysql.com/doc/refman/5.7/en/what-is-mysql.html>. Acesso em: 30 mai. 2017.
PEGN TV. Máquina que customiza tecidos é opção para quem trabalha em casa, 2016.
Disponível em <http://g1.globo.com/economia/pme/pequenas-empresas-grandes-
negocios/noticia/2016/12/maquina-que-customiza-tecidos-e-opcao-para-quem-trabalha-em-
casa.html>. Acesso em: 11 abr. 2017.
PHP, O que é o PHP?. Disponível em <https://secure.php.net/manual/pt_BR/intro-

whatis.php>. Acesso em: 28 mai. 2017.
RABELO, Eduardo. A evolução do CSS: De arquivos CSS, SASS, BEM para CSS
Modules até Styled Components, 2017. Disponível em: <https://medium.com/tableless/a-
evolu%C3%A7%C3%A3o-do-css-de-arquivos-css-sass-bem-para-css-modules-at%C3%A9-
styled-components-b7ad4d16ffc2>. Acesso em: 18 mai. 2017.
REDMOND, Paul. Lumen Programming Guide: Writing PHP Microservices, REST and
Web Service APIs. Apress, 2016.
RICARDO, José. Introdução ao MySQL. Disponível em:

<http://www.devmedia.com.br/introducao-ao-mysql/27799>. Acesso em: 30 mai. 2017.
RICHARDSON, Chris; SMITH, Floyd. Microservices: From Design to Deployment, 2016.

Disponível em: <https://www.nginx.com/blog/microservices-from-design-to-deployment-
ebook-nginx>. Acesso em: 16 mai. 2017.
RODRIGUEZ, Alex. RESTful Web services: The basics, 2015. Disponível em:
<https://www.ibm.com/developerworks/library/ws-restful/>. Acesso em: 15 mai. 2017.
SILBERCHATZ, Abraham; KORTH, F. H.; SUDARSHAN S. Database System Concepts.

6. Ed. McGraw-Hill Education, 2010.
SILVA, Maurício Samy. HTML5 - 2ª Edição: A linguagem de marcação que

revolucionou a web. 2. ed. São Paulo: Novatec, 2014.
SILVA, Maurício Samy. Desenvolva aplicações web profissionais com uso dos poderosos
recursos de estilização das CSS3. 1. ed. São Paulo: Novatec. 2011.
63
VUE. Getting Started. Disponível em: <https://012.vuejs.org/guide>. Acesso em: 30 out.

2017.
W3C. HTML & CSS. Disponível em: <https://www.w3.org/standards/webdesign/htmlcss>.

Acesso em: 30 out. 2017.
W3TECHS. Usage of web servers broken down by ranking. Disponível em:

<http://w3techs.com/technologies/cross/web_server/ranking>. Acesso em: 31 out. 2017.
64
APÊNDICE A – DOCUMENTAÇÃO DA API

Plataforma Web para Criação de Produtos Customizados Utilizando Arquitetura de Microserviços Com Docker

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Plataforma Web para Criação de Produtos Customizados Utilizando Arquitetura de Microserviços Com Docker

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE REGIONAL INTEGRADA DO ALTO URUGUAI E DAS MISSÕES

ANDERSON EDUARDO BARBERINI

PLATAFORMA WEB PARA CRIAÇÃO DE PRODUTOS CUSTOMIZADOS

PLATAFORMA WEB PARA CRIAÇÃO DE PRODUTOS CUSTOMIZADOS

Trabalho de conclusão de curso,

Orientador: Marcos A. Lucas

O objetivo deste trabalho é implementar uma arquitetura de microserviços utilizando a

Palavras-chave: Arquitetura de microserviços. Containers. Docker. API REST. Plataforma

The objective of this paper is to implement a microservice architecture using container

Figura 1 - Arquitetura monolítica vs. arquitetura de microserviços ......................................... 13

Tabela 1 - Serviços expostos pela API de autenticação ........................................................... 37

API - Application Programming Interface

O segmento de produtos customizados cresce a cada dia. O desejo de se diferenciar das

Além disso, conforme a repórter Fonseca (2017), a Feira do Empreendedor, organizada

imagens e textos. Por fim, através de um formulário de autenticação ou de cadastro, o cliente

Neste capítulo serão apresentadas as principais tecnologias que foram utilizadas na

Atualmente, o modelo natural de desenvolvimento de sistemas é baseado em uma

Figura 1 - Arquitetura monolítica vs. arquitetura de microserviços

Fonte: ANITA (2016)

 Resiliência, pois se um componente do sistema falhar, pode-se isolar o problema e

 Alinhamento organizacional, pois permite trabalhar com equipes distribuídas, de

 Composição, que aborda o conceito de reutilização das funcionalidades. Isso é

 Otimização para substituição, pois permite uma maior facilidade de substituir um

Contudo, uma arquitetura baseada em microserviços introduz uma certa complexidade

 Distribuição: performance é a primeira. Quando um serviço precisa realizar diversas

 Consistência Eventual: a gestão descentralizada de dados dos microserviços pode

 Complexidade Operacional: Não há maneira fácil de lidar com dezenas de serviços

Containers estão revolucionando a forma de desenvolver, distribuir e executar

Figura 2 - Diferença entre máquinas virtuais e containers

Fonte: DONDA (2015)

Para Mouat (2015), as principais vantagens dos containers são:

 Compartilham os recursos com o sistema operacional host, o que os torna mais

 A portabilidade dos containers elimina vários problemas causados por mudanças

Docker é a principal plataforma de container de software do mundo. O Docker

Segundo Fielding (2000), Representational State Transfer, ou simplesmente REST,

2.4 API Gateway

Uma API Gateway é um único ponto de entrada de um sistema e é responsável pelo

Figura 3 - Exemplo de uma API Gateway em uma arquitetura de microserviços

Fonte: (RICHARDSON; SMITH, 2016)

2.4.1 Kong API Gateway

2.5 Autenticação e autorização

Autenticação e autorização são conceitos fundamentais quando se trata de pessoas e

 Autocontido, pois a carga contém todas as informações necessárias sobre o usuário,

O resultado da signature é o token, que terá uma estrutura semelhante ao exemplo

Neste capítulo serão apresentadas as principais tecnologias utilizadas para o

Em outubro de 2006, Tim Berners-Lee anunciou que trabalharia juntamente com o

 Server-side: Usado para aplicação do lado do servidor. Fornece objetos relevantes a

VueJS é uma biblioteca para construção de interfaces web interativas. Também é

 Praticidade: a linguagem que permite ao usuário construir aplicações poderosas

$randomString = substr(md5(microtime()), 0, 5);

 Poder: os desenvolvedores PHP têm mais de 180 bibliotecas à disposição, que ao

 Possibilidade: desenvolvedores PHP raramente estão atrelados a uma única solução

 Preço: PHP é uma linguagem open source e é disponibilizada gratuitamente.

Laravel é um framework PHP para desenvolvimento aplicações web, com sintaxe

A Laravel reutiliza e monta os componentes existentes visando proporcionar uma

 Modularidade: Laravel foi construído em cima de mais de 20 bibliotecas diferentes

 Testabilidade: o framework foi desenvolvido para facilitar os testes,

 Roteamento: permite muita flexibilidade para definir as rotas da aplicação.

 Gerenciamento de configuração: oferece um suporte para criar configurações

 Banco de dados: Laravel vem com um conjunto de ferramentas que possibilitam

 Autenticação: o framework vem com uma estrutura pronta para implementação de

Lumen é um micro framework baseado em Laravel incrivelmente rápido. É uma ótima