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.

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

22. 😷

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,
SUBINDOVERSÃ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, UMAVEZ 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 MUITASVEZES 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ÃOVISUAL).
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Á.
AVANTAGEM É 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 DEVIEWS 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
QUEVOCÊ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 ;)