Full Stack: O que são Microserviços e Microfrontend?

Full Stack: O que são Microserviços e Microfrontend?

19 de outubro de 2019 0 Por Ramos de Souza Janones
Powered by Rock Convert

Entenda com exemplos o que são Microserviços e microfrontends e a importância cada vez maior de desenvolvedores Full Stack.

O que seria Microfrontend?

Resumindo bastante e sabendo o que são web components, cada componente da UI, pode ser um projeto separado, com suas próprias dependências, estrutura e equipe de desenvolvedores

Que problemas ele resolve (ou não resolve)?

Até resolve algumas situações muito específicas, mas trás diversos outros problemas consigo. Então deve ser analisado bem o contexto antes de adotar.

Quais são os prós e contras?

Se você tem uma interface que é montada a partir de diversos projetos…

  • Há um acúmulo de dependências, boa parte podendo ser apenas uma pequena mudança da versão ou diferentes bibliotecas com a mesma função (por exemplo, uma mesma tela ter que carregar o Vue e o React)
  • Você precisa gerenciar estado entre os projetos, o que provavelmente adicionará mais uma dependência
  • Você não deveria ter variáveis globais entre todos os projetos, afinal, cada projeto deve ser desacoplado dos demais
  • Tudo isso implica maior complexidade

Mas ela ajuda em alguma coisa…

  • Permite o uso de diferentes bibliotecas numa mesma aplicação (no caso um site e não um projeto)
  • Apesar de aumentar a complexidade do todo, simplifica as suas partes, pois divide aquele monstro em projetos menores

Possíveis casos de uso:

  • Permite a migração da biblioteca/framework principal (ou apenas versão do mesmo) aos poucos, você pode indo um componente de cada vez
  • Em aplicações muito grandes, pode se dividir melhor o projeto e as suas respectivas equipes, desacoplando as partes

Observações para os casos de uso, respectivamente:

  • Se o processo de migração for rápido, provavelmente não valha apena a adição dessa complexidade temporária
  • A divisão do projeto pode ser feita através de diferentes aplicação sem o uso microfrontend, desde que usem a mesma biblioteca/framework principal ou que as dependências em comum possuam suporte para todas. Por exemplo, posso ter uma aplicação em rh.app.com feita em Vue e finaceiro.app.com feita com Angular, ambas usando Ionic

Outras observações

  • No momento dessa resposta, diria que o microfrontend ainda está engatinhando, então não há tantos materiais e ainda não estão bem desenvolvidos
  • Apesar de permitir que você crie uma tela com diversos projetos, é bom evitar, principalmente quando há muitas dependências diferentes entre eles
  • Se sua aplicação é de médio ou pequeno porte não use, precisa de um motivo muito forte mesmo para que faça sentido o seu uso
  • Neste Podcast, é discutido sobre o problema de ter muitas dependências, uma das soluções é combinar com a(s) equipe(s) para usar o máximo de dependências comuns e, quando for atualizar, todos atualizarem juntos, mas isso faz pouco sentido, já que praticamente acaba com as vantagens
  • Para evitar duplicação de dependências, ou seja, múltiplos projetos carregam as mesmas coisas, as mesmas devem ser carregadas por um gerenciador global (acima do projeto), ele verificará se é mesmo necessário carrega-la. A princípio não vejo nenhum porém nisso, exceto é claro, o aumento de complexidade

Veja um demo de uma solução misturando diversas tecnologias aqui: https://single-spa.surge.sh

Em um resumo mais direto:Micro Frontends é uma técnica que surgiu para lidar com a complexidade de grandes projetos de frontend, onde em um mesmo sistema podemos mesclar diferentes tecnologias de front-end (Angular, AngularJS, React, Vue, etc), mantendo deploy e manutenção independentes.

Exemplos ilustrados

Para melhor compreensão, seguem exemplos ilustrados.

Para ilustrar uma arquitetura comum, temos abaixo um frontend monolítico:

Leia também:  

Com a introdução do Micro Frontend na aplicação, ela pode ser trabalhada da seguinte maneira:

Aqui há um outro exemplo ilustrando como diferentes times poderiam participar do desenvolvimento, de forma independente, na mesma tela:

