La temptació de canviar el runtime d' una aplicació en producció és comprensible. Quan es prometen instal·lacions en segons, reducció de memòria i arrencades més ràpides, molts equips es llancen a la migració. Tanmateix, la realitat és que el salt de Node a Bun, o a qualsevol entorn alternatiu, pot amagar fallades silencioses que passen desapercebudes durant setmanes. Aquest article analitza què passa quan un canvi aparentment innocu trenca la comunicació amb serveis crítics, i ofereix lliçons pràctiques per evitar-ho.
Imaginem un servei intern que corre sobre Kubernetes, a GKE, i que es comunica amb l'API de Kubernetes per gestionar infraestructura. Tot funciona correctament amb Node. Un dia, l'equip decideix migrar a Bun per accelerar els builds en CI. Els tests passen, l'staging respon bé, i es desplega a producció. Els beneficis són reals: les instal·lacions passen de minuts a segons, la imatge és més lleugera i el consum de RAM baixa. Però una setmana després, una funcionalitat que llista recursos del clúster comença a retornar llistats buits. No hi ha errors 500, no hi ha caigudes, només respostes buides. Després de revisar logs, apareix un error TLS: la verificació del certificat de l'API server falla.
El problema és que el clúster fa servir una CA pròpia, i perquè el client de Kubernetes hi confiï, es necessita passar la CA a través d'un agent HTTPS personalitzat. A Node, la llibreria @kubernetes/client-node construeix un https. Agent amb la CA i ho passa a node-fetch mitjançant l' opció agent. A Bun, aquesta opció no té efecte. No llança cap warning, cap error. Simplement la ignora. Les peticions surten sense la CA, falla la verificació TLS, i la llibreria reporta un error genèric de connexió. Des de la perspectiva de l'aplicació, l'API de Kubernetes és inabastable. La decisió és silenciosa perquè la configuració sembla aplicar-se, però el resultat es manifesta dues capes més avall, disfressat de problema de certificats.
El més frustrant és la dificultat de depurar. Es verifiquen els arxius muntats al pod, es prova amb NODE_EXTRA_CA_CERTS, es reinicia el servei, però res funciona. No hi ha una documentació clara de fins a quin punt Bun respecta aquesta variable d'entorn. L'equip es troba en un carreró sense sortida perquè ningú executa Bun localment: tots fan servir Node per a desenvolupament i tests. El bug només apareix en l'entorn productiu. La lliçó és clara: si el runtime de producció és Bun, llavors tot el cicle de desenvolupament, incloent-hi scripts de prova i reproducció d'errors, ha de fer servir Bun. Un retret baix Node no demostra res sobre el comportament a Bun.
La solució final va ser reemplaçar la capa de transport de la llibreria client per node:https directament, passant la CA en les opcions de la petició. Bun respecta aquesta opció en la seva implementació de node:https, per la qual cosa el problema es resol. Però això implica renunciar a l'abstracció de la llibreria i escriure codi propi per a una funcionalitat que abans funcionava sense tocar-la. No és ideal, però permet tenir control total sobre el comportament de xarxa. L'alternativa hauria estat node-fetch o usar una versió anterior del client, però l'opció més segura va ser eliminar les capes ocultes.
Aquest cas il·lustra un patró recurrent: la promesa de ser un 'reemplaçament directe' només cobreix el camí feliç. Bun executa la majoria del codi JavaScript sense problemes, però els punts on es toca el sistema operatiu —TLS, sockets, processos fills, sistema d'arxius— poden comportar-se de manera diferent. I l'absència d'errors en temps de configuració fa que aquestes fallades siguin especialment perilloses. Per a equips que depenen de certificats corporatius, proxies corporatius, o configuracions de xarxa complexes, la migració a Bun comporta un risc alt de fallades silencioses.
Des d' una perspectiva empresarial, les lliçons d' aquesta història són aplicables a qualsevol decisió d' infraestructura. En Q2BSTUDIO, entenem que l'elecció del runtime, la biblioteca o la plataforma cloud no s'ha de basar únicament en benchmarks de velocitat. Cal avaluar com es comporta cada capa en l' ecosistema real de l' empresa. Per això oferim serveis de desenvolupament d'aplicacions a mida, on analitzem les necessitats específiques d'integració, seguretat i rendiment abans de recomanar un stack tecnològic. A més, la nostra experiència en serveis cloud AWS i Azure ens permet dissenyar arquitectures que minimitzen els punts cecs entre runtime i plataforma.
Un altre aspecte clau és la visibilitat. Les fallades silencioses com el TLS ignorat són difícils de detectar sense un monitoratge adequat. Les eines d'intel·ligència de negoci, com Power BI, poden ajudar a correlacionar mètriques de rendiment i errors, però no reemplacen la necessitat de proves exhaustives en l'entorn exacte de producció. La intel·ligència artificial per a empreses i els agents IA tenen un paper creixent en la detecció d'anomalies, però tot i així, la responsabilitat última recau en l'equip de desenvolupament de verificar cada punt de contacte amb el runtime.
Quan convé quedar-se a Node? Si l'aplicació depèn d'addons nadius, d'eines madures d'APM o profiling, o de polítiques de compliment que exigeixen comportaments TLS específics (com CA corporatives o FIPS), la migració a Bun no està justificada. També si l'equip no està disposat a executar Bun en tots els entorns (desenvolupament, CI, staging), perquè la divergència entre entorns és la principal font d'aquests errors. En canvi, per a serveis nous o amb poques dependències de baix nivell, Bun pot ser una opció excel·lent, sempre que es realitzi una verificació sistemàtica de cada opció de configuració de xarxa.
La conclusió és que cap eina és un reemplaçament directe perfecte. La migració a Bun va portar beneficis reals de velocitat i eficiència, però també va exposar una vulnerabilitat en la capa de comunicacions que no s'hauria detectat sense una incidència en producció. La solució no va ser abandonar Bun, sinó entendre els seus límits i adaptar el codi per treballar dins d'ells. En Q2BSTUDIO apliquem aquest mateix principi en cada projecte: no assumim compatibilitat, la provem. Ja sigui integrant serveis d'intel·ligència artificial, desenvolupant aplicacions a mida o assegurant la ciberseguretat de la comunicació entre serveis, sempre validem cada supòsit tècnic en l'entorn real on s'executarà.
En definitiva, la lliçó més valuosa d'aquesta història és que l'èxit d'una migració no es mesura pels tests verds, sinó per la capacitat de reproduir i resoldre les fallades que només apareixen en producció. I això requereix una disciplina de verificació creuada, un monitoratge fi i, sobretot, la humilitat d'acceptar que cap runtime és una caixa negra perfecta.
