Descrição do projeto
TraduzidoEstamos migrando de uma API REST legada para GraphQL para atender dois clientes simultaneamente — um aplicativo móvel React Native e uma SPA React. Não queremos corrigir endpoints antigos: precisamos de uma camada GraphQL construída do zero e feita corretamente, por isso estamos procurando um desenvolvedor sênior com experiência real em produção com Apollo Server. O objetivo é um único gráfico tipado de forma limpa que ambos os clientes possam confiar, com desempenho previsível e sem surpresas de consultas N+1 quando uma tela carrega uma lista de registros relacionados.
O trabalho abrange toda a pilha de backend GraphQL: um esquema tipo-primeiro para nossas entidades principais, resolvers em cima de uma camada PostgreSQL otimizada, autenticação JWT passada através do contexto e autorização em nível de campo para que diferentes papéis vejam apenas o que devem. A parte em tempo real também é importante — o status do pedido e as notificações devem chegar aos clientes via assinaturas WebSocket, não por polling constante. Além da correção, nos preocupamos com segurança e controle de custo de consulta: limites de profundidade e complexidade, além de consultas persistidas para clientes móveis.
Como isso substitui uma API ao vivo, um caminho de migração limpo e documentação clara fazem parte da tarefa, não um bônus. Conte-nos sobre uma API GraphQL que você lançou e como resolveu problemas de autorização e desempenho. Escopo detalhado abaixo.
1. Design do esquema
— Tipo-primeiro: Usuário, Produto, Pedido, Avaliação, Notificação
— Tipos de entrada, mutações
— Escalares personalizados (Data, JSON, Upload)
— Tipos Enum para campos de status
2. Implementação
— Apollo Server 4 + Express
— DataLoader para prevenir consultas N+1
— Autenticação JWT via contexto
— Autorização em nível de campo
— Assinaturas via WebSocket (status do pedido, notificações)
3. Desempenho e qualidade
— Limites de profundidade/complexidade de consulta
— Consultas persistidas para clientes móveis
— Otimização do PostgreSQL (EXPLAIN ANALYZE)
— Testes unitários para resolvers (Jest + Supertest)
— Integração com Apollo Studio
4. Documentação
— Esquema documentado (descrições de todos os tipos)
— Coleção Postman/Insomnia
— Guia de migração de REST
O trabalho abrange toda a pilha de backend GraphQL: um esquema tipo-primeiro para nossas entidades principais, resolvers em cima de uma camada PostgreSQL otimizada, autenticação JWT passada através do contexto e autorização em nível de campo para que diferentes papéis vejam apenas o que devem. A parte em tempo real também é importante — o status do pedido e as notificações devem chegar aos clientes via assinaturas WebSocket, não por polling constante. Além da correção, nos preocupamos com segurança e controle de custo de consulta: limites de profundidade e complexidade, além de consultas persistidas para clientes móveis.
Como isso substitui uma API ao vivo, um caminho de migração limpo e documentação clara fazem parte da tarefa, não um bônus. Conte-nos sobre uma API GraphQL que você lançou e como resolveu problemas de autorização e desempenho. Escopo detalhado abaixo.
1. Design do esquema
— Tipo-primeiro: Usuário, Produto, Pedido, Avaliação, Notificação
— Tipos de entrada, mutações
— Escalares personalizados (Data, JSON, Upload)
— Tipos Enum para campos de status
2. Implementação
— Apollo Server 4 + Express
— DataLoader para prevenir consultas N+1
— Autenticação JWT via contexto
— Autorização em nível de campo
— Assinaturas via WebSocket (status do pedido, notificações)
3. Desempenho e qualidade
— Limites de profundidade/complexidade de consulta
— Consultas persistidas para clientes móveis
— Otimização do PostgreSQL (EXPLAIN ANALYZE)
— Testes unitários para resolvers (Jest + Supertest)
— Integração com Apollo Studio
4. Documentação
— Esquema documentado (descrições de todos os tipos)
— Coleção Postman/Insomnia
— Guia de migração de REST
Programação web Dinheiro, Transferência bancária