Como dito anteriormente, a tela pode ser segmentada em diferentes partes, misturando as tecnologias. No exemplo acima temos a área circulada em vermelho em Angular, a circulada em azul usa ReactJS e a circulada em verde foi feita com Vue.js.

Até pouco tempo atrás não existiam soluções bem difundidas sobre como resolver este problema. O assunto popularizou-se e ganhou bastante dimensão após a Thoughworks e Martin Fowler explorar mais o assunto, tanto que as principais referências ao assunto na Internet estão ligados a eles.

O que são microserviços ou microservices?

O objetivo principal de usar micro serviços (ou microservices) é ajudar o time de engenharia a entregar produtos mais rápido, de maneira mais segura e com qualidade mais alta. Pequenos serviços desacoplados permitem que os times tenham ciclos de desenvolvimento (sprints ou iterações) rápidos e com mínimo impacto ao resto do sistema.

Um micro serviço é uma pequena porção de software que roda de maneira independente, focada em um único e pequeno (daí o nome micro) conjunto de atividades dentro de um conjunto de serviços muito maior, formando uma arquitetura de micro serviços. Resumidamente é uma versão mais enxuta de web services e web APIs que tradicionalmente os desenvolvedores já faziam há anos.

Em uma arquitetura de micro serviços, múltiplos serviços fracamente acoplados (ou seja, com poucas ou nenhuma dependência entre si) trabalham juntos. Cada serviço foca em um único propósito e tem uma alta coesão (congruência, coerência) de comportamentos e dados relacionados. Note que esta última definição inclui três princípios básicos do design de micro serviços, que vamos ver a seguir.

Os três princípios do design de micro serviços

Quando estamos trabalhando em sistemas que usam a arquitetura de micro serviços devemos sempre ter em mente três princípios básicos.

Propósito Único: cada serviço deve focar em um único propósito e fazê-lo bem. Esta é regra é muito semelhante com o Single Responsibility Principle do acrônimo SOLID, muito utilizado em orientação à objetos.

Assim como o SRP do SOLID diz que uma classe Aluno deve se focar apenas em atender às necessidades de um aluno, o princípio do Propósito Único diz que um micro serviço ‘/alunos’ deve se focar apenas em realizar operações sobre alunos. Precisa lidar com questões financeiras do aluno? Crie outro micro serviço para focar nisso. Precisa fazer uma matrícula, onde tem de lidar com o aluno e com questões financeiras? Crie um terceiro micro-serviço que vai chamar os dois anteriores.

Garantir que cada micro serviço tenha um propósito único não é tão fácil e simples, mas é uma das dicas essenciais principalmente quando você está refatorando uma aplicação monolítica em micro serviços.

Baixo Acoplamento:  cada serviço não deve saber nada ou muito pouco dos outros serviços. Eles não devem compartilhar bibliotecas de código, ou apenas o que for genérico e essencial para ter o mínimo de código repetido. Eles devem ter suas próprias validações, seus próprios testes unitários e inclusive não precisam compartilhar sequer a mesma tecnologia ou o mesmo mecanismo de persistência.

Isso tudo para que uma mudança em um serviço não exija mudar outros serviços. Ou que um bug inserido no desenvolvimento de um serviço não atinja o código de outros também. Inclusive a comunicação entre serviços deve ser feita através de interfaces públicas e protocolos leves, funcionando em processos separados.

Curso completo de Games, inclusive Realidade Aumentada.Powered by Rock Convert

Este também é um princípio herdado da Orientação à Objetos, onde trabalhamos Loose Coupling ou Low Coupling dentro dos design patterns como sendo um objetivo desejável para garantir boas arquiteturas, muito mencionado no clássico Padrões de Arquitetura de Aplicações Corporativas, do Martin Fowler.

Alta Coesão: cada serviço encapsula todos os comportamentos e dados relacionados juntos. Isso garante que se precisarmos construir uma nova feature sobre um mesmo domínio ou propósito, todas as mudanças devem ser localizadas em um único serviço.

Note que o próprio princípio do Propósito ou Responsabilidade Única dá os subsídios necessários para garantir uma alta coesão, outro tema bem forte nos design patterns da orientação à objetos.

