Meta ha completato una delle modernizzazioni infrastrutturali più complesse del proprio stack di comunicazione real-time e ha portato WebRTC su una nuova architettura dual-stack già operativa in oltre 50 casi d’uso reali. Il progetto chiude una migrazione pluriennale nata per risolvere il cosiddetto forking trap, cioè la trappola tecnica che si crea quando un fork interno, ottimizzato per casi d’uso estremi, si allontana troppo dal ramo upstream e rende ogni aggiornamento sempre più costoso. Per anni Meta aveva mantenuto una versione interna altamente specializzata per Messenger, Instagram, Cloud Gaming e Meta Quest, ma la divergenza rispetto all’upstream Chromium rendeva i merge difficili, rischiosi e lenti. Con la nuova soluzione l’azienda può eseguire nello stesso binario la versione legacy e quella più recente di WebRTC, testarle in parallelo e aggiornare continuamente la libreria senza perdere le proprie ottimizzazioni proprietarie.
Cosa leggere
Meta risolve il forking trap di WebRTC senza riscrivere tutto
Il cuore della strategia Meta sta in una scelta architetturale precisa: evitare una riscrittura completa e costruire invece un sistema in grado di convivere con due versioni di WebRTC nello stesso ambiente applicativo. Per anni il fork interno aveva garantito performance elevate su miliardi di sessioni audio e video, ma aveva anche accumulato patch, correzioni, adattamenti hardware e cambiamenti locali che rendevano proibitivo il ritorno all’upstream. Ogni nuova release Chromium richiedeva merge manuali sempre più costosi, con rischio crescente di regressioni e debito tecnico strutturale. Meta ha quindi deciso di usare la versione più recente di libwebrtc come nuova base e di reintrodurre i propri moduli in modo controllato. L’obiettivo non era solo tornare aggiornati, ma costruire un modello che consentisse di restare sempre vicini all’head upstream anche negli anni successivi.
Lo shim layer unifica le API e abilita il dual-stack runtime
Per rendere possibile questa convivenza, il team ha introdotto uno shim layer che funge da proxy tra il codice applicativo e le due implementazioni di WebRTC. Lo shim espone una API unificata e indipendente dalla versione sottostante, in modo che il codice a livello prodotto non debba conoscere direttamente quale stack sia attivo. A runtime una configurazione globale, definita come flavor, decide se usare la versione legacy o quella aggiornata.
Questo meccanismo ha permesso a Meta di effettuare test A/B su larga scala senza duplicare tutta la logica di orchestrazione delle chiamate. Gli sviluppatori possono così instradare traffico reale verso i due stack in parallelo, confrontare comportamento, stabilità e consumo risorse, e migrare gradualmente i call site più critici senza interrompere l’esperienza utente.
Il renamespacing evita collisioni C++ nel monorepo di Meta
Uno dei problemi tecnici più difficili da risolvere riguardava il linking statico di due copie di WebRTC nello stesso spazio di memoria. In un monorepo C++, questa scelta viola la One Definition Rule e genera migliaia di collisioni di simboli, namespace e macro. Meta ha affrontato l’ostacolo con uno script automatico di renamespacing che trasforma i namespace della versione legacy in webrtc_legacy:: e quelli della versione upstream in webrtc_latest::.
Dove necessario sono state rinominate anche funzioni globali e macro C. Questa soluzione permette di collegare nello stesso binario due implementazioni potenzialmente incompatibili senza conflitti diretti. Per mantenere però il comfort degli sviluppatori, Meta ha usato dichiarazioni using del C++ che reimportano il namespace scelto nel familiare webrtc::, così il codice esistente continua a sembrare identico mentre la scelta della stack resta trasparente.
Adapter, converter e template riducono la duplicazione della logica
Il dispatch tra i due stack non avviene con un semplice toggle, ma attraverso adapter direzionali e converter che traducono tipi, struct e chiamate tra shim e implementazioni concrete di WebRTC. La logica comune è scritta una sola volta grazie all’uso di template C++, mentre le specializzazioni gestiscono il comportamento specifico di ciascun flavor. Questo approccio limita la duplicazione e rende il sistema più manutenibile nel tempo.
Allo stesso modo Meta ha condiviso moduli comuni come rtc_base per ridurre la dimensione binaria e abbassare la superficie da shimmare. Invece di gonfiare il binario di circa 38 MB, come sarebbe avvenuto con una duplicazione completa delle dipendenze, il team ha contenuto l’aumento a soli 5 MB, con un risparmio dell’87 percento. È un risultato importante perché su scala mobile anche pochi megabyte incidono su distribuzione, cache, aggiornamenti e footprint complessivo delle app.
I branch dedicati separano le patch proprietarie dall’upstream
Per gestire le personalizzazioni proprietarie senza perdere la storia Git e la possibilità di contribuire upstream, Meta ha costruito un flusso parallelo basato su un repository Git dedicato e allineato all’upstream di libwebrtc. Per ogni release Chromium viene creato un branch base, mentre ogni patch interna, come strumenti di debug o fix hardware per codec, vive in un proprio branch feature. Durante ogni upgrade tutti i branch feature vengono portati avanti, i conflitti vengono risolti e i test eseguiti separatamente, prima di combinare tutto in un candidato finale di release. Questo approccio rende il processo più parallelo, più auditabile e più compatibile con future automazioni. Invece di avere un grande fork monolitico difficile da comprendere, Meta spezza il proprio valore proprietario in componenti modulari che possono essere mantenuti, riapplicati o eventualmente upstreamati con molto più controllo.
Da M120 a M145 con upgrade continui e miglioramenti misurabili
La nuova stack webrtc/latest è partita dalla versione M120 e in tempi rapidi è arrivata fino a M145, segnale che il modello di upgrade continuo funziona davvero. I benefici tecnici sono concreti e misurabili. Meta riporta una riduzione dell’uso della CPU fino al 10 percento, un miglioramento del crash rate fino al 3 percento sulle app principali e una riduzione della dimensione binaria compressa compresa tra 100 e 200 KB a seconda dell’applicazione.
Oltre a questo, l’azienda ha eliminato librerie deprecate come usrsctp e ha chiuso vulnerabilità di sicurezza che erano rimaste nella vecchia stack legacy. In un ecosistema che gestisce miliardi di minuti di audio e video ogni giorno, anche miglioramenti apparentemente piccoli generano un impatto enorme su costi infrastrutturali, durata batteria, fluidità dell’esperienza e qualità percepita dagli utenti finali.
Meta prepara una manutenzione WebRTC sempre più AI-driven
La modernizzazione di WebRTC non si ferma all’architettura dual-stack. Meta guarda già alla prossima fase, in cui parte della manutenzione sarà supportata da agenti AI-driven capaci di correggere errori di build, assistere nei rebasing e risolvere automaticamente la maggior parte dei conflitti di merge più ripetitivi. Gli ingegneri resterebbero così focalizzati solo sui cambiamenti architetturali più complessi o sulle patch più delicate. Questa direzione è coerente con l’intero progetto: ridurre il costo umano delle operazioni ripetitive e costruire una pipeline di aggiornamento quasi continua, in cui la distanza dall’upstream non torna mai a diventare pericolosa. In sostanza Meta sta trasformando WebRTC da fork pesante e difficile da mantenere a piattaforma aggiornata, testabile e modulare, con la possibilità di assorbire rapidamente i benefici della community Chromium senza rinunciare alle proprie ottimizzazioni.
La migrazione di Meta diventa un modello per l’industria real-time
Il valore di questa operazione va oltre il caso Meta. Molte grandi aziende cadono nello stesso forking trap quando adattano librerie open source critiche ai propri bisogni di scala, performance o sicurezza. Il progetto dual-stack su WebRTC dimostra che è possibile uscire da quella trappola senza riscrivere tutto e senza sacrificare anni di lavoro proprietario. La combinazione di shim layer, renamespacing, dispatch runtime, branch separati e A/B testing su scala reale offre un blueprint molto concreto per chi lavora in monorepo complessi e deve riallinearsi all’upstream senza fermare prodotti già in produzione. Per Meta il risultato è una base RTC più moderna, sicura e manutenibile. Per l’industria, è un caso di studio importante su come modernizzare infrastrutture core in ambienti enterprise senza downtime e senza compromessi prestazionali.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
