Spring GDS 25è Aniversari
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
GraphQL i REST són dos enfocaments per construir una API, la capa a través de la qual un frontend demana dades a un backend. REST ho organitza tot al voltant de recursos, cadascun amb la seva pròpia URL. Obtens un usuari d'un endpoint, les seves comandes d'un altre, els articles de cada comanda d'un tercer. GraphQL exposa un únic endpoint i un esquema, i el client envia una consulta que descriu exactament les dades que vol, rebent de tornada aquesta forma i res més.
La diferència es nota sobretot en dos problemes als quals REST és propens. L'over-fetching és quan un endpoint retorna més camps dels que necessites. L'under-fetching és quan una crida no n'hi ha prou i has de fer-ne diverses per armar una pantalla. Una pàgina de perfil mòbil en REST podria cridar tres endpoints i llençar la meitat del que arriba. La mateixa pàgina en GraphQL és una consulta que retorna precisament els camps que la pantalla renderitza, i per això les apps preocupades per l'amplada de banda solen preferir-la.
Cap dels dos guanya de manera rotunda. REST és més simple, es recolza en la memòria cau HTTP que tot el web ja entén i és fàcil de raonar per a un accés a recursos senzill. GraphQL dona flexibilitat al client i redueix els viatges d'anada i tornada, però mou la complexitat al servidor, complica la memòria cau i exigeix cura amb el cost de les consultes perquè una sola petició no pugui demanar massa. L'elecció correcta depèn del client, de la forma de les dades i de qui consumeix l'API.
No tenim favorit de la casa. Triem segons el problema. Un client que construïa una plataforma de continguts amb molts tipus de client i dades profundament niuades es va endur GraphQL, perquè la flexibilitat pagava de debò el seu sobrecost i deixava els seus equips de frontend avançar sense esperar nous endpoints. Un altre client necessitava una API pública neta i cacheable per a partners, i REST era la resposta òbvia i honesta. Forçar GraphQL allà hauria afegit complexitat per a res.
Totes dues decisions són part de com abordem el desenvolupament API-first. Triem l'estil abans d'escriure el contracte, sospesem amb el client les conseqüències de cau i tooling, i ens comprometem amb un en lloc de descargolar un segon per tapar una mala primera decisió. L'objectiu és una API amb la qual els mateixos enginyers del client puguin conviure durant anys, no la que millor es llegeix en una proposta.
Decidint entre GraphQL i REST per a una API nova? Triem la que encaixa.
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
Convertir una marca en un negoci que funciona.
Mig milió de persones. Una app. Zero caos.















