Descripción del proyecto
TraducidoEl trabajo cubre toda la pila de backend de GraphQL: un esquema tipo-primer para nuestras entidades clave, resolutores sobre una capa de PostgreSQL optimizada, autenticación JWT pasada a través del contexto, y autorización a nivel de campo para que diferentes roles vean solo lo que deben. La parte en tiempo real también importa: el estado de los pedidos y las notificaciones deben llegar a los clientes a través de suscripciones WebSocket, no mediante sondeos constantes. Más allá de la corrección, nos importa la seguridad y el control de costos de las consultas: límites de profundidad y complejidad, además de consultas persistidas para clientes móviles.
Dado que esto reemplaza una API en vivo, un camino de migración limpio y documentación clara son parte de la tarea, no un bono. Cuéntanos sobre una API GraphQL que hayas lanzado y cómo resolviste problemas de autorización y rendimiento. Alcance detallado a continuación.
1. Diseño del esquema
— Tipo-primer: Usuario, Producto, Pedido, Reseña, Notificación
— Tipos de entrada, mutaciones
— Escalares personalizados (Fecha, JSON, Carga)
— Tipos de enumeración para campos de estado
2. Implementación
— Apollo Server 4 + Express
— DataLoader para prevenir consultas N+1
— Autenticación JWT a través del contexto
— Autorización a nivel de campo
— Suscripciones a través de WebSocket (estado del pedido, notificaciones)
3. Rendimiento y calidad
— Límites de profundidad/complejidad de consultas
— Consultas persistidas para clientes móviles
— Optimización de PostgreSQL (EXPLAIN ANALYZE)
— Pruebas unitarias para resolutores (Jest + Supertest)
— Integración de Apollo Studio
4. Documentación
— Esquema documentado (descripciones de todos los tipos)
— Colección de Postman/Insomnia
— Guía de migración de REST