/projects/dietbox-portal
← Todos os projetosDietbox Portal
O back office que passou a operação do produto para o time de operações.
Head de Tecnologia · 2023–2024
Visão geral
Até 2023, qualquer alteração nos dados do produto passava pelo time de tecnologia: ajustar uma assinatura, corrigir um cadastro, carregar uma tabela de alimentos. O portal colocou essas ações em telas, com as regras do produto na frente e um login separado do login do cliente. O time de operações passou a fazê-las direto — quarenta e quatro ações em dez áreas.
O que eu fiz
Decidi o que a operação deveria conseguir fazer sem a gente, e construí o que era preciso para que fizesse com segurança: a identidade de equipe e as permissões atrás das quais tudo roda, a superfície de comandos por baixo das telas, e o desenho sobre o qual o resto do time construiu as dezoito áreas de negócio.
- A escolha das ações: de quais pedidos a gente estava cansado, e quais deles dava para entregar com segurança.
- O bloco de identidade: base de usuários própria, um builder e validador de JWT, tokens de acesso e refresh, e autorização baseada em claims.
- A impersonation, nas duas direções e nos dois caminhos de volta, e a regra de que ela mora atrás de uma conta de equipe, não de cliente.
- O desenho sobre o qual o time construiu as dezoito áreas de negócio, para que uma área nova fosse um dia de trabalho e não uma discussão.
Entre o serviço e o cliente admin juntos, cerca de um terço dos commits são meus — o restante, incluindo a maior parte dos dezoito controllers de domínio de negócio e das telas do cliente, é do time.
O problema
O suporte não conseguia ajustar uma assinatura, o marketing não conseguia publicar um banner, e ninguém fora da engenharia conseguia carregar uma tabela nova de alimentos. Cada coisa era um pedido ao time de tecnologia, e um engenheiro rodando a mudança na mão contra o banco do produto ou a superfície de admin do monolito — sem regra na frente e sem nome depois.
Em números
A fatia de commits vem dos dois repositórios. O quarenta e quatro é a contagem das ações de escrita que o serviço expõe — os comandos por trás das telas que a operação usa.
Arquitetura
Alguém do time de operações escolhe uma ação numa tela, e ela viaja como um comando nomeado pelas regras do próprio produto antes de chegar aos dados do produto.
- OpsAlguém do time de operações, logado com uma conta de equipe, nas telas em Vue das dez áreas — incluindo os controles de impersonate na navbar e na tela do paciente.
- PermissionsO token decide quais das ações essa pessoa pode executar — um filtro de exigência de claim na frente de cada controller.
- CommandA ação roda como um dos quarenta e quatro comandos, registrada pelo nome no caminho, em vez de como uma edição numa tabela.
- RulesAs mesmas regras que o próprio produto aplica ficam na frente da escrita — que é a diferença entre a operação fazer isso e um engenheiro fazer na mão.
- DatabaseA mudança cai no mesmo banco de onde o produto serve — que é exatamente por que ela passa pelas regras acima, e não por fora delas.
O que faz
- Impersonation como funcionalidade de primeira classe: o suporte pode agir como a nutricionista ou o paciente que está atendendo, pela navbar do cliente ou pela tela do paciente, e voltar a ser quem é.
- Assinaturas: cancelar uma, conceder uma especial, mudar os limites de um plano e migrar uma nutricionista para o novo gateway de pagamento.
- O catálogo de alimentos: criar, editar, desativar e ativar alimentos e grupos em lote — ou importar uma tabela inteira de um arquivo, que antes era um engenheiro com um script.
- Vouchers, vouchers externos e configuração de brindes, criados e encerrados por quem está tocando a campanha.
- Marketing: banners em destaque, os cards customizáveis nas telas do próprio produto e a biblioteca de materiais.
- Cadastros de nutricionista e paciente: atualizar dados, corrigir um e-mail e limpar um cache que está servindo algo desatualizado.
- Um dashboard cujos números vêm dos mesmos comandos que os alteraram, então a operação lê os próprios resultados.
Decisões de engenharia
Entregar as ações em vez de atender os pedidos
A opção mais barata era continuar atendendo os pedidos conforme chegavam. Só que atender não fica mais rápido com a repetição, e cada pedido custa tempo de engenharia num trabalho que não é de engenharia. As telas construídas aqui são os pedidos que chegavam com frequência suficiente para valer a substituição.
Identidade de equipe não é identidade de cliente
O back office se autentica contra a própria base — um bloco de identidade com base de usuários própria, um builder e validador de JWT, tokens de acesso e refresh, e autorização baseada em claims — não o diretório do cliente. Dar contas de equipe de suporte no sistema de identidade do cliente teria significado conceder escopos administrativos a identidades de grau cliente; manter os dois separados faz de uma sessão do back office algo diferente de uma sessão de cliente, por construção.
Uma ação, não uma edição no banco
A operação invoca uma de quarenta e quatro ações nomeadas, cada uma com as regras do próprio produto na frente, e cada uma registrada pelo nome ao passar por um pipeline behaviour. O caminho manual que isso substituiu — um engenheiro escrevendo um update contra o banco — não passava por nenhuma dessas regras e não deixava registro de ter rodado.
O suporte vê a tela, em vez de uma descrição dela
Parte do que chegava na engenharia não era pedido de mudança, e sim problema de reprodução — alguém sem conseguir ver o que o cliente descrevia. A impersonation responde isso direto: o suporte entra na sessão da própria nutricionista ou do próprio paciente, vê o que a pessoa vê, e sai de volta. É muito acesso concentrado numa funcionalidade só, e por isso ela fica atrás da identidade de equipe, não perto de uma conta de cliente.