Dipendere dal servizio di qualcun altro
Ogni servizio esterno che colleghi è una parte del tuo prodotto che non controlli e non puoi riparare. Va bene — purché tu l’abbia deciso apposta.
Collegare una API esterna è di solito il modo più rapido per ottenere una capacità, e sposta in silenzio una parte della tua affidabilità nelle mani di altri. Il lavoro sta nel decidere cosa succede quando quella mano scivola.
Decidi prima del disservizio cosa succede durante
Ogni servizio prima o poi cade, in un momento che non hai scelto. La domanda da chiudere mentre non c’è nulla di rotto: la tua funzionalità fallisce, si degrada o aspetta?
Fallire va bene per qualcosa di opzionale: una mappa che non si carica, un arricchimento che resta vuoto. Non va bene in un percorso di pagamento o di accesso, dove serve un’alternativa o un errore onesto che dica cosa fare. Un indicatore che gira senza mai concludersi è l’esito peggiore, perché insegna alle persone che è rotto il tuo prodotto, non quello altrui.
Le chiavi sono credenziali, non configurazione
Una chiave API è una password che per caso sta scritta in un file di configurazione, e viene trattata come configurazione perché sembra un’impostazione. Poi finisce nel repository, in una schermata, in una conversazione.
Tieni le chiavi fuori dal codice, usa una chiave distinta per ambiente così che un test non tocchi mai i dati reali, e ruotale quando se ne va qualcuno che vi aveva accesso. E dai a ogni chiave l’ambito più stretto offerto dal servizio: quasi tutte le API lo permettono, e quasi nessuno lo usa prima dell’incidente che glielo fa desiderare.
I limiti di frequenza e i tentativi che li peggiorano
La prima cosa che fa quasi ogni integrazione quando una chiamata fallisce è riprovare subito. Se il fallimento era un limite di frequenza, l’hai appena peggiorato, e una mattina intensa diventa un disservizio autoinflitto.
Riprova con un ritardo crescente, limita il numero di tentativi e poi fermati invece di ciclare. E non riprovare mai alla cieca una scrittura non idempotente: la versione classica di questo bug è un cliente addebitato due volte perché la prima chiamata era riuscita e si era persa solo la risposta.
Cambierà sotto di te
I servizi cambiano formati di risposta, ritirano endpoint e modificano i limiti, di solito annunciandolo in un posto che non stavi leggendo. L’integrazione che funziona da un anno non è stabile: è non testata dall’ultima volta che è cambiata.
Fissa una versione se il servizio la offre, iscrivi una persona reale agli annunci di modifica invece di una casella condivisa che nessuno legge, e tieni una piccola chiamata automatica quotidiana che ti avvisi quando la risposta smette di somigliare a com’era. Quest’ultima costa un’ora e trova la rottura prima di un cliente.
Domande frequenti
Cosa decidere prima di integrare un servizio esterno?
Cosa succede quando è giù: fallire, degradarsi o aspettare. Fallire va bene per qualcosa di opzionale; in un percorso di pagamento o accesso servono un’alternativa o un errore onesto.
Come vanno gestite le chiavi API?
Come credenziali, non configurazione. Fuori dal repository, una chiave per ambiente così i test non toccano dati reali, rotazione quando se ne va chi vi aveva accesso, e ambito il più stretto possibile.
Come devono funzionare i tentativi?
Con ritardo crescente e numero limitato, poi ci si ferma. Riprovare subito trasforma un limite di frequenza in un disservizio autoinflitto, e riprovare alla cieca una scrittura non idempotente addebita due volte.