Rendimiento y Escala
Resumen
El rendimiento es una característica con un presupuesto. Mídelo, delimítalo y respeta que los comportamientos de hoy se convierten en los contratos de mañana. Los sistemas rara vez fallan con el rendimiento para el que fueron diseñados; fallan por la consulta que no indexaste y la lista que no paginaste.
Los Principios
- Establece presupuestos y mide contra ellos. Objetivos de latencia (vinculados a los SLOs de
observability-and-slos) y presupuestos del cliente (p. ej., tamaño del bundle). Una regresión por encima del presupuesto es un error. - Mide antes de optimizar. Encuentra el cuello de botella real con datos (perfiles, planes de consulta, trazas) antes de cambiar código. Sin optimización especulativa.
- Pagina por defecto. Cualquier lista que pueda crecer debe paginarse con un tamaño de página limitado. Los conjuntos de resultados sin límite son un riesgo de latencia y denegación de servicio.
- Cuidado con los patrones de acceso N+1. Los datos obtenidos en un bucle son la falla de escalabilidad más común; usa operaciones por lotes o joins en su lugar. (En esta pila: usa la capa de GraphQL con look-ahead/DataLoader en lugar de resolución por fila).
- La Ley de Hyrum es real: todo comportamiento observable de una interfaz se convierte en un contrato del que alguien depende una vez que tiene suficientes consumidores, incluidos comportamientos que nunca planeaste (orden, nulabilidad, formas de error, temporización). Trata las interfaces públicas (especialmente la API/esquema) como contratos: añade y depreca, no cambies en silencio. Las pruebas de contrato de
graphql-contract-testingfijan los comportamientos que elegiste; la disciplina protege los que no elegiste.
Referencia Rápida
| Síntoma | Solución |
|---|---|
| Consulta dentro de un bucle | Operación por lotes o join; usa look-ahead |
| Endpoint de lista sin límite | Añade paginación con tope |