En el desenvolupament d' aplicacions modernes, especialment aquelles que depenen de múltiples fonts de dades externes, la gestió correcta de promeses concurrents pot marcar la diferència entre un sistema robust i una experiència frustrant per a l' usuari. És habitual trobar-se amb equips que utilitzen Promise.all per llançar diverses peticions simultànies, sense aturar-se a pensar què passa quan una d'elles falla. La resposta és simple: tot el bloc es rebutja. En escenaris on la decisió parcial és acceptable, aquesta decisió pot provocar que una única API lenta o un error temporal enderroci completament un dashboard, una pàgina d'inici o fins i tot un flux crític de negoci.
Per afrontar aquesta realitat, JavaScript ofereix tres alternatives que convé conèixer a fons: Promise.allSettled, Promise.any i Promise. Cadascuna resol un problema específic de concurrència i tolerància a fallades, i triar l' adequada és una competència essencial per a desenvolupadors que busquen construir aplicacions a mida amb alta disponibilitat.
Imaginem un panell d'indicadors corporatius que necessita mostrar vendes, mètriques d'usuari, alertes de ciberseguretat i dades d'inventari. Si utilitzem Promise.all i l'API d'alertes respon amb un error 500, la resta dels widgets no rebran dades. L'usuari veurà una pantalla en blanc o un missatge genèric d'error. Aquest comportament és incoherent amb l' expectativa que cada component funcioni de forma independent. Aquí entra en joc Promise.allSettled: espera que totes les promeses acabin —ja sigui amb èxit o amb fallada— i retorna un arrelament amb l'estat de cadascuna. El desenvolupador pot llavors tractar cada resultat per separat, mostrant el widget correcte o una indicació d' error parcial. Aquest patró és especialment útil en solucions de serveis intel·ligència de negoci i Power BI, on un panell ha de continuar sent operatiu fins i tot quan alguna font de dades no respon.
Un altre cas d'ús freqüent apareix en entorns amb múltiples servidors o CDNs. Suposem que necessitem obtenir la resposta més ràpida entre diversos endpoints duplicats per garantir una baixa latència en la càrrega de recursos crítics, com models d'intel·ligència artificial o dades per a agents IA. Promise.any és l'eina indicada: resol amb la primera promesa que es compleix satisfactòriament, ignorant els rebuigs previs. Només si totes fallen es produeix un error agregat. Aquest enfocament és ideal en arquitectures multiregió amb serveis cloud aws i azure, on es busca maximitzar la disponibilitat sense penalitzar el rendiment. Per contra, Promise.race es dispara amb la primera promesa que es completi —sigui èxit o error— i s'empra típicament per implementar timeouts. Per exemple, en llançar una petició a un servei extern, podem combinar-la amb una promesa que rebutgi després d'un temps límit, protegint així l'experiència de l'usuari i evitant esperes indefinides. En projectes de ciberseguretat i pentesting, aquest patró ajuda a controlar la durada d'escanejos o proves de penetració.
No obstant això, Promise.all no ha de ser demonitzada. Continua sent l' elecció correcta quan es requereix atomicitat: per exemple, en realitzar una operació que ha d' escriure en tres bases de dades diferents i la decisió de la qual ha de provocar un rollback complet. En transaccions financeres o en l' actualització d' estats crítics dins d' un programari a mida, la coherència global és més important que la disponibilitat parcial.
La clau està a preguntar-se: ¿puc acceptar que una part falli sense que la resta es vegi afectat? Si la resposta és sí, Promise.allSettled o Promise.any són les teves aliades. Si necessites la primera resposta —sense importar la seva naturalesa— utilitza Promise. En Q2BSTUDIO, desenvolupem ia per a empreses i aplicacions que integren aquestes tècniques per oferir sistemes resilients, escalables i centrats en l'usuari. L' elecció del mètode de concurrència no és un detall menor: és una decisió de disseny que impacta directament en l' experiència final i en la robustesa del producte. Conèixer a fons les quatre promeses i aplicar-les segons el context permet construir aplicacions que s' adapten a entorns reals, on les fallades no són excepcions, sinó part del paisatge.
