Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Samuel Martins

October 31, 2019
Tweet

More Decks by Samuel Martins

Other Decks in Technology

Transcript

  1. CRITÉRIOS PARA UMA
    ESCOLHA ADEQUADA DE
    UMA STACK FRONT-END

    View Slide

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

    View Slide

  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

    View Slide

  4. VAMOS DESENVOLVER UM NOVO PROJETO!

    View Slide

  5. View Slide

  6. DEFINIÇÃO ARQUITETURAL DO PROJETO

    View Slide

  7. FILE > NEW PROJECT…

    View Slide

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

    View Slide

  9. NOVAS LINGUAGENS
    PARA
    DESENVOLVIMENTO
    NO FRONT-END
    Elm language
    Javascript
    Typescript
    Purescript
    ReasonML
    Web Assembly (WASM)

    View Slide

  10. NÃO EXISTE BALA
    DE PRATA

    View Slide

  11. O QUE FAZER DIANTE
    DESSE CENÁRIO?
    Não é possível ser especialista em tudo, certo? Então…

    View Slide

  12. ESTABELEÇA CRITÉRIOS
    OBJETIVOS
    ‣ Performance;
    ‣ Disponibilidade;
    ‣ Tempo de carregamento;
    ‣ Bundle size;
    ‣ Segurança;
    ‣ Documentação;
    ‣ Custos;
    ‣ SEO;
    ‣ Maior hype…
    KEEP CALM AND

    View Slide

  13. ESTABELEÇA PESO PARA
    OS CRITÉRIOS OBJETIVOS

    View Slide

  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.

    View Slide

  15. FAÇA PROVAS DE
    CONCEITO
    BASEADAS NOS SEUS CRITÉRIOS OBJETIVOS

    View Slide

  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

    View Slide

  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

    View Slide

  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.”

    View Slide

  19. “Our prototype: a reimplementation of the
    LinkedIn feed in Preact and Glimmer.js flavors”

    View Slide

  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.

    View Slide

  21. FERRAMENTA UTILIZADA: HTTPS://WWW.WEBPAGETEST.ORG/

    View Slide

  22. RESULTADOS

    View Slide

  23. Tom Dale
    CASO LINKEDIN
    “(...) SKIMPING ON ABSTRACTIONS AND
    INFRASTRUCTURE IN THE BEGINNING
    JUST MEANS PUSHING ADDITIONAL
    COMPLEXITY INTO THE APP ITSELF.”

    View Slide

  24. OUTRAS FERRAMENTAS
    PARA PROVAS DE CONCEITO

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  28. ADOÇÃO DA
    COMUNIDADE

    View Slide

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

    View Slide

  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.

    View Slide

  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).

    View Slide

  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.

    View Slide

  33. UM BREVE
    PANORAMA

    View Slide

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

    View Slide

  35. Vuejs ReactJs
    Angular

    View Slide

  36. NOVAS LINGUAGENS
    PARA
    DESENVOLVIMENTO
    NO FRONT-END
    Elm language
    Javascript
    Typescript
    Purescript
    ReasonML
    Web Assembly (WASM)

    View Slide

  37. Javascript Typescript

    View Slide

  38. ANGULAR

    View Slide

  39. ANGULARJS != ANGULAR

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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/;

    View Slide

  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.

    View Slide

  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.

    View Slide

  47. ANGULAR
    PONTOS DE ATENÇÃO
    https://bundlephobia.com/[email protected]/[email protected]

    View Slide

  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.

    View Slide

  49. EXEMPLO
    https://codesandbox.io/s/angular-demo-ygv74

    View Slide

  50. VUE

    View Slide

  51. "VUE IS DESIGNED FROM THE
    GROUND UP TO BE
    INCREMENTALLY ADOPTABLE”
    Core team
    VUE

    View Slide

  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;

    View Slide

  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.

    View Slide

  54. View Slide

  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.

    View Slide

  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/;

    View Slide

  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.

    View Slide

  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.

    View Slide

  59. VUE

    View Slide

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

    View Slide

  61. REACT

    View Slide

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

    View Slide

  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.

    View Slide

  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.

    View Slide

  65. const MyComponent = props => Hello World

    View Slide

  66. function App(props) {
    return (

    {props.title}
    Start editing to see some magic happen!

    );
    }

    View Slide

  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.

    View Slide

  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.

    View Slide

  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).

    View Slide

  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.

    View Slide

  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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  79. REACT

    View Slide

  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.

    View Slide

  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);

    View Slide

  82. [REACT] SERVER-SIDE RENDERING
    https://nextjs.org/

    View Slide

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

    View Slide

  84. [ANGULAR] SERVER-SIDE RENDERING

    View Slide

  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;

    View Slide

  86. MICRO FRONT-ENDS

    View Slide

  87. MICRO FRONT-ENDS
    ‣ Não é um framework;
    ‣ Não é uma biblioteca;
    ‣ Não é uma extensão;
    ‣ Não é magia;
    ‣ É um estilo arquitetural!

    View Slide

  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;

    View Slide

  89. Fonte: https://martinfowler.com/articles/micro-frontends.html

    View Slide

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

    View Slide

  91. View Slide

  92. OBRIGADO! Github:

    https://github.com/samwx
    Linkedin:

    https://www.linkedin.com/in/samwx/
    Email:

    [email protected]

    View Slide

  93. VAMOS PRATICAR!

    View Slide

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

    View Slide

  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).

    View Slide

  96. View Slide

  97. ATIVIDADE AVALIATIVA (40PTS)
    ‣ Tela 2:
    ‣ Listagem de detalhes de um filme (título, capa e sinopse)

    View Slide

  98. View Slide

  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).

    View Slide

  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!

    View Slide