GraphQL en Platzi: APIs que dan exactamente lo que pedís

La primera vez que vi GraphQL pensé: ¿por qué complicar algo que ya funciona con REST? El curso de Platzi me convenció de cuándo la pregunta está mal planteada.

El problema que GraphQL resuelve

Over-fetching: cuando una API REST retorna 40 campos y vos necesitás 5. Under-fetching: cuando necesitás datos de tres endpoints diferentes para renderizar una pantalla y hacés tres requests en cascada. GraphQL resuelve ambos — pedís exactamente lo que necesitás en un solo request.

Para aplicaciones con múltiples tipos de clientes (web, móvil, TV, reloj) que necesitan diferentes cortes de los mismos datos, GraphQL elimina la necesidad de endpoints especializados por cliente o múltiples versiones de API.

Cuándo tiene y cuándo no tiene sentido

Para un proyecto con un solo cliente web y datos relativamente simples — REST es más sencillo de implementar, cachear y debuggear. Para plataformas con múltiples consumidores, queries complejas y datos muy interrelacionados — GraphQL empieza a brillar.

Los proyectos del portafolio donde GraphQL aparece son los más complejos — plataformas con múltiples roles de usuario, datos de múltiples fuentes y clientes web y móvil consumiendo los mismos endpoints. El desarrollo de estos sistemas requiere pensar la API desde el inicio.

Lo que el curso no menciona pero importa en producción

N+1 queries — el problema clásico de GraphQL donde una query aparentemente simple dispara cientos de queries a la base de datos. DataLoader resuelve esto, pero hay que saber que el problema existe. El caching de GraphQL es más complejo que REST — CDN y HTTP cache no funcionan igual con POST requests.

Esas complejidades son manejables, pero hay que conocerlas antes de comprometerse con GraphQL en un proyecto de producción. Si estás evaluando arquitectura de API, contanos el caso.