Foto do Samuel Teixeira
Samuel Teixeira
FPP
Engenheiro de Software (Full Stack - Frontend Lead + Legacy Refactors)
Mai 2025 → Set 2025

FPP World (TSW) - Modernização do monorepo Laravel e criação do Student Registration SPA em Vue 3

Liderei a modernização do frontend em um monorepo Laravel legado, introduzindo Vue 3 + Vite + Tailwind e entregando um SPA de registro de estudantes com integrações (reCAPTCHA, GA4, Google Places) e refactors em Blade.

Stack

Laravel 8
PHP
Blade
Vue 3
Vite
TypeScript
Tailwind CSS
Pinia
Docker
AWS (S3)

Métricas

406 commits atribuídos a mim (08/05/2025 → 15/09/2025)
Vue 3 + Vite + Tailwind introduzidos no monorepo
Pinia adotada para estado do fluxo de Registration

Resumo

  • Entrega: criação/reestruturação do Student Registration (SPA) e modernização do frontend do monorepo (Vue 3 + Vite + Tailwind).
  • Como eu destravei: migração incremental (legado Blade + SPA coexistindo), com toolchain consistente e componentes reutilizáveis.
  • Efeito prático: base moderna para evoluir fluxos (registration/match), com integrações essenciais (anti-bot, analytics, autocomplete) e UI mais consistente.

Em ~4 meses, eu assumi o “refresh” do frontend de um Laravel monorepo e levei a plataforma para um setup moderno com Vue 3 + Vite + TypeScript + Tailwind, além de refactors em Blade quando fazia sentido - mantendo compatibilidade com o legado e com o deploy existente.

Contexto

  • Produto e usuários: plataforma multi-tenant/multi-marca para eventos/feiras (físicas e virtuais), com páginas em Blade e apps de fluxo (registro/match) no frontend.
  • Por que era crítico: evoluir UI e fluxos sem “quebrar” o legado e sem reescrever a plataforma inteira.
  • Restrições reais: monorepo antigo, coexistência Blade + assets modernos, dependência do pipeline de deploy (scripts + upload estático), e cobertura de testes baixa.

Principais desafios

  • Modernizar sem reescrever: introduzir Vite/Vue/TS/Tailwind dentro de um Laravel legado sem parar a operação.
  • Complexidade de fluxo: registro do estudante com múltiplas etapas, estados intermediários e jornada de match.
  • Consistência e qualidade: reduzir drift visual e padronizar estilo/estrutura em múltiplas áreas.
  • Integrações e confiabilidade: analytics, anti-bot e autocomplete de endereço sem degradar UX.

O que eu fiz

  • Student Registration SPA (Vue 3)

    • Estruturei o app por domínios do fluxo (etapas, validações, estado e componentes de formulário/match), deixando a base pronta para manutenção e evolução.
    • Evoluí telas-chave do registration e do match, garantindo estados previsíveis (loading/erro/sucesso) entre etapas.

  • Modernização de build + stack

    • Introduzi Vue 3 + Vite + TypeScript + Tailwind dentro do monorepo Laravel e garanti compatibilidade com o pipeline de build existente.
    • Configurei padrões de qualidade no frontend (lint/format) para aumentar consistência e reduzir regressões em mudanças frequentes.

  • Integrações (produto) e robustez

    • Integrei Google Analytics (GA4/GTM) no SPA e mantive compatibilidade com tags já existentes no legado.
    • Adicionei Google reCAPTCHA v2 no fluxo de frontend com suporte no backend.
    • Integrei Google Places Autocomplete no formulário para melhorar preenchimento e reduzir erros.
    • Mantive compatibilidade com o processo de deploy existente (build + distribuição de assets).

Decisões & trade-offs

  • Migração incremental (Blade + SPA) > rewrite total: reduziu risco e acelerou entrega.
    Trade-off: convivência de padrões diferentes por um tempo (Blade e Vue lado a lado).
  • Padronizar qualidade (lint/format) cedo > “só feature”: aumentou consistência e reduziu drift/regressão visual.
    Trade-off: investimento inicial antes de parte das entregas visíveis.
  • Centralizar estado do Registration (Pinia) > estado espalhado por componentes: diminuiu acoplamento e facilitou evolução por etapa.
    Trade-off: exige disciplina no desenho do estado e contratos entre telas/componentes.
  • Testes: mantive o baseline do repo (PHPUnit), mas com baixa cobertura e sem suíte dedicada de frontend no período.
    Trade-off: priorizei evolução de produto + toolchain em vez de elevar cobertura naquele ciclo.

Resultados

  • Medido (engenharia): 406 commits atribuídos a mim (08/05/2025 → 15/09/2025), com modernização de stack (Vue 3/Vite/TS/Tailwind) e adoção de Pinia no fluxo de registration.
  • Proxy técnico (concreto):
    • SPA de registration estruturado para evolução (etapas + estado + componentes reutilizáveis).
    • Integrações entregues: GA4/GTM, reCAPTCHA v2, Google Places Autocomplete.
    • Refactors em Blade templates (padronização/ajustes) em áreas do legado relacionadas a páginas institucionais/eventos.
  • Operacional: base mais previsível para evoluir features e UI, com melhor DX e menos inconsistência visual.

Nota: métricas sensíveis de produto podem estar em dashboards internos; evidências redigidas podem ser organizadas sob solicitação.

O que eu faria diferente

  • Investiria mais cedo em uma suíte mínima de testes de frontend (smoke/e2e) para proteger o fluxo de registration.
  • Documentaria contratos e padrões (arquitetura do SPA, convenções de estado/rotas, guidelines de componentes) para acelerar onboarding e reduzir variações.
  • Criaria um checklist de release (lint + build + validações essenciais) acoplado ao pipeline de deploy para reduzir risco em mudanças de UI.