Aquesta és l'última lliçó del curs, i no és cap resum mandrós. Un resum et recordaria els noms de les coses; el que necessites ara és una altra cosa: criteri. Saber fer servir Express, Mongoose o BullMQ és una habilitat que s'adquireix en setmanes. Saber quan cal fer servir cadascun, què es trenca quan el sistema creix, què cal comprovar abans de deixar alguna cosa en mans d'usuaris reals i com justificar una decisió davant d'un equip, això és el que separa algú que «sap Node» d'algú a qui es confia un servei en producció.

Aquesta lliçó té cinc parts: el mapa del viatge, la llista de comprovació de posada en producció, el marc per prendre decisions tècniques, el que aquest curs no ha cobert, i com continuar aprenent. Al final, una última mirada a Escena Viva i una proposta concreta per a qui vulgui continuar pel seu compte.

1. El mapa del viatge: què vas construir i què va demostrar
2. La llista de comprovació de posada en producció
3. Com es pren una decisió tècnica
4. Deute tècnic: quan assumir-lo i quan pagar-lo
5. El que aquest curs no ha cobert i cap on continuar
6. Com continuar aprenent
7. Una última mirada a Escena Viva
8. Una proposta de continuació

Cada mòdul va ensenyar alguna cosa i aquest alguna cosa s'havia de demostrar en una peça real d'Escena Viva. Aquesta taula és el curs sencer en una pantalla:

Llegeix l'última columna de dalt a baix. No és una llista d'exercicis: és la història d'una empresa que comença amb un array en un fitxer i acaba amb una plataforma operada de debò. Aquesta continuïtat és la lliçó més difícil de transmetre i la més valuosa que t'emportes.

Això és el que cal revisar abans que un usuari real toqui el sistema. No és aspiracional: cada punt es pot comprovar avui al teu projecte.

• [ ] Les proves passen a CI, no només a la teva màquina (M9, M11).
• [ ] La cobertura és raonable on importa: domini, càlcul d'imports, transicions d'estat, autorització. Un 90 % global amb el càlcul dels diners sense provar és un número que menteix.
• [ ] Hi ha com a mínim una prova d'integració per flux crític: comprar una entrada, pagar una comanda, publicar un article.
• [ ] Els casos límit estan provats: cistella buida, zero resultats, última unitat, data en el passat.
• [ ] El linter i el formatador s'executen a CI i bloquegen el merge.

• [ ] npm audit sense vulnerabilitats altes o crítiques sense justificar (M5), i actualitzacions automatitzades.
• [ ] Cap secret al repositori. Tots per variables d'entorn, validades amb zod en arrencar (M11). Si algun cop se n'ha filtrat un, es rota: esborrar-lo del codi no l'esborra de l'historial de git.
• [ ] HTTPS obligatori, amb HSTS; galetes httpOnly, Secure i SameSite (M8).
• [ ] helmet, cors amb llista d'orígens explícita, límits de mida de cos (M6).
• [ ] Limitació de peticions a autenticació, registre, recuperació de contrasenya i punts d'entrada cars (M6, M8).
• [ ] Autorització provada, no suposada: per cada punt d'entrada que pugui retornar dades alienes, una prova que confirmi el 403 o el 404 (M8, 12-04).
• [ ] Tota entrada validada amb zod, inclosos els esdeveniments de socket (12-01) i els paràmetres de consulta.
• [ ] Fitxers pujats validats pel nombre màgic, reanomenats pel servidor i servits des d'un altre origen (M3, 12-03).
• [ ] Sortida escapada en mostrar; HTML d'usuari sanejat amb llista blanca (12-03).

• [ ] Aturada ordenada: SIGTERM deixa d'acceptar connexions, acaba les peticions en curs, tanca sockets, cues i pool de base de dades, i surt (M11, 12-01).
• [ ] Sondes /salut/viu i /salut/preparat diferenciades: viva no és el mateix que preparada per rebre trànsit (M11).
• [ ] Temps límit a tota crida externa. AbortSignal.timeout a fetch (M4); temps de connexió i de consulta a la base de dades. Una crida sense temps límit és una fuita de recursos esperant a passar.
• [ ] Reintents amb retrocés exponencial i només en operacions idempotents (M10).
• [ ] Idempotència allà on el reintent és inevitable: pagaments, webhooks, treballs de cua (M10, 12-02).
• [ ] Treballs de cua amb attempts, backoff i cua de fallits revisada per algú.
• [ ] Migracions aplicades en un pas de release separat, mai en arrencar cada rèplica (M11).

