Critérios para uma escolha adequada de uma stack front-end

Critérios para uma escolha adequada de uma stack front-end

009048ba3b1535aa65e3e7bdb232e513?s=128

Samuel Martins

October 31, 2019
Tweet

Transcript

  1. 3.

    ‣ TechLead na Take; ‣ Formado em Sistemas de Informação

    pela PUC Minas; ‣ Pós-graduado em Arquitetura de Software Distribuído na PUC Minas; ‣ Professor de pós-graduação na PUC Minas no curso de Desenvolvimento web Fullstack; SAMUEL MARTINS
  2. 5.
  3. 11.

    O QUE FAZER DIANTE DESSE CENÁRIO? Não é possível ser

    especialista em tudo, certo? Então…
  4. 12.

    ESTABELEÇA CRITÉRIOS OBJETIVOS ‣ Performance; ‣ Disponibilidade; ‣ Tempo de

    carregamento; ‣ Bundle size; ‣ Segurança; ‣ Documentação; ‣ Custos; ‣ SEO; ‣ Maior hype… KEEP CALM AND
  5. 14.

    CONVERSE COM SEU TIME ‣ Analise as skills; ‣ Analise

    o background da equipe; ‣ Será necessário um treinamento? ‣ Metas de aprendizado; ‣ Foque nos critérios objetivos.
  6. 16.

    PROVAS DE CONCEITO (POC) ‣ Circuito mínimo de um projeto

    a ser avaliado e testado antes da construção do MVP; Fonte: Marco Mendes
  7. 17.

    CASO LINKEDIN LIGHTER THAN LIGHTWEIGHT: HOW WE BUILT THE SAME

    APP TWICE WITH PREACT AND GLIMMER.JS https://engineering.linkedin.com/blog/2018/03/how-we-built-the-same-app-twice-with-preact-and-glimmerjs
  8. 18.

    “This project first started with the goal of building a

    prototype that optimized for page load time at all costs, to help us calibrate what “theoretical maximum” performance looked like.”
  9. 20.

    CRITÉRIOS OBJETIVOS ADOTADOS ‣ First Meaningful Paint: tempo para o

    conteúdo principal da página aparecer pela primeira vez; ‣ Time to Interactive: mede quanto tempo leva para a aplicação responder de maneira confiável à interação do usuário.
  10. 23.

    Tom Dale CASO LINKEDIN “(...) SKIMPING ON ABSTRACTIONS AND INFRASTRUCTURE

    IN THE BEGINNING JUST MEANS PUSHING ADDITIONAL COMPLEXITY INTO THE APP ITSELF.”
  11. 30.

    ADOÇÃO DA COMUNIDADE ‣ Menor tempo para resolução de bugs;

    ‣ Evolução mais rápida; ‣ Maior quantidade de eventos e meetups; ‣ Melhor documentação e suporte.
  12. 31.

    CASO DE INSUCESSO (NANOCOMPONENTS) ‣ Projeto atendia todos os critérios

    objetivos propostos; ‣ Dentre todos os comparados, possuía o menor tamanho; ‣ Curva de aprendizado baixa; ‣ Ótimo benchmark; ‣ Funcionou exatamente como esperado nas POCs (provas de conceito).
  13. 32.

    CASO DE INSUCESSO (RESULTADO) ‣ Com o tempo, surgiram problemas

    cujas soluções não foram encontradas no StackOverflow; ‣ Mantenedores do projeto não corrigiam as issues abertas, sendo necessário um fork do projeto no GitHub e resolução dos problemas pelo próprio time; ‣ Comunidade pequena, apenas 333 stars no GitHub. Responsáveis pelo projeto não evoluíram mais o produto; ‣ Necessário traçar um caminho para refatorar o que foi feito e utilizar algo que fosse mantido pela comunidade.
  14. 38.
  15. 40.

    ANGULAR ARQUITETURA ▸ Pensado para o desenvolvimento de aplicações front-end

    de ponta-a-ponta; ▸ Setup inicial com tudo que é necessário para desenvolver uma aplicação moderna: ▸ Sistema de rotas; ▸ Arquitetura e organização de pastas bem definidas; ▸ Sugere o uso dos Services para consultas a APIs externas.
  16. 41.

    ANGULAR ARQUITETURA ▸ Utiliza, desde o início, uma linguagem tipada

    (typescript); ▸ Permite uma boa escalabilidade. Linguagem tipada tem se tornada essencial em grandes projetos; ▸ Desenvolvido para permitir o desenvolvedor focar na lógica de negócio.
  17. 42.

    ANGULAR ASPECTOS TÉCNICOS ▸ Permite uma associação à linguagens tipadas

    de back-end mais conhecidas (C#, Java…); ▸ Utilização do conceito conhecido de orientação a objetos. Ex.: um mesmo modelo definido na aplicação de back-end pode servir de base para um mesmo domínio no front-end; ▸ Boa opção para desenvolvimento de aplicações híbridas ou aplicações que possuem uma versão mobile devido a similaridade com o IONIC.
  18. 43.

    ANGULAR ASPECTOS TÉCNICOS ▸ angular-cli: utilitário de linha de comando

    para criação de partes da aplicação; ▸ Permite criar componentes, serviços, módulos e diretivas. ng generate component my-component ng g c my-component
  19. 44.

    ANGULAR COMUNIDADE E EVOLUÇÃO ▸ 53.5k stars no Github; ▸

    Conferência oficial anual para apresentação de novidades e evoluções do framework (NG-Conf); ▸ Possui bibliotecas de componentes para agilizar ainda mais o desenvolvimento das aplicações: ▸ Angular-material: https://material.angular.io/;
  20. 45.

    ANGULAR PONTOS DE ATENÇÃO ▸ Necessário mais linhas de código

    para escrita de uma aplicação; ▸ Curva de aprendizado pode ser alta para pessoas com backgrounds 100% front-end: ▸ Necessário aprender conceitos de orientação a objetos (Tipos, Heranças, Interfaces, Generics, Annotations/ Decorators); ▸ Necessário aprender a utilizar o angular-cli.
  21. 46.

    ANGULAR PONTOS DE ATENÇÃO ▸ Necessário o aprendizado de muitos

    conceitos core do framework ▸ Componentes; ▸ Diretivas; ▸ Módulos; ▸ Serviços; ▸ Programação reativa com RxJs (Observables, subscribers…); ▸ Injeção de dependências; ▸ HttpClient.
  22. 48.

    ANGULAR CASOS DE USO COMUNS ▸ Aplicações web corporativas (ERP,

    Dashboards…); ▸ Aplicações de grande porte em geral; ▸ Utilizada por times com mais conhecimento em linguagens server-side tipadas (Java, C#) e sem nenhum conhecimento em JavaScript.
  23. 50.

    VUE

  24. 52.

    VUE ARQUITETURA ‣ Focado 100% em componentes. Resumidamente, é um

    framework para criação de componentes web; ‣ Vue não é um framework para desenvolvimento de SPAs (Single Page Applications); ‣ É possível desenvolver SPAs instalando bibliotecas externas: ‣ Vue-router: possibilita o gerenciamento de rotas; ‣ Vuex: possibilita o gerenciamento de estados;
  25. 53.

    VUE ARQUITETURA ‣ Similaridade com o AngularJs; ‣ Possibilita a

    adoção incremental em um projeto já existente; ‣ TODO o código relacionado a um componente é escrito no mesmo arquivo.
  26. 54.
  27. 55.

    VUE ASPECTOS TÉCNICOS ‣ Possui um formato de arquivo próprio

    (.vue); ‣ Configuração inicial utiliza JavaScript “puro”; ‣ Permite a escrita de CSS com escopo de forma nativa; ‣ Permite a configuração da aplicação para aceitar a escrita dos componentes em TypeScript.
  28. 56.

    VUE COMUNIDADE E EVOULUÇÃO ‣ 151k stars no Github; ‣

    Possui um bibliotecas de componentes para agilizar o desenvolvimento das aplicações (ex.: https:// vuematerial.io/); ‣ Lista de projetos da comunidade para o Vue: https:// github.com/vuejs/awesome-vue; ‣ Eventos conhecidos: https://events.vuejs.org/conferences/;
  29. 57.

    VUE PONTOS DE ATENÇÃO ‣ Não possui nenhuma definição de

    arquitetura da aplicação (organização de pastas, por exemplo); ‣ Deixa sempre a cargo do desenvolvedor definir o seu próprio padrão de desenvolvimento; ‣ Arquivos dos componentes podem crescer exponencialmente. Por isso a necessidade de separar os componentes em partes mais pequenas o possível.
  30. 58.

    VUE CASOS DE USO COMUNS ‣ Desenvolvimento de bibliotecas de

    componentes cross- framework (Design systems, bibliotecas UI); ‣ Exemplo: https://github.com/takenet/blip-cards-vue- components. ‣ Componentização de aplicações já existentes; ‣ Criação de aplicações de pequeno porte.
  31. 59.

    VUE

  32. 61.
  33. 63.

    REACT ARQUITETURA ‣ Arquitetura 100% focada em componentes (no React,

    TUDO é um componente); ‣ Biblioteca concebida inicialmente para desenvolvimento de interfaces de usuário; ‣ Utiliza uma linguagem diferente, o JSX; ‣ Primeiro framework implementar o conceito de Virtual DOM; ‣ Nasceu focado em performance.
  34. 64.

    REACT ARQUITETURA ‣ Permite a integração com o TypeScript; ‣

    Permite a criação de aplicações SPA por meio de bibliotecas da comunidade (react-router, por exemplo); ‣ Permite a adoção incremental em projetos já existentes; ‣ Utiliza um paradigma de escrita de componentes diferente dos demais.
  35. 67.

    REACT ARQUITETURA ‣ Não possui mecanismo nativo para gerência de

    estados da aplicação; ‣ Possui como forte aliado o Redux, biblioteca da comunidade amplamente utilizada para gerenciamento de estados; ‣ Não possui conceitos além dos componentes. Não existe serviço, diretiva nem módulos.
  36. 68.

    REACT ASPECTOS TÉCNICOS ‣ Utiliza um dos melhores algoritmos de

    “reconciliação” de elementos DOM; ‣ Boa integração com outra linguagem tipada, o FlowTyped; ‣ Possui diversos caminhos para resolver o mesmo problema; ‣ Um componente pode ser escrito: ‣ Com funções; ‣ Com classes; ‣ Com funções + react hooks.
  37. 69.

    REACT ASPECTOS TÉCNICOS ‣ Utiliza vários conceitos da programação funcional;

    ‣ Componentes escritos como funções; ‣ Componentes não alteram valores fora do seu escopo (funções puras); ‣ Estados do componente são modificados atribuindo um novo valor, e nunca alterando diretamente (imutabilidade); ‣ Efeitos colaterais (chamadas em APIs, por exemplo), podem ser tratados de forma separa do restante do ciclo de vida (tratamento adequado de efeitos colaterais).
  38. 70.

    REACT ASPECTOS TÉCNICOS ‣ Possibilidade de utilizar o conceito de

    composição de funções nos componentes; ‣ Por ter os componentes escritos em funções, permite utilizar qualquer conceito conhecido relacionado a funções: ‣ Funções que retornam outros componentes; ‣ Funções que recebem parâmetros que e retornam componentes dinâmicos.
  39. 71.

    REACT COMUNIDADE E EVOLUÇÃO ‣ Possui a maior e melhor

    comunidade; ‣ 139k stars no GitHub; ‣ Constantemente em evolução; ‣ Evoluções, até então, foram tratadas de forma a manter uma maior retrocompatibilidade; ‣ Eventos conhecidos: https://reactconf.com.br/; ‣ TUDO já foi feito por alguém no StackOverflow.
  40. 76.

    REACT PONTOS DE ATENÇÃO ‣ Não possui estrutura de pastas

    e arquivos definidos; ‣ Mudança de mindset na criação dos componentes por conta da linguagem (jsx); ‣ Necessidade de instalação de pacotes adicionais para funcionar como um SPA.
  41. 77.

    REACT CASOS DE USO COMUNS ‣ Criação de bibliotecas de

    componentes (Design Systems, componentização de projetos existentes); ‣ Criação de aplicações de grande porte; ‣ Boa forma de manutenção de estados de aplicação através do Redux; ‣ Vários casos de sucesso para inspirar; ‣ Criação de aplicações que possuem uma versão Mobile; ‣ React Native utiliza o mesmo conceito do React para desenvolvimento de aplicações mobile nativas.
  42. 78.

    REACT CASOS DE USO COMUNS ‣ Desenvolvimento de aplicações que

    requerem foco maior em performance; ‣ Utilizado muito por times que já possuem um bom background em JavaScript e front-end de uma forma geral.
  43. 79.
  44. 80.

    PROBLEMAS COM SEO ‣ TODOS os frameworks SPA possuem problemas

    com SEO; ‣ Frameworks SPA sempre possuem uma página estática e o restante dinâmica de acordo com as rotas e o estado de cada componente; ‣ Mecanismos de busca não conseguem prever qual tela o cliente irá renderizar para fazer o Rankeamento.
  45. 81.

    PROBLEMAS COM SEO: SERVER-SIDE RENDERING ‣ Front-end no Back-end ;

    ‣ Servidor envia na requisição o resultado esperado da página; ‣ Navegação entre as páginas continua fluida como em um SPA; ‣ Menor TTI (time to interactive);
  46. 85.

    MÚLTIPLOS PROBLEMAS EM UMA MESMA APLICAÇÃO ‣ Tela de Login

    precisa de um baixo TTI (time to interact); ‣ Tela de Cadastro foi feita em MVC, mas possui os mesmos aspectos visuais da tela de Editar Conta; ‣ Módulo de Produtos precisa ser confiável e manter a mesma consistência de tipos de seus endpoints no backend;
  47. 87.

    MICRO FRONT-ENDS ‣ Não é um framework; ‣ Não é

    uma biblioteca; ‣ Não é uma extensão; ‣ Não é magia; ‣ É um estilo arquitetural!
  48. 88.

    MICRO FRONT-ENDS ‣ Baixo ou nenhum acoplamento; ‣ Alta coesão;

    ‣ Não deve assumir responsabilidades de outro micro frontend; ‣ Não deve interferir ou ser interferido por outro micro frontend; ‣ Base de código independente; ‣ Stack (frameworks, linguagens..) diferentes para cada aplicação; ‣ Pipeline de build, test e deploys separados e independentes;
  49. 91.
  50. 95.

    ATIVIDADE AVALIATIVA (40PTS) ‣ Utilizar API do The Movie DB

    para consulta de filmes; ‣ Tela 1: ‣ Listagem dos filmes mais populares (/movies/popular); ‣ Barra de busca de filmes por nome (/search/movie).
  51. 96.
  52. 97.
  53. 98.
  54. 99.

    REQUISITOS ‣ Escolha de algum framework SPA (client-side ou server-side

    rendering); ‣ Utilização de recursos para criação de um PWA (progressive web application); ‣ Sugestão: workbox: https://developers.google.com/web/ tools/workbox; ‣ Cache de requisições e/ou cache de assets (arquivos .css e .js).
  55. 100.

    QUAL O SEU PAPEL? ‣ Formar um grupo; ‣ Analisar

    as skills do time; ‣ Definir quais os critérios técnicos do protótipo; ‣ Escolher uma stack!