Logo de Dallonses

GraphQL vs REST

Quina és la diferència entre GraphQL i REST?

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.

GraphQL i REST a Dallonses

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.

Parla amb nosaltres sobre disseny d'APIs

Serveis relacionats


Preparat per a traballar junts?

Reserva una reunió
Aymón sostenint una revista Tools davant de la seva cara
Ari treballant en un portàtil a l'aire lliure envoltada de plantes
Vista superior d'un escriptori de fusta amb teclat, ratolí i auriculars
Il·lustració dibuixada a mà d'una mà chasquejant els dits
Nico recolzat contra un dispensador d'aigua al costat d'un extintor
Primer pla d'un ordinador obert amb placa de circuit i components sobre un escriptori de fusta
Bernat i Andreu col·laborant en un escriptori amb monitors i un portàtil
Il·lustració dibuixada a mà d'una mà oberta saludant
Aymón sostenint una revista Tools davant de la seva cara
Ari treballant en un portàtil a l'aire lliure envoltada de plantes
Vista superior d'un escriptori de fusta amb teclat, ratolí i auriculars
Il·lustració dibuixada a mà d'una mà chasquejant els dits
Nico recolzat contra un dispensador d'aigua al costat d'un extintor
Primer pla d'un ordinador obert amb placa de circuit i components sobre un escriptori de fusta
Bernat i Andreu col·laborant en un escriptori amb monitors i un portàtil
Il·lustració dibuixada a mà d'una mà oberta saludant