Un operario de depósito intenta usar su app en el celular (PWA) para verificar el stock de 100 artículos en el ecommerce interno. La barra de carga se clava a la mitad, gasta batería y datos. El problema no es la velocidad de internet, el problema es que tus programadores diseñaron APIs "Chatter" (Habladoras) bajo arquitectura REST ineficiente.
El asesino silencioso: Overfetching y N+1
Para cargar una ficha de producto corporativa en tu B2B que muestre (1) Datos básicos, (2) Reseñas de calidad, y (3) Volumen de compra histórico de ese cliente, una arquitectura clásica REST (Endpoints fijos) hace tres viajes distintos al servidor. Cada viaje (ida y vuelta a la antena 4G) tiene "Latencia", unos 200 milisegundos de demora en el aire.
Además, el endpoint REST /api/v1/products/44 devuelve un archivo gigante de texto (JSON) donde está todo el diccionario del producto, aunque la pantalla solo necesite mostrar el número "15" en el circulito de stock.
La elegancia de las Mutaciones (GraphQL)
Las plataformas SaaS modernas (CommerceTools, VTEX IO, módulos nuevos) se están re-cableando internamente bajo GraphQL.
El cliente hace una sola consulta central (Un solo viaje):
query {
producto(id: "44") {
precio_lista
stock_deposito_centro
}
perfil_cliente {
historial_compras_mes
}
}
El servidor es lo suficientemente inteligente para ir a tres bases de datos distintas, juntar esos 3 datos sueltos exactos, y armar un paquetito miniatura que viaja al celular a la velocidad de un parpadeo. Para portales B2B pesados con miles de SKUs que tienen 50 atributos cada uno (medidas técnicas, voltajes, certificados), usar esta arquitectura separa el software corporativo del amateur.
