Come passare da REST a GraphQL senza riscrivere il frontend
Decine di servizi cambiano contratto. Il frontend che li usa deve cambiare nello stesso giorno?
Il rischio di una migrazione di API sta nel fatto che ogni consumatore del vecchio contratto deve cambiare insieme ai servizi. Se i consumatori sono un sito, una prenotazione online e un'app, la migrazione diventa un rilascio coordinato di più team, tutto nello stesso giorno.
La decisione
Un gateway davanti ai servizi, che espone al frontend esattamente il contratto che già conosce, con gli stessi percorsi, gli stessi codici di errore, gli stessi casi limite, e dietro risolve sul nuovo schema GraphQL. Il frontend continua a chiamare quello che chiamava. Quello che cambia è chi risponde.
Il pattern ha un nome, strangler fig con strato anticorruzione, e una regola di lavoro che conta più del nome: ogni handler si porta uno a uno, senza migliorare niente durante il trasporto. Anche un comportamento discutibile, come un tentativo ripetuto su più settimane, si replica tale e quale, perché era parte del contratto. Le migliorie vengono dopo, con il vecchio già spento.
Cosa rende il passaggio sicuro
Tre cose. La base del gateway impostata prima dei domini: struttura, resolver, log con contesto, gestione dei token e degli errori, così che chi aggiunge un endpoint segua una forma già decisa. La parità verificata per ogni handler, sulle risposte reali. E la revisione incrociata su tutto ciò che firma o autentica: è in revisione che un handler migrato in perfetta parità si è rivelato firmare i token con una chiave simmetrica, ed è passato a chiavi asimmetriche prima di arrivare in produzione.
Con il gateway in piedi, ogni dominio successivo costa meno del precedente. Il vecchio proxy si spegne un handler alla volta, e nessuno se ne accorge dal frontend. È il risultato che si vuole.
Descrivici il sistema. Ti diciamo cosa vediamo.
Dieci minuti, una domanda alla volta. Alla fine, la nostra lettura onesta del caso. È il filtro, prima ancora della call.