A hora de migrar do Rails numa perspectiva do Front-end

Você sente que o processo de desenvolvimento front-end começou a ficar improdutivo com Rails? Nessa palestra vamos pontuar vários aspectos que nos ajudaram a decidir que a hora de partir pra outra stack tinha chegado. Veremos como é o impacto de uma migração desse tipo, quais alternativas e como escolher uma nova abordagem, considerando o aprendizado e bagagem que o Rails tem.

Transcript

1. A HORA DE MIGRAR DO RAILS NUMA PERSPECTIVA DO FRONT-END
2. OI, EU SOU O E D U @eduardojmatos
3. a maior plataforma de contratação de serviços do Brasil
4. D E V N A E S T R A DA . C O M . B R
5. H T T P : / / D I V E R S I DA D E . T E C H
6. H T T P S : / / G I T H U B . C O M / F R O N T E N D B R
7. RAILS 
 X
 FRONT
8. RAILS 
 X
 FRONT
9. É SOBRE QUAL O MOMENTO CERTO DE MIGRAR O FRONT-END PRA UMA APLICAÇÃO ISOLADA
10. ANTES…
11. RAILS VAI BEM, OBRIGADO
12. RAILS VAI BEM, OBRIGADO
13. PQ ENTÃO ESSA PALESTRA?
14. COMPLEXIDADE E PRODUTIVIDADE
15. API render de HTML servir assets modelagem de dados várias lógicas de negócio
16. https://martinfowler.com/bliki/MicroservicePremium.html
17. MAS O QUE TEM DE NEGATIVO NO RAILS? NUMA PERSPECTIVA DO FRONT-END DIVIDIDO EM DOIS TEMAS GESTÃO DE ASSETS TIME E CULTURA
18. GESTÃO DE ASSETS
19. RENDER NO RAILS TOOLING DE OTIMIZAÇÃO BUILT-IN DE HTML ENGESSADO COM BACK-END GESTÃO DE ASSETS
20. RENDER NO RAILS AS PARTIALS COMEÇAM A SE TORNAR CONFUSAS E COMEÇAM AS ARMADILHAS HTML ESPALHADO PRA TODO LUGAR GESTÃO DE ASSETS
23. TOOLING ENGESSADO COM BACK-END A MAIORIA DAS APLICAÇÕES MONOLÍTICAS TENDEM A TER SEUS PRÓPRIOS GESTORES DE ASSETS (EX: RAILS => SPROCKETS). GESTÃO DE ASSETS
24. TOOLING ENGESSADO COM BACK-END BABEL, NODE-SASS, OUTRAS FERRAMENTAS DE TOOLING FICAM DEPENDENTES DE UM UPDATE DO FRAMEWORK DE BACK-END GESTÃO DE ASSETS
25. MONOLÍTICOS QUE NÃO FAZEM GESTÃO DE ASSETS DEPENDEM DE UM BUILDER EXTERNO QUE CONSIGA CONVERSAR COM O BACK-END GESTÃO DE ASSETS
26. DEPLOY DE FRONT-END AFETANDO BACK-END AJUSTES PONTUAIS DE FRONT-END QUE PODERIAM SER SIMPLES DE SUBIR EM PRODUÇÃO, ACABAM CRIANDO UM DEPLOY MAIS ROBUSTO, SUBINDO VERSÃO DA APLICAÇÃO TODA GESTÃO DE ASSETS
30. DEPLOY PRA PRODUÇÃO EM MÉDIA: 30 MIN ISSO SE OS TESTES NÃO FALHAREM, SE EM HOMOLOG ESTIVER TUDO CERTINHO, NÃO CHOVER, AMAZON S3 NÃO CAIR (RÁ!), PRECOMPILE DE ASSETS DAR ALGUM XABÚ, …
31. ERA SÓ CSS, CAR***O
33. TIME E CULTURA
34. TAMANHO DA APLICAÇÃO PESSOA NOVA NO TIME SE ASSUSTA E SE PERDE COM CODEBASE GIGANTE TIME E CULTURA
39. MUITOS TIMES, MESMA APLICAÇÃO VÁRIAS ÁREAS DENTRO DE UM MESMO PROJETO TIME E CULTURA
40. MUITOS TIMES, MESMA APLICAÇÃO CONFUSÃO EM PADRÕES E CODE-REVIEW TIME E CULTURA
41. MUITOS TIMES, MESMA APLICAÇÃO REFACTOR TORNA-SE MAIS DIFÍCIL TIME E CULTURA
42. MUITOS TIMES, MESMA APLICAÇÃO ENTREGAS ATRELADAS A DE OUTROS TIMES TORNAM O PROCESSO DE DEPLOY MAIS COMPLEXO DE LIDAR TIME E CULTURA
43. “ATÉ QUE A MORTE OS SEPARE” SE TRATANDO DE FRAMEWORKS DE BACK-END, UMA VEZ ESCOLHIDA A TECNOLOGIA, VAI CONVIVER COM ELA POR UM LONGO TEMPO NO FRONT-END ISSO É QUASE IMPOSSÍVEL, SE TRATANDO DA QUANTIDADE DE EVOLUÇÕES QUE TEM OCORRIDO TIME E CULTURA
44. FERRAMENTA CERTA PRO JOB CERTO FRAMEWORKS MUITAS VEZES NÃO FACILITAM O USO DE FERRAMENTAS CERTAS PRA CADA TAREFA. TIME E CULTURA
45. IMPACTO DE ALTERAÇÕES MAIS COMPLEXO COM COBERTURA DE TESTES, FAZER ALTERAÇÕES NO FRONT-END COMEÇA A FICAR COMPLICADO. 
 VELOCIDADE DE EXECUÇÃO DAS SPECS, TESTE DE MARKUP, ETC., COMEÇA A DIFICULTAR AS COISAS. TIME E CULTURA
