A 03-01 vam triar Express i no vam discutir la decisió: calia començar per algun lloc i Express és el punt de partida més didàctic de l'ecosistema Node, perquè no amaga res. Cada middleware que vam registrar a src/app.js el vam escriure nosaltres, i per això entenem què fa cadascun.

Però Express no és l'única opció, ni tan sols dins de JavaScript, i la pregunta «quin framework fem servir?» apareix el primer dia de qualsevol projecte nou. Es respon gairebé sempre malament: per costum, per moda o per un benchmark llegit a mitges.

Aquesta lliçó dona la perspectiva que falta. Implementarem el mateix endpoint, GET /v1/cafes, en nou frameworks diferents de cinc llenguatges, amb el mateix contracte: els filtres de 02-06, la paginació obligatòria, la resposta {dades, total} i la validació que produeix el 400 del catàleg. Compararem què fa el framework per tu i què et deixa a tu, i acabarem amb els criteris honestos d'elecció —els que no surten als gràfics de peticions per segon— i amb l'observació més important del mòdul: gairebé res del que has après en aquest curs depèn del framework.

Aquesta lliçó no és un tutorial d'instal·lació. No muntaràs nou projectes. Els fragments hi són per ser llegits i comparats, no executats; cadascun assumeix el projecte ja creat amb les eines del llenguatge corresponent.

