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

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!
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.
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
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).
97. ATIVIDADE AVALIATIVA (40PTS) ‣ Tela 2: ‣ Listagem de detalhes de um filme (título, capa e sinopse)
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!