• [ ] Registres estructurats amb pino, amb idPeticio a cada línia i un registrador fill per petició (M11).
• [ ] Mai no es registren contrasenyes, tokens, targetes ni dades personals innecessàries.
• [ ] Mètriques amb prom-client: latència per ruta, taxa d'error, profunditat de les cues, encerts de memòria cau (M11).
• [ ] Panell amb les quatre senyals d'or: latència, trànsit, errors i saturació.
• [ ] Alertes per símptoma, no per causa. Alerta per «el p99 de compra supera 2 s» o «hi ha comandes en pendent_pagament de fa més d'una hora», no per «la CPU està al 80 %». La CPU alta pot ser inofensiva; un client que no pot pagar, mai no ho és.
• [ ] Cada alerta té un procediment associat. Una alerta sense acció és soroll que ensenya l'equip a ignorar alertes.

• [ ] Migracions reversibles o, com a mínim, compatibles cap enrere durant un desplegament (afegir columna, desplegar, migrar dades, esborrar columna en un desplegament posterior).
• [ ] Còpies de seguretat provades. Una còpia que mai no s'ha restaurat no és una còpia: és una esperança. Restaura-la en un entorn a part amb calendari fix.
• [ ] Pla de reversió documentat i assajat: com es torna a la versió anterior i què passa amb les dades escrites per la nova.
• [ ] API documentada amb OpenAPI i versionada (M10); els canvis incompatibles passen per versió nova.
• [ ] README amb: com aixecar l'entorn, quines variables calen i a qui avisar si alguna cosa es trenca.

Si el teu projecte no supera aquesta llista, no vol dir que estigui malament: vol dir que saps exactament què et falta. Això ja és un avantatge enorme.

Les decisions que has vist al curs no van sortir d'una preferència personal. Van seguir —explícitament o implícitament— aquest marc:

El pas 5 és el que més gent es salta i el que més temps estalvia. Pregunta sempre: quant costa desfer això?

• Triar una llibreria de validació: reversible en una tarda. Decideix ràpid.
• Triar el model de dades de les comandes: gairebé irreversible un cop hi ha dades reals. Decideix a poc a poc.

Tres exemples del mateix curs, amb el marc aplicat:

Registrar les decisions: els ADR. Un ADR (Architecture Decision Record) és un fitxer curt al repositori, un per decisió rellevant:

El que és valuós d'un ADR no és el format: és que d'aquí a dos anys algú —probablement tu— llegirà «per què dimonis això està així?» i hi trobarà la resposta. Sense ADR, les decisions es reobren cada sis mesos amb menys informació que la primera vegada.

Deute tècnic no vol dir codi dolent. Vol dir una decisió que accelera avui a canvi d'un cost futur, igual que un préstec. Com un préstec, pot ser una idea excel·lent o una ruïna, i la diferència és si és conscient i si es paga.

La regla pràctica: el deute en seguretat, en dades i en diners no s'assumeix. Tota la resta és negociable si s'anota. I s'anota en un lloc amb data i amo, perquè un TODO sense amo és una decoració.

El senyal que el deute t'està ofegant sempre és el mateix: cada canvi petit triga cada vegada més i trenca coses cada vegada més llunyanes. Quan notis això, la prioritat ja no és la funcionalitat següent.

Honestedat abans que res: aquest curs t'ha donat una base sòlida i completa per construir serveis reals amb Node. No t'ho ha donat tot —ni podia—. Això és el que queda fora, per què importa i quan tocar-ho:

Si n'haguessis de triar només un: TypeScript. El retorn per hora invertida és el més alt de la llista, i millora tots els altres passos.

Quatre hàbits que distingeixen qui continua creixent de qui s'estanca:

Llegeix la documentació oficial, no la tercera resposta d'un cercador. La documentació de Node és excel·lent i conté detalls que cap tutorial no esmenta: el comportament exacte de pipeline davant d'errors, les garanties de cluster, les opcions de crypto.timingSafeEqual. Mitja hora a la documentació oficial ret més que tres hores de fragments solts.

Llegeix el codi font del que fas servir. Ja el tens a node_modules. Quan alguna cosa es comporti de manera estranya —Express 5 i els seus errors asíncrons, com BullMQ implementa jobId, com Socket.IO decideix el transport— obre'l i mira-te'l. Descobriràs que les llibreries que t'intimiden són codi normal escrit per gent normal. És el salt d'«usuari de l'eina» a «enginyer».

Segueix les notes de les versions de Node. Les versions LTS (Long Term Support, suport a llarg termini) són les parells (20, 22, 24…) i reben manteniment uns 30 mesos: són les que es fan servir en producció. Les senars són de vida curta i serveixen per provar novetats. Cada versió porta coses que substitueixen dependències: el fetch global, l'executor de proves integrat, el carregador de .env, node --watch. Menys dependències és menys superfície d'atac i menys manteniment.