1. Per què existeix aquesta lliçó
2. Què s'espera avui d'un framework d'API
3. L'endpoint de referència
4. Express: el mínim, tot a càrrec teu
5. Fastify: esquemes, plugins i velocitat
6. NestJS: arquitectura opinada per a equips grans
7. Hono: lleuger i multi-runtime
8. FastAPI (Python): el tipatge com a contracte
9. Django REST Framework (Python): serializers i viewsets
10. Spring Boot (Java): l'estàndard empresarial
11. ASP.NET Core (C#): minimal APIs i rendiment
12. Mencions: Laravel, Rails API i Go
13. La taula comparativa
14. Criteris d'elecció honestos
15. El que no depèn del framework
16. Migrar entre frameworks: d'Express a Fastify
17. Runtimes alternatius i serverless

Tres situacions concretes fan que aquesta comparació importi:

• Comences un projecte i has de triar. La decisió condiciona els anys següents: contractacions, formació, dependències i velocitat de lliurament. Es pren en una reunió d'una hora i es paga durant cinc anys.
• Canvies de feina i el projecte és en un altre framework. Si entens quin problema resol cadascun, aterres en dies en lloc de en mesos.
• Algú proposa migrar. Necessites arguments millors que «Fastify és més ràpid» per decidir si compensa.

I hi ha un quart motiu, més de fons: veure el mateix endpoint nou vegades ensenya què és essencial en una API REST —el contracte, els codis, la validació, la paginació— i què és accidental, propi del framework de torn. És la millor vacuna contra confondre Express amb REST.

Un framework d'API es jutja per quant d'aquesta llista et dona resolt i amb quina qualitat:

Observa quantes caselles de la columna dreta diuen «a mà». Això no és un defecte d'Express: és la seva proposta. La pregunta d'aquesta lliçó és què guanyes i què perds quan un altre framework omple aquelles caselles per tu.

El contracte que implementaran els nou, tal com el vam fixar a 02-06 i 05-02:

Regles que cada implementació ha de complir:

1. limit per defecte 20, màxim 100; desplacament màxim 10.000.
2. torrefaccio només admet clar, mitja o fosc.
3. Un paràmetre invàlid produeix 400 amb {"error": {"codi": "parametre_invalid", ...}}.
4. El preu s'emmagatzema en cèntims enters i se serialitza en euros amb dos decimals.
5. Requereix autenticació.

Aquella quarta regla és la més reveladora: és on es veu si el framework serialitza per tu i si et deixa controlar la transformació.

El nostre punt de partida, condensat per poder-lo comparar:

Balanç d'Express. El codi és transparent: es llegeix de dalt a baix i no hi ha màgia. Cada garantia del contracte existeix perquè la vam escriure. El cost és que la llista de «a mà» de l'apartat 2 és llarga, i que res no t'obliga: és perfectament possible que un company registri una ruta sense validar i ningú no se n'assabenti fins que arribi un 500.

Fastify va néixer preguntant-se si es podia tenir la simplicitat d'Express amb millor rendiment. La resposta va ser que sí, i el mecanisme és interessant: JSON Schema com a peça central.

Tres coses que Fastify fa diferent i que convé entendre:

• La validació és declarativa i automàtica. No hi ha middleware validar: l'esquema querystring el fa el framework, i produeix el 400 sol. Guanyes garantia —no te'n pots oblidar— i perds control sobre el format de l'error, que s'ha de personalitzar amb setErrorHandler perquè encaixi amb el nostre catàleg.
• L'esquema de resposta compila un serialitzador. Fastify converteix aquell response.200 en una funció de serialització especialitzada, més ràpida que JSON.stringify genèric. Efecte secundari crucial: els camps no declarats a l'esquema s'eliminen de la resposta. És una protecció esplèndida contra fuites accidentals de dades (04-02) i, alhora, la causa número u de «he afegit un camp i no apareix».
• Els plugins tenen encapsulació real. Un plugin registrat en un àmbit no contamina els altres, a diferència d'app.use a Express, que és global. Això permet, per exemple, aplicar un rate limiting diferent a /v1/sessions sense trucs.

La documentació és gairebé gratis, perquè els esquemes ja estan escrits:

Aquí hi ha la diferència pràctica amb 05-02: a Express vam escriure openapi.yaml a mà i arrisquem deriva; a Fastify l'esquema és la validació i és la documentació. A canvi, l'especificació resultant és més pobra en descripcions i exemples si ningú no els escriu.

NestJS és el framework més opinat de l'ecosistema Node. Porta TypeScript, decoradors, mòduls i injecció de dependències; el seu model mental ve d'Angular i, més enrere, de Spring.

Què hi guanyes. Estructura idèntica a tots els projectes i equips, cosa que redueix a dies el temps d'incorporació d'algú nou. Injecció de dependències de debò, que fa trivials les proves amb dobles —el que a 03-08 vam aconseguir a mà amb el repositori en memòria—. Documentació OpenAPI generada des dels DTO amb @nestjs/swagger. I una convenció tan forta que les discussions sobre estructura de carpetes desapareixen.

Què hi pagues. Molt codi per a poc: el DTO anterior són trenta línies per al que en Zod són sis. Corba d'aprenentatge real —mòduls, proveïdors, àmbits, guàrdies, interceptors, canonades—. Arrencada i consum de memòria més grans. I una capa d'abstracció que, quan falla, obliga a entendre'n les interioritats.

Quan compensa. Equips de més de cinc persones, projectes de llarg recorregut, dominis complexos amb molts mòduls. Per a una API de sis endpoints és un vestit massa gran.

Hono respon a una pregunta nova: i si la teva API no s'executa en un servidor Node, sinó a la vora de la xarxa —Cloudflare Workers, Deno Deploy, Bun—?

L'interessant de Hono no és la sintaxi —molt semblant a Express— sinó que fa servir APIs web estàndard: Request, Response, fetch. El mateix codi s'executa a Node, Deno, Bun, Cloudflare Workers i AWS Lambda. És diminut (uns pocs kilobytes), cosa que importa molt en entorns on l'arrencada en fred es mesura en mil·lisegons.

El seu límit és l'altra cara de la mateixa moneda: a la vora no tens sistema de fitxers ni connexions TCP persistents, així que better-sqlite3 i el pool de PostgreSQL de 03-05 no existeixen; cal fer servir serveis de dades amb API HTTP. I el seu ecosistema és molt menor que el d'Express.

FastAPI és probablement la millor demostració d'una idea: si el llenguatge té anotacions de tipus, el framework en pot deduir la validació, la serialització i la documentació.

El que passa amb aquestes vint línies, sense escriure res més:

• Validació completa de tipus i rangs, amb 422 automàtic (personalitzable al nostre 400).
• Conversió de tipus: limit=20 arriba com a text i es lliura com a int.
• Documentació OpenAPI 3.1 completa, servida a /docs amb Swagger UI i a /redoc amb Redoc, sense una línia extra.
• Serialització amb els àlies preu_euros → preuEuros, que resol l'etern xoc entre el snake_case de Python i el camelCase del JSON.
• Injecció de dependències amb Depends, que a més fa trivial substituir usuari_actual a les proves.

FastAPI és la resposta més elegant del panorama a la deriva entre codi i contracte de 05-02. Els seus límits: Python és més lent que els runtimes compilats —encara que FastAPI, sobre async, és dels més ràpids de l'ecosistema—, i l'async de Python és fàcil d'espatllar: una crida bloquejant dins d'una funció async congela tot el bucle d'esdeveniments, un error tan clàssic com l'await oblidat a Node.

DRF és l'altra escola: no un framework d'API, sinó una capa d'API sobre un framework web complet. La seva premissa és que ja tens models de Django i els vols exposar.

Quaranta línies produeixen els set endpoints del recurs complet, amb filtratge, ordenació, paginació, permisos i una consola HTML navegable. És, amb diferència, la productivitat inicial més alta de tot aquest recorregut.

El preu. Els ViewSets exposen la forma del teu model de dades, no la del teu contracte d'API, i aquí xoca de ple amb 02-02: el dia que el contracte hagi de divergir del model —camps calculats, agregacions, noms diferents, subrecursos de transició d'estat com /comandes/{id}/pagament— lluites contra el framework. Es pot fer, amb serializers i accions personalitzades, però cada excepció costa més que si ho haguessis escrit a mà. A més, Django arrossega una filosofia completa: el seu ORM, el seu sistema de migracions, el seu admin. Si no els faràs servir, DRF és un pes mort.

Quan compensa: un CRUD sobre un model relacional que ja existeix, amb panell d'administració inclòs. És imbatible en aquell terreny.

Spring Boot és el framework que més APIs corporatives sosté al món. El seu model —anotacions, injecció de dependències, capes— és el que NestJS imita.

Java resol netament una cosa que en JavaScript és un problema real: BigDecimal per als diners. En JavaScript, 0.1 + 0.2 no és 0.3, i per això a 02-05 vam decidir desar cèntims enters. Java té un tipus decimal exacte de sèrie, igual que C# amb decimal.

El seu ecosistema és l'argument més gran: Spring Security per a OAuth i OIDC (04-03), Spring Data per a persistència, Actuator que dona /salut i mètriques de Prometheus (04-07) pràcticament gratis, springdoc-openapi per a la documentació. Tot el que al mòdul 4 vam construir peça a peça existeix aquí com a dependència estàndard, revisada i amb suport comercial.

El preu: verbositat, arrencada lenta (segons, encara que GraalVM ho mitiga), consum de memòria alt, i una corba d'aprenentatge llarga on el problema no és Java sinó la quantitat de conceptes de Spring.

ASP.NET Core és, als benchmarks públics, un dels frameworks web més ràpids que existeixen, i el seu mode minimal API elimina bona part de la cerimònia clàssica de C#.

Punts destacables: [AsParameters] agrupa els paràmetres de consulta en un record tipat, decimal dona aritmètica exacta per als diners, i el rendiment amb el mateix maquinari sol estar entre els millors del panorama. El seu punt fluix relatiu és la validació declarativa, que no ve de sèrie amb la potència de Pydantic o Zod.

Quan triar-lo: organitzacions ja a l'ecosistema Microsoft, o quan el rendiment per servidor és un factor de cost real. I convé desmuntar el prejudici: ASP.NET Core és multiplataforma, de codi obert i s'executa a Linux i en contenidors amb normalitat.

Laravel (PHP). Continua sent dominant a la web PHP i el seu mode API amb Eloquent, API Resources i Sanctum és productiu i ben documentat. El seu allotjament és el més barat i disponible del món. Estigmatitzat sense motiu: el PHP modern amb tipus poc té a veure amb el de fa quinze anys.

Ruby on Rails API (rails new --api). Pare de la «convenció sobre configuració» que va inspirar mig sector. Enorme productivitat inicial, ideal per a prototips i startups. El seu rendiment per procés és modest i l'ecosistema ha perdut impuls davant d'altres.

Go amb net/http (que des de Go 1.22 encamina amb patrons de mètode i ruta), o amb Gin o Echo:

Go destaca en tres coses: binari únic sense runtime (imatges Docker de pocs megues, arrencada instantània), concurrència amb goroutines i molt poca memòria per petició, i una biblioteca estàndard tan completa que molts equips no fan servir framework. A canvi, escrius més codi: no hi ha validació declarativa ni generació automàtica d'OpenAPI sense eines addicionals.

Com llegir la columna de rendiment. És una ordenació aproximada de peticions per segon en proves sintètiques de «retornar un JSON petit». Gairebé mai no descriu la teva API real, perquè tan bon punt hi ha una consulta a base de dades, una crida de xarxa o una plantilla, el framework deixa de ser el coll d'ampolla. Un GET /v1/cafes que triga 40 ms dels quals 35 són la consulta SQL rendeix pràcticament igual a Express que a Fastify. Si el teu p99 és alt, mesura abans de culpar el framework: la resposta sol ser a l'apartat d'índexs i N+1 de 04-06.

Els criteris reals, ordenats pel pes que haurien de tenir:

1. El llenguatge que domina el teu equip. És el criteri número u, de molt. Un equip expert en Python lliurarà abans i amb menys errors amb FastAPI que amb el framework Node més ràpid del món. El cost d'aprendre un llenguatge nou —no la sintaxi, sinó els seus modismes, la seva depuració, el seu empaquetatge, els seus paranys— es mesura en mesos de productivitat reduïda i en errors subtils en producció.

2. Contractació i mercat laboral. Si demà necessites dues persones més, les trobes? I a la teva ciutat, o a la teva franja horària? Triar un framework de nínxol perquè és elegant i descobrir que no hi ha ningú a qui contractar és un error car i freqüent.

3. Maduresa i horitzó de suport. Qui el manté? Hi ha una empresa al darrere, una fundació, una persona? Quina és la política de versions? Spring i Django porten més de quinze anys i continuaran; un framework de dos anys amb un sol mantenidor és una aposta. Aquest criteri pesa el doble si l'API és de llarg recorregut i el triple si ets en un sector regulat.

4. Encaix amb el problema. Un CRUD sobre model relacional amb panell d'administració demana DRF a crits. Una API a la vora amb latència mínima demana Hono. Un domini complex amb vint mòduls i quinze persones demana NestJS o Spring. Forçar l'eina contra el problema es paga cada setmana.

5. Ecosistema per al que necessites. No l'ecosistema en abstracte: existeix un client madur per a la teva base de dades, el teu proveïdor d'OAuth, la teva passarel·la de pagament, el teu sistema de cues? Descobrir la setmana sis que l'SDK de la teva passarel·la no existeix en aquell llenguatge és un problema seriós.

6. Rendiment. L'últim, tret que estiguis en un cas concret on importi: desenes de milers de peticions per segon, latència sub-10 ms, o una factura de servidors prou gran perquè un 30 % d'eficiència siguin diners reals. Per al 95 % de les APIs, la diferència entre frameworks és irrellevant davant d'una consulta sense índex.

I un advertiment sobre els benchmarks públics: mesuren un endpoint que retorna {"hello":"world"}, amb configuracions optimitzades per especialistes i sense base de dades, sense autenticació, sense validació i sense logs. Són útils per descartar ordres de magnitud i enganyosos per a tota la resta. Mesura la teva API real amb autocannon (04-06) abans de prendre cap decisió basada en velocitat.

Aquesta és l'observació central de la lliçó. Repassa el curs:

De sis mòduls, un canvia. I ni tan sols sencer: la separació per capes de 03-03 —rutes, controladors, serveis, repositoris— es conserva a tots ells amb altres noms, perquè no és una idea d'Express.

Exemples concrets del que es transfereix sense canvis:

• Que POST /v1/comandes exigeixi Idempotency-Key i retorni 201 amb Location és contracte. Igual als nou.
• Que un ETag que coincideixi amb If-None-Match produeixi 304 ho dicta HTTP. Canvia la funció que l'escriu, no la regla.
• Que el token JWT porti sub, rol i exp, i que la validació comprovi signatura, expiració i emissor, és OAuth i JWT. Canvia la biblioteca.
• Que un error es retorni com {"error": {"codi", "missatge", "detalls"}} és el teu catàleg.
• Que les etiquetes de les mètriques no incloguin com_5001 perquè rebenten la cardinalitat és una regla de Prometheus.

Conclusió pràctica: si saps dissenyar i operar APIs, aprendre un framework nou és qüestió d'una o dues setmanes. Si només saps Express, no saps fer APIs: saps fer servir Express. El coneixement transferible és el dels mòduls 1, 2, 4 i 5.

Suposem que la Botiga Aroma decideix migrar a Fastify per rendiment i per la generació automàtica d'OpenAPI. Què passa amb el projecte?

Es conserva tot el que no toca req i res: els serveis de src/serveis/, els repositoris de src/repositoris/, els mapejadors, src/errors/error-api.js, les migracions i —el més valuós— l'openapi.yaml i les proves d'integració de 03-08, perquè parlen HTTP i els és igual qui respongui. Aquelles proves són la xarxa de seguretat que fa possible la migració: si passen amb Fastify, la migració és correcta per definició.

Es reescriu la capa de lliurament: rutes, middlewares i la composició de l'aplicació.

Aquí hi ha el mateix endpoint, abans i després:

El controlador és idèntic tret de la signatura. Els esquemes Zod es converteixen amb zod-to-json-schema, l'eina que ja vam veure a 05-02.

La recepta de migració, si mai t'hi toca:

1. Congela el contracte. Ni un canvi funcional durant la migració. Si barreges totes dues coses, no sabràs si una fallada ve de la migració o de la funció nova.
2. Assegura primer les proves d'integració. Són el criteri objectiu d'èxit. Si la cobertura dels endpoints és baixa, apuja-la abans de tocar res.
3. Migra per recursos, no de cop. Amb un proxy al davant pots servir /v1/cafes des del servei nou i la resta des del vell. És el patró de la figuera estranguladora, i és el que fa viable migrar un sistema en producció.
4. Compara respostes byte a byte. Executa la col·lecció de Postman de 05-01 contra tots dos i fes-ne el diff. Les sorpreses solen ser a les capçaleres i a l'ordre dels camps.
5. Vigila els detalls petits, que són els que mosseguen: el format exacte de l'error de validació, l'ordre de les claus del JSON, si l'ETag és feble o fort, la codificació dels paràmetres repetits.

Compensa? Gairebé mai per rendiment tot sol. Compensa quan el framework actual bloqueja alguna cosa important: falta de tipatge en un equip que creix, absència d'un ecosistema que necessites, o un manteniment abandonat. «És més modern» no és una raó; és una despesa sense retorn.

Dos eixos més, breument, perquè afecten l'elecció tant com el framework.

Runtimes de JavaScript:

El detall més interessant de Deno per al que hem vist a 04-02: els permisos són explícits (--allow-net=api.botigaaroma.example), de manera que una dependència compromesa no pot llegir el teu disc ni obrir connexions a un servidor desconegut. És una defensa real contra els atacs de cadena de subministrament que vam esmentar amb npm audit.

Serverless. La teva API no s'executa com a procés permanent, sinó com a funcions que s'invoquen sota demanda: AWS Lambda amb API Gateway, Google Cloud Functions, Azure Functions, Cloudflare Workers.

Implicacions directes per al que hem construït: el rate limiting amb memòria local de 04-04 no funciona en serverless —cada invocació pot anar a una altra instància—, així que Redis passa de recomanable a obligatori; la memòria cau en procés desapareix; i el pool de connexions de 03-05 es converteix en un problema que exigeix un pooler extern.

Express s'executa a Lambda amb adaptadors (serverless-http), però Hono està dissenyat per a aquell entorn i arrenca en una fracció del temps. És un bon exemple de com l'entorn de desplegament —tema de 05-05— condiciona l'elecció del framework tant com el llenguatge.

• Triar per benchmark. Els gràfics mesuren {"hello":"world"} sense base de dades ni autenticació. El teu p99 el domina la consulta SQL, no l'encaminador.
• Triar per moda. El framework del qual tothom parla aquest any pot estar sense manteniment d'aquí a tres. Comprova qui el sosté i amb quina política de versions.
• Triar un llenguatge que l'equip no domina. És la decisió que més projectes enfonsa. La sintaxi s'aprèn en una setmana; la depuració, l'empaquetatge i els paranys del runtime, en mesos.
• Confondre el framework amb l'arquitectura. DRF o NestJS no et donen un bon disseny d'API: et donen una estructura. Un ViewSet mal fet servir exposa el teu model de dades i viola tot el mòdul 2.
• Migrar sense proves. Sense les proves d'integració de 03-08, una migració és una reescriptura a cegues. Assegura-les abans de començar.
• Barrejar migració i funcionalitat nova. Quan alguna cosa falli no sabràs de quina meitat ve. Congela el contracte.
• Oblidar que Fastify elimina els camps no declarats a l'esquema de resposta. És una virtut de seguretat i la causa més freqüent de «el meu camp nou no surt».
• Creure que «codi primer» t'estalvia pensar el contracte. Els tipus es generen; el disseny de 02-02 no.
• Consell: aprèn un segon framework d'un altre llenguatge, no un altre de Node. Comparar Express amb Fastify ensenya poc; comparar Express amb FastAPI o Spring ensenya què és essencial i què és accidental.
• Consell: mantén la lògica de negoci fora del framework. Si els teus serveis no importen res d'Express, migrar és canviar la capa de lliurament. És la raó de ser de la separació de 03-03, i el seu valor només s'aprecia el dia que cal.
• Consell: escriu un ADR amb la decisió (04-01), amb els criteris i les alternatives descartades. D'aquí a dos anys algú preguntarà per què, i sense ADR la resposta serà «perquè sí».

Per a cada escenari, tria un framework, justifica'l amb almenys tres criteris de l'apartat 14 i esmenta l'alternativa que descartes i per què:

A) Una startup de tres persones amb experiència en Python llança l'MVP d'una API de reserves de restaurants en vuit setmanes. Necessiten un panell d'administració intern des del primer dia i preveuen canvis de model constants.