47. AMBIENTE DE DESENVOLVIMENTO MUITO LENTO SE NÃO EXISTIR “MOCK” OU SEED DE DADOS, DEPENDENDO DA QUANTIDADE DE QUERIES E INTEGRAÇÕES, O FRONT-END FICA EXTREMAMENTE LENTO TIME E CULTURA
48. FIRST RENDER DE UM MONOLÍTICO
49. 54 segundos de first render
50. VANTAGENS DE MIGRAR PARA UMA STACK DE FRONT-END ISOLADA
51. DEPLOY ISOLADO MUDOU CSS? CHEGA DE DEPLOY COMPLEXO E CRÍTICO
52. TOOLING ESPECIALIZADO POSTCSS, CSSNANO, BABELJS, ETC. UMA CAIXA DE FERRAMENTAS PRÓPRIA DE FRONT-END
53. PESSOAS DE 
 FRONT-END FOCADAS EM MELHORAR O FRONT-END PERFIL T-SHAPE OU FULL-STACK É MUITO BOM! MAS PRA INVESTIR EM PERFORMANCE, TER UMA BASE SÓLIDA E SABER ONDE ATACAR NO FRONT-END É PRECISO PESSOAS ESPECIALIZADAS NO ASSUNTO
54. NOVAS FERRAMENTAS PARA PROBLEMAS ESPECÍFICOS PWA, OFFLINE-FIRST, CLIENT-SIDE DATA, OTIMIZAÇÃO DE PAINT, WEBWORKERS… MUITA COISA NOVA SURGINDO QUE PRECISA DE UM CUIDADO MAIOR
55. COISAS SEPARADAS, MAS AINDA UNIDAS AINDA PRECISA DE MUITA INTEGRAÇÃO ENTRE AS APLICAÇÕES. NO FUNDO, AMBOS OS MUNDOS GANHAM.
56. DESENVOLVIMENTO MAIS RÁPIDO ISOLANDO O FRONT-END, PODEMOS FOCAR EM ENTREGAR INTERFACE MESMO SEM A FONTE DE DADOS BEM DEFINIDA AINDA (MOCKS). ISSO AGILIZA O PROCESSO
57. ENTÃO RAILS 
 É UMA B***A?
