Imagina que la teva aplicació backend fa una crida a una API externa per obtenir dades crítiques. De sobte, aquesta crida mai respon. L’usuari es queda esperant, el servidor consumeix recursos i l’experiència es deteriora. Aquest problema, conegut com a 'crida penjada', és més comú del que sembla i pot convertir-se en un maldecap tècnic i de negoci. En aquest article explorarem una solució elegant i efectiva: el timeout wrapper. A més, veurem com aplicar-lo correctament per evitar fuites de recursos i garantir la resiliència dels teus sistemes.
Quan desenvolupem aplicacions modernes, especialment aquelles que integren serveis externs, bases de dades o APIs de tercers, les crides de xarxa són inevitables. Tanmateix, la xarxa no sempre és fiable. Un servidor remot pot trigar més del previst, un tallafoc pot bloquejar la connexió o simplement el servei pot estar caigut. Sense un mecanisme de control, la nostra aplicació quedarà esperant indefinidament, bloquejant fils d’execució i acumulant memòria. És aquí on el timeout wrapper es converteix en un aliat indispensable.
El concepte és senzill: en fer una crida asíncrona, en lloc d’esperar sense límit, establim un temps màxim d’espera. Si la resposta no arriba dins d’aquest període, el wrapper cancel·la o ignora l’operació i permet que el flux principal continuï. Però no totes les implementacions de timeout són iguals. Hi ha dos enfocaments principals que resolen el mateix problema de maneres molt diferents.
El primer enfocament utilitza Promise.race. Consisteix a crear una promesa que es rebutja després d’un temps determinat i competir contra la promesa original. La que resolgui primer guanya. Si el timeout guanya, obtenim un error i el podem gestionar. Tanmateix, la promesa original (la crida de xarxa) continua executant-se en segon pla. El socket roman obert, la memòria segueix ocupada i els recursos del servidor es consumeixen fins que l’operació acaba. Això pot provocar fuites de recursos en sistemes amb moltes peticions concurrents. És una solució ràpida, però no neta.
El segon enfocament empra AbortController, una API nativa en navegadors i Node.js dissenyada específicament per cancel·lar operacions asíncrones. En crear un controlador i associar-lo a la crida fetch mitjançant el senyal, podem avortar físicament la sol·licitud si el temps d’espera s’esgota. Això tanca el socket, allibera la memòria i atura el consum de CPU. És una solució molt més robusta per a crides HTTP. A més, és important netejar el temporitzador amb clearTimeout per evitar fuites addicionals.
Quan utilitzar cadascun? Si treballes amb fetch o qualsevol API que suporti AbortController, opta per la segona opció. Si operes amb bases de dades, lectures de fitxers o altres promeses que no tenen suport natiu de cancel·lació, la primera opció (Promise.race) és vàlida, però has de ser conscient que l’operació continua en segon pla. En sistemes crítics, això pot acumular-se i degradar el rendiment.
A Q2BSTUDIO, entenem la importància de construir programari robust des de la base. Per això, en els nostres projectes de aplicacions a mida integrem patrons com el timeout wrapper per garantir que les aplicacions responguin ràpid fins i tot davant fallades de xarxa. A més, en treballar amb serveis al núvol a AWS i Azure, implementem timeouts configurables que s’ajusten dinàmicament segons el comportament històric de cada endpoint, millorant l’experiència de l’usuari i optimitzant l’ús de recursos.
La ciberseguretat també es beneficia d’aquests patrons. Una crida penjada pot ser utilitzada com a vector d’atac per esgotar recursos del servidor (denegació de servei). En cancel·lar les connexions lentes o sospitoses, reduïm la superfície d’atac. A Q2BSTUDIO apliquem mesures de ciberseguretat que inclouen timeouts estrictes en totes les integracions externes.
En l’àmbit de la intel·ligència de negoci, els nostres sistemes de BI i Power BI consulten bases de dades i APIs constantment. Un timeout wrapper evita que un dashboard es quedi carregant per sempre, oferint a l’usuari un missatge clar en lloc d’una pantalla en blanc. I els agents d’IA que desenvolupem poden monitoritzar el rendiment de les crides i ajustar automàticament els timeouts basant-se en patrons de latència, fent el sistema més intel·ligent i resilient.
Implementar un timeout wrapper no és complicat, però requereix entendre les implicacions de cada enfocament. La diferència entre 'ignorar la resposta' i 'cancel·lar l’operació' pot marcar la diferència en un entorn d’alta concurrència. Si la teva aplicació gestiona centenars o milers de peticions per segon, cada recurs no alliberat s’acumula i pot col·lapsar el servidor.
Per acabar, t’invito a revisar les teves pròpies integracions. Estàs gestionant timeouts en totes les teves crides de xarxa? Utilitzes Promise.race o AbortController? La resposta correcta depèn del context, però sempre és millor tenir un timeout que no tenir-lo. A Q2BSTUDIO ajudem empreses a optimitzar els seus sistemes amb aquestes pràctiques, combinant desenvolupament de programari a mida, núvol, IA i ciberseguretat per crear solucions que funcionin fins i tot quan la xarxa falla.
Un petit detall tècnic pot evitar grans problemes. No subestimis el poder d’un timeout ben implementat. La teva aplicació, els teus usuaris i la teva infraestructura t’ho agrairan.
