Di tanto in tanto mi capita di buttare giù due righe in PHP e scrivere dei package “ispirati” a qualcosa che ho visto a lavoro, o di cui magari ho avuto necessità nella stesura di questo o quel side-project. Qualche giorno fa, a lavoro, mi sono ritrovato a parlare con un collega del Circuit Breaker pattern, di cui si può trovare un’ottima spiegazione qui.
Circuit What?
Niente di complesso, ad essere onesti. Fondamentalmente si tratta di un pattern grazie al quale è possibile, in parole poverissime, “wrappare” una funzione/oggetto in modo tale da poterne monitorare lo “stato di servizio”. Per capirci meglio facciamo un esempio:
- immaginiamo di avere un’integrazione con un gateway di pagamenti per il nostro store/applicazione;
- in caso di malfunzionamenti abbiamo un meccanismo di fallback, che ci permette di segnare gli ordini che non possono essere processati se il gateway è giù;
Implementando un circuit breaker monitoriamo l’esito delle chiamate al gateway di pagamento. Se più di X chiamate in un certo periodo T non vanno a buon fine, allora possiamo marcare per un certo lasso di tempo il nostro gateway come “failed” ed usare direttamente il meccanismo di fallback, senza dover aspettare tutte le volte il gateway che, sappiamo, ormai è andato.
Abbiate pazienza, è sabato sera e non ho una gran fantasia.
Interessante! Cosa c’entra con Laravel?
C’entra perché chiunque può sviluppare la propria “versione” di un circuit breaker. Nel mio caso, ho deciso di creare un package per Laravel (dalla 5.6 in poi) che mi permetta di realizzare velocemente una cosa del genere.
Il package è già pronto: si può trovare tranquillamente su GitHub e lo si può installare con un semplice
[code lang=”bash”]$ composer require francescomalatesta/laravel-circuit-breaker[/code]
Non scriverò un tutorial su come usarlo perché non apprezzo ripetermi, però su Github ho messo tutto l’indispensabile per giocarci senza problemi.
Riporto giusto quelle che penso siano le feature più interessanti:
- la possibilità di specificare in file di configurazione tutti i vari parametri (numero di tentativi prima di dichiarare un servizio “failed”, finestra temporale entro la quale questi x tentativi devono avvenire, quanto tempo il servizio rimane nello stato “failed”);
- se una definizione “generica” di questi parametri non basta, è possibile anche specificare questi parametri per un singolo servizio, attraverso una “mappa” nel file di configurazione;
- il package è ovviamente compatibile con il servizio di auto-discovery, quindi non bisogna più aggiungere service provider ed alias;
Ho già in mente alcuni miglioramenti aggiuntivi, li ho riportati nel file readme e ci metterò le mani appena mi sarà possibile. Se invece siete più veloci, beh… aprite una PR! 🙂
Have fun!