58. VANTAGENS DO RAILS PARA O FRONT-END
60. BRINKS ;)
61. MENOS CONFIG PRA MEXER DECISÕES JÁ FORAM TOMADAS, BASTA SE PREOCUPAR COM A FUNCIONALIDADE VANTAGENS DO RAILS
62. CONVENÇÕES FORTES FUNCIONA ASSIM, FAÇA AS COISAS DESSE JEITO. NÃO TEM MUITO SEGREDO OU CONVERSA. VANTAGENS DO RAILS
63. COMPLEXIDADE BAIXA ISOLANDO O FRONT-END, PRECISAMOS CUIDAR TAMBÉM DE MAIS UMA APLICAÇÃO WEB. MONITORAMENTO DE SERVER, TRACK DE ERROS, PERFORMANCE E CUIDADO COM OUTRAS COISAS VANTAGENS DO RAILS
64. TESTES CENTRALIZADOS AO ISOLAR O FRONT-END, PRECISAMOS COBRIR TAMBÉM A PARTE DE CLIENT-SIDE COM TESTES ESPECÍFICOS (INTEGRAÇÃO E ATÉ REGRESSÃO VISUAL). VANTAGENS DO RAILS
65. FRAMEWORK CONHECIDO, CONTRATAÇÃO MAIS FÁCIL QUANDO USAMOS UM FRAMEWORK CONHECIDO, ACHAR PESSOAS QUE JÁ CONHECEM A STACK É MAIS FÁCIL. FACILITA A ENTRADA DE INTEGRANTES NO TIME. VANTAGENS DO RAILS
66. ONE RING TO RULE THEM ALL TUDO ESTÁ LÁ. A VANTAGEM É QUE SÓ É PRECISO ME PREOCUPAR COM UMA APLICAÇÃO SÓ, E BOAS. SEJA PRA DESENVOLVER OU SUBIR NOVAS FEATURES. VANTAGENS DO RAILS
67. AGORA FIQUEI CONFUSO… CALMA
68. QUANDO DEVO MIGRAR PRA UMA STACK DE FRONT-END ISOLADA?
69. QUANDO DEVO MIGRAR PRA UMA STACK DE FRONT-END ISOLADA? QUANDO O TIME COMEÇAR A CRESCER. 1
70. QUANDO DEVO MIGRAR PRA UMA STACK DE FRONT-END ISOLADA? SÓ QUANDO AS PESSOAS DESENVOLVEDORAS TIVEREM SKILLS SUFICIENTES PRA MIGRAÇÃO. 2
71. QUANDO DEVO MIGRAR PRA UMA STACK DE FRONT-END ISOLADA? QUANDO O TEMPO DE CARREGAMENTO DE VIEWS E ASSETS COMEÇAR A IMPACTAR O DIA-A-DIA. 3
72. QUANDO DEVO MIGRAR PRA UMA STACK DE FRONT-END ISOLADA? QUANDO O DEPLOY COMEÇAR A SER PREOCUPANTE E IMPACTANTE COM FREQUÊNCIA. 4
73. QUANDO DEVO MIGRAR PRA UMA STACK DE FRONT-END ISOLADA? QUANDO O FRONT-END NÃO CONSEGUIR MAIS EVOLUIR, EM QUESTÕES DE TOOLING E NOVAS TECNOLOGIAS. 5
74. E COMO?
75. E COMO? CONVENCENDO COM DADOS O QUANTO DE IMPACTO NA PRODUTIVIDADE PARA O FRONT-END O RAILS TEM INFLUENCIADO? QUE TIPOS DE FERRAMENTAS PODERÍAMOS USAR SE MIGRÁSSEMOS PRA OUTRA STACK? QUANTAS PESSOAS JÁ TRABALHARAM NA STACK ATUAL E NA QUE VOCÊS QUEREM MIGRAR?
76. E COMO? MIGRANDO AOS POUCOS ESCOLHA UMA PÁGINA OU UMA PARTE PEQUENA DA APLICAÇÃO PRA COMEÇAR A MUDANÇA. FAÇA ITERATIVO. IMPLEMENTE, MEÇA. REFATORE, MEÇA. MOSTRE O RESULTADO DEPOIS DA MIGRAÇÃO.
77. E COMO? FAÇA POCs “PROVE OF CONCEPT” É JUSTAMENTE PRA TESTAR FERRAMENTAS QUE O TIME DESEJA IMPLEMENTAR. FAÇA POCs QUE PRODUZAM UMA ANÁLISE DO QUE FOI ESTUDADO. POCs SEM RESULTADO NÃO FAZEM SENTIDO.
78. E COMO? MOSTRE MIGRAÇÕES DE OUTRAS EMPRESAS BLOG POSTS EXPLICANDO OS PONTOS POSITIVOS E NEGATIVOS ESTÃO AÍ AOS MONTES. LEIA E TENTE ENCAIXAR NA SUA PROPOSTA DE MUDANÇA. CONVENCER COM EXEMPLOS É O MELHOR CAMINHO.
79. AVALIE, PESQUISE, LEIA ANTES DE MUDAR, TOME UMA DECISÃO BASEADA NO SEU CENÁRIO EM VÁRIOS CASOS, RAILS PARA O FRONT AINDA FAZ MUITO SENTIDO!!! TOME CUIDADO COM BLOG POST “PAGANDO DE COOL”, MUDANDO TODA STACK E ETC. ETC. ETC. AVALIE!!
80. UMA PESSOA QUE É BOA DESENVOLVEDORA: QUESTIONA TESTA PESQUISA LÊ MUITO NÃO SE LEVA PELO HYPE USA A FERRAMENTA CERTA, PRA HORA E LUGAR CERTO LEVA EM CONTA O NEGÓCIO QUE ESTÁ TRABALHANDO
81. Rails ainda é legal #PAS Matos, Eduardo
82. Stacks de front-end isoladas também #PAScomS2 Matos, Eduardo
83. Stacks de front-end isoladas também #PAScomS2 Matos, Eduardo
84. @eduardojmatos http://eduardomatos.me eduardoj.matos@gmail.com OBRIGADO ;)