Contribueix i construeix. Comença pel que és petit en projectes lliures: una errada a la documentació, una prova que falta, un cas límit. N'aprendràs tant del procés de revisió com del codi. I, sobretot, construeix alguna cosa teva de principi a fi, amb usuaris reals encara que en siguin cinc. Cap lliçó no ensenya el que ensenya un desplegament que es va trencar un diumenge i vas haver d'arreglar.

Val la pena mirar enrere el sistema complet.

Va començar sent un array de tres esdeveniments en un fitxer JavaScript i un console.log. Avui, sobre el paper d'aquest curs, Escena Viva és:

• Una API REST versionada i documentada amb OpenAPI, amb validació a la frontera, errors homogenis { error: { codi, missatge, estat, detalls } } i paginació per cursor; més una capa GraphQL amb DataLoader per a les vistes compostes.
• Un catàleg de 3 esdeveniments i 7 sessions sobre tres sales, amb un aforament de 3000 places i 1811 entrades venudes que mai no es sobrevenen, gràcies a transaccions amb blocatge.
• Autenticació amb contrasenyes xifrades amb bcrypt, JWT d'accés curt, refresc rotatori en galeta httpOnly amb revocació per famílies, i una política d'autorització pura sobre tres rols.
• Temps real: suport en directe amb Socket.IO, sales de conversa per conversa, confirmacions, presència i adaptador de Redis per funcionar amb diverses rèpliques.
• Comerç: botiga de marxandatge amb variants i stock, preus congelats a la comanda, imports calculats al servidor en cèntims, passarel·la de pagament amb webhooks signats i idempotents i una màquina d'estats que rebutja l'impossible.
• Contingut: magazín amb flux editorial, publicació programada, Markdown sanejat amb llista blanca, imatges validades pel nombre màgic i processades en cua a diverses mides.
• Col·laboració interna: espais per sala i esdeveniment, permisos per pertinença empesos a la consulta, blocatge optimista amb 412, activitat immutable i notificacions agrupades.
• Infraestructura: cues BullMQ amb consumidor a part, memòria cau a Redis amb invalidació, pool de worker threads, registres estructurats amb pino i idPeticio, mètriques amb prom-client, sondes de salut, Docker multietapa, docker compose amb api, consumidor, postgres, mongo i redis, i una canonada de CI/CD que prova, audita, construeix i desplega sola.
• I una bateria de proves que impedeix que res del que hi ha més amunt es trenqui en silenci.

Cap d'aquestes peces no és exòtica. Totes són les que sostenen productes reals que fas servir cada dia. La diferència entre aquest sistema i un de veritat no és de naturalesa: és d'escala, de diners i d'anys de retocs. Però les idees són les mateixes, i ara les tens.

Si vols continuar sol, aquí tens quatre ampliacions ben delimitades. Cadascuna cap en un cap de setmana o dos i toca coses noves de debò:

1. Migrar un projecte a TypeScript. Tria el més petit (l'eina de tasques o la botiga). Comença per tsconfig.json amb strict: true, activa allowJs, i converteix primer el domini (funcions pures), després els repositoris, després els controladors. Escriu tipus per a l'objecte de configuració i per al format d'error. Apunta quantes fallades reals et troba el compilador: et sorprendrà.

2. Substituir l'enviament de correu simulat per un de real i observable. Integra un proveïdor de correu, afegeix-hi reintents, gestiona els rebots per webhook, i munta un panell amb dues mètriques: correus enviats i correus fallits per tipus. És petit i toca cues, webhooks, idempotència i observabilitat alhora.

3. Afegir un panell d'administració amb estadístiques en viu. Mètriques d'ocupació per sala i esdeveniment amb agregacions (M7), servides per SSE —no WebSocket: el flux és d'un sol sentit, i aplicar aquí l'elecció del 12-01 a l'inrevés és un exercici de criteri excel·lent— i posades a la memòria cau a Redis amb invalidació per venda.

4. Tancar la llista de comprovació del punt 2 sobre el teu propi projecte. Sense codi nou, o gairebé. Audita'l punt per punt, escriu el que falta, i arregla els tres més greus. És l'ampliació menys vistosa i la que més t'ensenyarà.

• Confondre «funciona» amb «està a punt». Que la funcionalitat respongui és el principi de la feina, no el final. La llista del punt 2 és la diferència.
• Triar tecnologia per popularitat. La pregunta no és què és modern, sinó quin problema tens i què costa desfer l'elecció.
• Optimitzar sense mesurar. Tot el del M10 comença amb un número: p99, perfil, gràfic de flama. Sense mesura, optimitzar és superstició.
• Afegir complexitat «per si de cas». Microserveis, cues distribuïdes o memòria cau en cinc nivells abans de tenir el problema és deute tècnic pagat per avançat i sense haver rebut el préstec.
• Copiar d'una resposta d'internet sense entendre-la —o d'un assistent d'IA—. Si no pots explicar per què funciona, no ho pots arreglar quan falli. I fallarà.
• No documentar les decisions. El cost no el pagues avui, el paga el teu jo d'aquí a dos anys.
• Consell final: el millor codi que escriuràs és el que una altra persona entén sense preguntar-te res. Noms clars, funcions curtes, dependències injectades i errors explícits guanyen sempre a la genialitat compacta.

Aquests exercicis són de síntesi: no hi ha una única resposta correcta, i el valor és en el procés.

1. Auditoria del teu propi projecte. Agafa el projecte del mòdul 12 que més t'hagi interessat i recorre'l sencer amb la llista de comprovació del punt 2. Marca cada punt com a complert, parcial o absent. Després ordena el que és absent per risc (probabilitat × impacte) i escriu un pla de tres accions concretes.

2. Escriu un ADR d'una decisió del curs. Tria'n una: MongoDB davant de PostgreSQL per al magazín, posicions fraccionàries davant de LexoRank, WebSocket davant de SSE per al suport, o confirmar el pagament per webhook en comptes de pel retorn del navegador. Redacta'l amb el format del punt 3, incloent-hi alternatives descartades i conseqüències negatives assumides.

3. Planifica una de les quatre ampliacions. Tria'n una del punt 8 i escriu-ne el pla: abast, el que queda explícitament fora, riscos, ordre de treball i com sabràs que està acabada.

1. Auditoria — quin aspecte té una de ben feta

No n'hi ha prou amb una llista de caselles. Un resultat útil d'aquesta auditoria és una taula de risc prioritzat:

Les tres accions del pla: (a) proves d'autorització a tots els llistats; (b) restauració de còpia provada amb calendari; (c) temps límit i alerta de símptoma al flux de pagament. Fixa't que cap no és una funcionalitat nova i totes tres redueixen risc real.

2. ADR — exemple resolt

3. Pla d'ampliació — exemple amb la migració a TypeScript

• Abast: src/domini, src/serveis i src/repositoris de l'eina de tasques, amb strict: true.
• Fora d'abast: controladors i proves (segona fase); no es canvia cap funcionalitat.
• Riscos: tipus de Sequelize costosos d'escriure; temptació de fer servir any i perdre tot el benefici.
• Ordre: (1) tsconfig.json amb allowJs i checkJs; (2) tipus del domini (Tasca, Espai, Pertinenca, estats com a unions literals); (3) funcions pures; (4) repositoris amb tipus de retorn explícits; (5) construcció a CI.
• Acabat quan: tsc --noEmit passa sense errors, no queda cap any explícit al domini, totes les proves continuen verdes i CI compila abans de provar.

Fixa't en l'elecció de l'ordre: es comença pel domini perquè és on els tipus aporten més i on menys infraestructura cal tipar. Començar pels controladors és l'error habitual i el que fa abandonar la migració.

Aquí s'acaba el curs.

Vas començar instal·lant Node i executant un fitxer amb tres esdeveniments dins d'un array. Acabes amb una plataforma completa —catàleg, aforament sense sobrevenda, autenticació amb refresc rotatori, temps real, comerç amb pagaments, contingut, col·laboració interna, cues, memòria cau, proves, contenidors i desplegament automàtic— i, més important, amb els criteris per decidir què construir, què no construir i què comprovar abans que algú en depengui.

Si hi ha una idea que convé que quedi per damunt de totes les altres, és aquesta: les eines canvien i els criteris perduren. Express donarà pas a un altre framework, Mongoose i Sequelize a altres ORM, i alguna de les llibreries d'aquest curs haurà quedat obsoleta abans del que sembla. El que no caduca és saber per què el preu es congela a la comanda, per què l'estat local deixa de valer tan bon punt hi ha dos processos, per què l'autorització s'empeny a la consulta, per què un reintent exigeix idempotència i per què una còpia de seguretat que no s'ha restaurat no és una còpia de seguretat. Això ho has après construint, que és l'única manera com s'aprèn de debò.

Ja no necessites aquest curs. Necessites un problema que t'importi i temps per equivocar-t'hi. Escriu codi, posa'l davant d'usuaris, mira'l fallar, arregla'l i torna a començar. Aquest bucle —el mateix que has recorregut dotze vegades amb Escena Viva— és tot l'ofici.

Bon viatge.