B) Un banc modernitza la seva API de consulta de moviments. Deu persones, requisits d'auditoria i traçabilitat, integració amb un proveïdor d'identitat corporatiu, i suport garantit a deu anys.

C) Una API de geolocalització que rep 50.000 peticions per segon, retorna respostes molt petites des d'una memòria cau en memòria, i ha de respondre en menys de 20 ms a tot el món.

Aquest és l'endpoint GET /v1/cafes/{id}/ressenyes a Express:

Porta'l a Fastify mantenint el mateix contracte: mateixos paràmetres i validacions, mateixes capçaleres Cache-Control i Link, i el mateix format d'error parametre_invalid. Indica quines peces desapareixen, quines canvien de nom i què s'ha d'afegir explícitament que a Express era en un middleware.

Un company s'incorpora a un projecte en Spring Boot venint d'aquest curs, fet en Express. Redacta una guia d'una pàgina que li digui: quins coneixements dels mòduls 1, 2, 4 i 5 aplica tal qual (amb tres exemples concrets), què ha de reaprendre del mòdul 3 i quin és l'equivalent a Spring de cinc peces del nostre projecte (middleware/autenticacio.js, middleware/errors.js, repositoris/cafes-sqlite.js, esquemes/cafes.js i observabilitat/metriques.js).

