You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Olá, sou Gabriela, engenheira de software, e gostaria de compartilhar uma história sobre uma lição que aprendi ao desenvolver uma nova funcionalidade. Os organizadores de eventos podiam atribuir apenas um papel a cada palestrante em uma sessão. Os clientes precisavam de mais: a mesma pessoa poderia ser Moderadora em uma sessão e, em outra, atuar como Painelista e Apresentadora ao mesmo tempo.
Neste episódio, vou mostrar como evoluí uma plataforma Node.js e GraphQL em produção para atender a essa necessidade, em duas etapas. Primeiro, de um campo personalizado legado para papéis definidos por evento. Depois do lançamento, de uma relação um para um para um modelo muitos para muitos, sem alterar o contrato de resposta da API nem obrigar os organizadores a reconfigurar seus eventos.
Você vai aprender:
Como valores padrão seguros nos resolvers — um papel padrão por evento quando roleId não é informado — mantêm as integrações existentes funcionando.
Quando evitar a migração automática de dados legados e como os dados de produção nos ajudaram a tomar essa decisão: apenas 7% dos palestrantes usavam o campo antigo.
Como migrar para uma tabela associativa após o lançamento: preenchimento dos dados existentes (backfill), leitura dos dois modelos com DataLoader e manutenção do contrato da API.
Como isso funciona em produção: eventos com cerca de 1.000 sessões, nos quais 500 palestrantes têm múltiplos papéis.
Activity