No gráfico abaixo, extraído da Internet, temos a relação entre estes três princípios e como eles se interseccionam para gerar a base desejada para a construção de micro serviços que atendem ao padrão deste tipo de arquitetura.

O que não é um micro serviço?

Muitas vezes fica mais fácil de entender o que algo é quando definimos o que ele não é, certo?

Um micro serviço não é um serviço que tem um número pequeno de linhas de código ou que faz ‘micro tarefas’. 

Esta confusão vem do próprio nome, mas não é uma regra e nem é o objetivo desta arquitetura. Os serviços devem possuir a complexidade e quantidade de linhas de código necessárias desde que atendam os três princípios anteriormente descritos.

Um micro serviço não é um serviço construído com a tecnologia mais bacana e hipster que o mercado oferece no momento. 

Embora a arquitetura de micro serviços te permita sim testar novas tecnologias de maneira muito rápida e fácil, não é um objetivo primário desta arquitetura. Está completamente ok usar qualquer tecnologia que atenda aos princípios anteriores e não faz sentido algum refatorar todos seus micro serviços cada vez que uma nova stack aparece no mercado.

Um micro serviço não tem de ser sempre programado do zero. 

Quando você está iniciando um processo de refatoração de uma aplicação monolítica, é muito comum que você extraia códigos da aplicação original para os micro serviços e não há problema algum nisso, desde que respeite os três princípios.

Com este paradigma, cada vez mais o mercado procura por desenvolvedores FullStalck

O que é um desenvolvedores FullStalck?

Pegando o gancho do site TutanoTrampos:

Paulo Barroso, CEO da agência full service namBBU, define que o Desenvolvedor Full Stack atua em back-end (servidor, banco de dados, modelagem, programação, estruturação de dados e implementação) e front-end (interface, UX, corte).

Com isso, a gama de conhecimento é bastante variada. Medina enumera: “Tem que sujar as mãos em todas as camadas, usar o terminal, saber de servidor, entender como funciona a nuvem, saber montar uma boa base de dados, de versionamento, de cacheamento e ser craque na produção de peças digitais.

Ou seja: até com o Photoshop, para uma correta construção de biblioteca de assets, o Full Stack deve se virar bem”.

QUANTO GANHA UM DESENVOLVEDOR FULL STACK?

Conforme os dados de oportunidades em que a faixa salarial foi divulgada no trampos.co, os salários para desenvolvedores  Full Stack variam de R$ 4.500 a R$ 12.000. Estágios na área podem chegar a R$ 2.500. Em grandes empresas nacionais e internacionais, profissionais de nível Sênior podem receber remunerações de até R$25.000.  

PERFIL E CARACTERÍSTICAS DO PROFISSIONAL FULL STACK

Para Medina, esse profissional FullStack tem que estar atento às mais recentes práticas de toda a cadeia de desenvolvimento. “Procuro sempre por profissionais comprometidos com a promoção do próprio conhecimento. Uma pessoa em constante adaptação aos cenários mais diversos e que encontre alternativas a qualquer bomba que se jogue na mão dele”, explica. Gumieri acrescenta que a lógica de programação é importante para garantir entrega independente de ferramenta, library ou linguagem.

Por isso, os recrutadores costumam avaliar no momento da contratação de novos colaboradores a já citada multidisciplinaridade e a capacidade de entender os processos de maneira integral. Somos autodidatas, somos criativos, somos interessados em ir além da sala de aula para produzir mais riqueza do que conhecimento acadêmico. Felipe Medina

COMO TORNAR UM DESENVOLVEDOR FULL STACK?

Nós, Ramos da Informática, recomendamos a Formação da Danki Code que é o mais completo do mercado  para a formação de desenvolvedores  Full Stack. Claro que há diversas opções de formação, mas este além de completo é constantemente atualizado com o mercado nacional e internacional.

VOCÊ ESTÁ EM  » MundoJS

 

React Native Do Zero Ao Profissional: crie apps para Android e IOSPowered by Rock Convert
Siga os bons!

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.




Frontend Do Zero Ao Profissional