A) Startup de reserves → Django REST Framework.

Alternativa descartada: FastAPI. Millor contracte i millor documentació automàtica, però no porta ORM, ni migracions, ni admin: caldria muntar SQLAlchemy, Alembic i un panell, i allà se'n van les vuit setmanes. Es reconsideraria als dos anys si l'API deixa de ser un CRUD i el contracte comença a divergir del model.

B) Banc → Spring Boot.

Alternativa descartada: NestJS. Dona una arquitectura semblant amb TypeScript i seria una elecció defensable, però perd en horitzó de suport, en maduresa de l'ecosistema de seguretat i auditoria empresarial, i en profunditat del mercat laboral bancari. A més, JavaScript no té tipus decimal natiu, cosa que en un sistema financer és fricció constant.

C) Geolocalització a 50.000 rps → Go, o Hono sobre Cloudflare Workers.

Decisió: Hono a la vora si el conjunt de dades cap en un magatzem distribuït tipus KV; Go multiregió si les dades són grans o el càlcul és intensiu. Descartats Express, NestJS i DRF: a aquell volum la diferència d'eficiència es tradueix directament en factura, i DRF a més arrossega un ORM que aquest cas no fa servir.

I el manejador d'errors global, imprescindible perquè el 400 automàtic de Fastify parli el nostre idioma:

