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. CRITÉRIOS PARA UMA ESCOLHA ADEQUADA DE UMA STACK FRONT-END

  2. http://bit.ly/puc-front-end

  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
  4. VAMOS DESENVOLVER UM NOVO PROJETO!

  5. None
  6. DEFINIÇÃO ARQUITETURAL DO PROJETO

  7. FILE > NEW PROJECT…

  8. ECOSSISTEMA FRONTEND EM CONSTANTE EVOLUÇÃO Vuejs Polymer Elm ReactJs Angular

    Angular Elements
  9. NOVAS LINGUAGENS PARA DESENVOLVIMENTO NO FRONT-END Elm language Javascript Typescript

    Purescript ReasonML Web Assembly (WASM)
  10. NÃO EXISTE BALA DE PRATA

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

    especialista em tudo, certo? Então…
  12. ESTABELEÇA CRITÉRIOS OBJETIVOS ‣ Performance; ‣ Disponibilidade; ‣ Tempo de

    carregamento; ‣ Bundle size; ‣ Segurança; ‣ Documentação; ‣ Custos; ‣ SEO; ‣ Maior hype… KEEP CALM AND
  13. ESTABELEÇA PESO PARA OS CRITÉRIOS OBJETIVOS

  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.
  15. FAÇA PROVAS DE CONCEITO BASEADAS NOS SEUS CRITÉRIOS OBJETIVOS

  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
  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
  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.”
  19. “Our prototype: a reimplementation of the LinkedIn feed in Preact

    and Glimmer.js flavors”
  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.
  21. FERRAMENTA UTILIZADA: HTTPS://WWW.WEBPAGETEST.ORG/

  22. RESULTADOS

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

    IN THE BEGINNING JUST MEANS PUSHING ADDITIONAL COMPLEXITY INTO THE APP ITSELF.”
  24. OUTRAS FERRAMENTAS PARA PROVAS DE CONCEITO

  25. ‣ Code sandbox: https://codesandbox.io;

  26. ‣ Zeit/Now: https://zeit.co/now

  27. ‣ Heroku: https://www.heroku.com/

  28. ADOÇÃO DA COMUNIDADE

  29. ADOÇÃO DA COMUNIDADE != HYPE-DRIVEN DEVELOPMENT

  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.
  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).
  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.
  33. UM BREVE PANORAMA

  34. ECOSSISTEMA FRONTEND EM CONSTANTE EVOLUÇÃO Vuejs Polymer Elm ReactJs Angular

    Angular Elements
  35. Vuejs ReactJs Angular

  36. NOVAS LINGUAGENS PARA DESENVOLVIMENTO NO FRONT-END Elm language Javascript Typescript

    Purescript ReasonML Web Assembly (WASM)
  37. Javascript Typescript

  38. ANGULAR

  39. ANGULARJS != ANGULAR

  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.
  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.
  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.
  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
  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/;
  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.
  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.
  47. ANGULAR PONTOS DE ATENÇÃO https://bundlephobia.com/result?p=@angular/core@8.2.12

  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.
  49. EXEMPLO https://codesandbox.io/s/angular-demo-ygv74

  50. VUE

  51. "VUE IS DESIGNED FROM THE GROUND UP TO BE INCREMENTALLY

    ADOPTABLE” Core team VUE
  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;
  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.
  54. None
  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.
  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/;
  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.
  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.
  59. VUE

  60. EXEMPLO https://codesandbox.io/s/vue-demo-rezu6

  61. REACT

  62. “A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES” https://reactjs.org/ REACT

  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.
  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.
  65. const MyComponent = props => <h1>Hello World</h1>

  66. function App(props) { return ( <div className="App"> <h1>{props.title}</h1> <h2>Start editing

    to see some magic happen!</h2> </div> ); }
  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.
  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.
  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).
  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.
  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.
  72. Fonte: https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-web-frameworks

  73. Fonte: https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-web-frameworks

  74. Fonte: https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-web-frameworks

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

    e arquivos definidos.
  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.
  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.
  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.
  79. REACT

  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.
  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);
  82. [REACT] SERVER-SIDE RENDERING https://nextjs.org/

  83. [VUE] SERVER-SIDE RENDERING https://nuxtjs.org/

  84. [ANGULAR] SERVER-SIDE RENDERING

  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;
  86. MICRO FRONT-ENDS

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

    uma biblioteca; ‣ Não é uma extensão; ‣ Não é magia; ‣ É um estilo arquitetural!
  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;
  89. Fonte: https://martinfowler.com/articles/micro-frontends.html

  90. ANALISE A PONTUAÇÃO DOS SEUS CRITÉRIOS OBJETIVOS

  91. None
  92. OBRIGADO! Github:
 https://github.com/samwx Linkedin:
 https://www.linkedin.com/in/samwx/ Email:
 samuelmartins.sw@gmail.com

  93. VAMOS PRATICAR!

  94. ATIVIDADE AVALIATIVA (40PTS) ‣ Aplicativo para listagem de filmes https://www.themoviedb.org/

  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).
  96. None
  97. ATIVIDADE AVALIATIVA (40PTS) ‣ Tela 2: ‣ Listagem de detalhes

    de um filme (título, capa e sinopse)
  98. None
  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).
  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!