Balanç de la migració d'aquest endpoint:

El que s'ha d'afegir explícitament és el més important de la llista: a Express controlàvem el format del 400 perquè l'escrivíem nosaltres; a Fastify, si no es registra setErrorHandler, la validació automàtica retorna el format del framework i trenca el contracte d'errors de 02-04 sense que ningú ho noti fins que un consumidor es queixa. És l'exemple perfecte que les garanties automàtiques d'un framework s'han de reconduir al teu contracte, no a l'inrevés.

Guia d'incorporació: d'Express a Spring Boot

El que apliques tal qual (mòduls 1, 2, 4 i 5).

El 80 % del que saps continua sent vàlid, perquè descriu HTTP i disseny, no Express. Tres exemples concrets:

1. El disseny del contracte (mòdul 2). Que els recursos siguin substantius en plural, que les transicions d'estat s'expressin com a subrecursos (POST /comandes/{id}/pagament) i no com un PATCH sobre estat, que el 201 porti Location, que un filtre sense resultats sigui 200 amb llista buida i no 404, i que la paginació sigui obligatòria amb limit i desplacament. Res d'això no canvia: ho escriuràs amb @PostMapping en lloc de router.post, i prou.
2. Memòria cau i concurrència (04-06). ETag, If-None-Match → 304, If-Match → 412, Cache-Control amb max-age. Spring ho exposa amb ResponseEntity.ok().eTag(...) i ShallowEtagHeaderFilter, però les regles són les d'HTTP i les decisions de política són les mateixes que vas prendre.
3. Tot el mòdul 5. La col·lecció de Postman funciona sense tocar una línia, perquè parla HTTP. L'openapi.yaml és el mateix document. La canalització de CI canvia npm ci per mvn verify i poc més. I un gateway al davant no distingeix què hi ha al darrere.

El que has de reaprendre (mòdul 3).

Només la capa de lliurament i les seves eines: anotacions en lloc de middlewares, Bean Validation en lloc de Zod, JPA o JDBC en lloc de better-sqlite3, JUnit i MockMvc en lloc de node:test i Supertest, i —el més aliè venint de Node— el contenidor d'injecció de dependències: a Spring no instancies els teus serveis, els declares i el framework els construeix i injecta.

Taula d'equivalències:

Consell final per a la incorporació: dedica el primer dia a llegir l'openapi.yaml del projecte, no el codi. El contracte és el que ja saps llegir, i et donarà el mapa complet del sistema abans d'enfrontar-te a una sola anotació de Spring.

Has vist el mateix endpoint —GET /v1/cafes, amb els seus filtres, la seva paginació obligatòria, el seu 400 del catàleg i la seva conversió de cèntims a euros— resolt en Express, Fastify, NestJS, Hono, FastAPI, Django REST Framework, Spring Boot, ASP.NET Core i Go. I amb això has vist els tres models que es reparteixen el panorama: el minimalista, on tu escrius totes les garanties i per això les entens; el d'esquema com a centre, on un mateix document serveix de validació, serialització i documentació —Fastify i FastAPI en són els millors exponents, i resolen d'arrel la deriva de contracte que a 05-02 vam haver de combatre amb eines—; i l'opinat, NestJS, Spring i DRF, que a canvi de més cerimònia donen estructura idèntica, injecció de dependències i una productivitat enorme quan el problema encaixa amb el que el framework espera.

Els criteris d'elecció, en el seu ordre real: el llenguatge que domina el teu equip, la contractació, la maduresa i l'horitzó de suport, l'encaix amb el problema, l'ecosistema concret que necessites i, en darrer lloc tret de casos molt específics, el rendiment —perquè els benchmarks mesuren {"hello":"world"} sense base de dades i el teu p99 el domina la consulta SQL de 04-06—. I saps que una migració es conserva o es perd segons una única cosa: si la teva lògica de negoci importa el framework o no. A la Botiga Aroma no ho fa, i per això src/serveis/, src/repositoris/, els mapejadors, openapi.yaml, la col·lecció de Postman i —sobretot— les proves d'integració de 03-08 sobreviurien intactes a un canvi a Fastify; només es reescriurien src/rutes/, src/middleware/ i src/app.js.

El més important d'aquesta lliçó és el que no canvia. Dels sis mòduls del curs, només el tercer depèn del framework, i ni tan sols sencer. Que una comanda exigeixi Idempotency-Key, que un ETag coincident produeixi 304, que els errors portin un codi estable del catàleg, que la SPA necessiti CORS i el panell un token amb àmbits, que les etiquetes de les mètriques no incloguin identificadors: res d'això no és Express. Si saps dissenyar i operar APIs, aprendre un framework nou són dues setmanes; si només saps Express, saps fer servir Express.

Tornem ara al projecte i a un cap que 05-02 va deixar solt. Tenim un contracte complet i validat com a document, però encara res no garanteix que el servidor el compleixi, ni que un canvi al YAML no trenqui la SPA sense avisar. A 05-04, Contractes, mocks i proves automatitzades d'API, tanquem aquell cercle: aixecarem un mock amb Prism des d'openapi.yaml perquè la SPA avanci en paral·lel, farem servir msw al front i nock per a les crides sortints a RàpidEnviaments, validarem les respostes reals contra els esquemes dins de les proves Supertest que ja tenim, detectarem canvis trencadors amb oasdiff aplicant les regles de 02-07, veurem quan el contract testing amb Pact compensa i quan és sobreenginyeria, i organitzarem el recorregut de compra complet com a prova d'extrem a extrem, amb la taula de què s'executa en desar, al pull request, al desplegament i en producció.