Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene e benvenuti, ventunesimo episodio di GITBAR, io sono Brenreppo e oggi vi accompagnerò nel mondo del PHP asincrono.Ebbene sì, dopo 21 episodi ritorniamo diciamo al linguaggio che è stato il linguaggio del nostro primo episodio e lo faccio con tanto piacere visto che PHP è stato per lungo tempo il mio primo linguaggio di programmazione, quello che ho utilizzato di più nella mia vita lavorativa e devo dire che in questi ultimi anni sta accelerando in modo molto sostenuto il suo sviluppo e si sta facendo a mondi come quello della programmazione assincrona che prima erano anche solo impensabili quando si parlava di PHP.Ma prima di entrare nel dettaglio di questo episodio beh il mio compito è quello di ricordarvi i nostri contatti.Potete trovare tutte le informazioni del podcast comprese le puntate le note degli episodi nel sito www.gitbar.it potete inoltre scrivermi @brainrepo su twitter o a info@gitbar.it mi raccomando scrivetemi se c'è qualche argomento che volete approfondire o volete che ve ne parli o se volete darmi qualche suggerimento per come migliorare o implementare il podcast detto questo possiamo iniziare il mondo delle web application si è sviluppato a una velocità decisamente sostenuta però con tanta velocità si è anche sviluppato una certa impazienza nell'utente per ricevere le risposte in tempo reale buona parte delle risposte però non possono essere restituite con questa velocità questo per esempio perché in realtà in background a una nostra richiesta succedono tutta una serie di eventi che hanno bisogno del tempo.Il più delle volte sono eventi che riguardano chiamate API oppure apertura e scrittura all'interno di file o letture da database.Comunque sono delle operazioni input output e operazioni che in qualche modo fermano il calcolo del processore e bloccano in qualche modo la nostra applicazione.Uno di questi esempi può essere l'invio di un'email attraverso un pannello web.Immaginiamo di avere la nostra applicazione web che invia un email a un certo indirizzo.Durante l'invio dell'email, quindi il momento in cui la nostra applicazione comunica con il server di posta, magari attraverso un API, immaginiamo l'API di Gmail, beh la nostra applicazione sarà bloccata fin che l'invio della mail, quindi l'API, non ci danno una risposta e quindi si può continuare l'esecuzione.Questo perché in realtà il flow tradizionale delle applicazioni gira step by step.Cosa vuol dire? Che prima viene eseguita un'operazione e al termine di questa viene eseguita quella successiva.Questo tipo di flow tradizionale nel caso in cui ci sono diverse operazioni di input output, quindi lettura e scrittura, si rallenta in modo significativo.Questo perché in realtà una CPU processa un'istruzione per volta, un blocchetto per volta e quindi passa a quello successivo una volta che è terminato quello precedente.Cosa succede? Che se nel blocco N ci sono tutta una serie di letture e scritture o comunque tutta una serie di operazioni di input output, il processore rimarrà fermo in attesa della conclusione appunto di queste operazioni.Questo tempo in realtà in cui il processore non fa niente è in qualche modo tempo perso per cui si è pensato di trovare delle soluzioni per l'esecuzione di codice asincrono quindi per fare in modo che a ogni richiesta di operazioni input output non si blocchi il processore e quindi si possa iniziare il calcolo di un task successivo, di un compito successivo.Per farlo però è necessario approfondire il concetto di sincrono e asincrono.Una delle soluzioni appunto per rendere il nostro codice più performante è quella di eseguire tra virgolette più task contemporaneamente o quasi contemporaneamente.Per arrivare a questo concetto è necessario fare una distinzione tra ciò che è sincrono e ciò che è asincrono.Quando si parla di sincrono o asincrono si parla solitamente di modelli di programmazione.Una cosa molto importante tra l'altro è uno degli argomenti che ritorna più spesso nelle interview di lavoro e spesso lo si confonde con programmazione concorrente o parallela.Qua stiamo semplicemente ragionando in termini di sincronicità dell'esecuzione quindi in questo momento prendiamo in considerazione solo due concetti la sincronicità o la sincronicità quando si parla di sincroni di programmazione di modello di programmazione sincrona beh si parla di un modello di programmazione che è top down quindi esegue le istruzioni blocco per blocco step by step quando è terminato il primo step si passa allo step successivo.Questo modello di programmazione è anche detto modello di programmazione prevedibile.Cosa vuol dire? Che in qualunque momento dell'esecuzione del nostro codice noi sappiamo in che punto ci troviamo.L'alternativa a questo modello di programmazione è la programmazione asincrona dove il nostro codice viene diviso in task che possono essere eseguiti in modo concorrente.Cosa vuol dire? Che possono essere eseguiti e noi abbiamo la percezione che siano eseguiti contemporaneamente.Questo tipo di programmazione, lo stato dell'esecuzione non è prevedibile.Nel senso che, vi faccio un esempio molto semplice, una funzione che stampa A, una funzione che stampa B.Se queste funzioni vengono eseguite prima la prima che stampa A poi quella che stampa B in modo assincrono io avrò come esito AB.Se io dovessi eseguire in modo assincrono queste due istruzioni beh potrei avere BA o AB perché io non conosco l'ordine in cui queste due funzioni vengono eseguite.Se volessi farvi un esempio ancora più semplice tra la programmazione sincrona e quella asincrona può essere assimilata alla lettura di un libro.La programmazione sincrona è una lettura un po tipo come quella che facciamo quando leggiamo dei romanzi.Quindi leggiamo pagina per pagina, paragrafo per paragrafo e quando terminiamo un paragrafo passiamo al successivo.quindi in qualche modo ho sempre la bussola e so sempre in quale punto del libro mi trovo e quanto ne ho letto di quel libro.Diverso è con la programmazione asincrona.L'esempio tipico della programmazione asincrona è l'enciclopedia.Io posso iniziare a leggere un paragrafo che parla che ne so di programmazione, interrompere, approfondire che ne so leggendo di un paragrafo che tratta l'argomento dell'istruzione IF per poi ritornare al paragrafo di programmazione dopo aver letto appunto quello che trattava della IF.Questo saltare da un punto all'altro, interrompere e riprendere, beh, questo in qualche modo abbastanza similare, ecco, quello che è la programmazione asincrona oppure un'altra metafora può essere l'ipertesto.Quindi è molto importante distinguere questi due modelli di programmazione.Quindi sono due modi completamente diversi con i quali scriviamo il nostro codice.Dal suo canto invece PHP è un linguaggio di programmazione single thread.Per thread si intende il flusso di istruzioni di un processo e vuol dire che un'applicazione uno script PHP non può creare nuovi thread durante la sua esecuzione.Questo naturalmente out of the box, è possibile farlo con funzionalità come pit threads ma se si diciamo andate incontro a parecchi mal di testa in fase di configurazione e di lavoro.Quindi cosa vuol dire? Che php in realtà quando esegui un certo task, un certo compito, si blocca finché non appunto non sono concluse da una parte l'elaborazione del processore dall'altra tutte le richieste disposte dell'input output.Attenzione però che quando parliamo invece di web server quindi Apache e Nginx sono loro quelli che in realtà aprono creano più thread per dispatchare le tante richieste che possono arrivare al web server quindi tutta quella complessità di aprire tanti thread quante richieste appunto ci sono naturalmente con dei limiti per esempio con Apache i limiti della memoria no? quindi quella complessità è passata da linguaggio al web server che fa girare gli script.Questo appunto per la sua natura di PHP.Quindi detto questo è appurato che PHP è un linguaggio che ragiona in termini di thread singolo.Perché utilizzare PHP e come evolvere PHP per poter eseguire delle applicazioni non bloccanti quindi che non attendano che tutte le operazioni siano terminate per passare all'istruzione successiva.Beh, perché non utilizzare degli altri linguaggi come JavaScript che sono già "synchrony out of the box"? Beh, questo perché in realtà, prima guardavo la classifica di tiobe.com che è uno dei siti più affidabili che fa in qualche modo un ranking dei linguaggi di programmazione PHP ricopre dopo tantissimi anni ancora l'ottavo posto in classifica quindi una posizione molto alta e tantissimi siti di hosting supportano questo come linguaggio principale questo ha creato insomma un'adozione di massa quindi PHP è diciamo un linguaggio molto adottato dai programmatori specie, dai programmatori entry level vista appunto la sua curva d'apprendimento e quindi perché non utilizzare linguaggi come node o go che in realtà lo supportano attivamente? beh questo perché per esempio se si parla in ambiente enterprise di azienda un nuovo linguaggio all'interno del team può anche voler dire anzi vuole dire solitamente l'abbracciare un nuovo ecosistema e se il team è grande soprattutto non è agilissimo beh questo vuol dire insomma un certo sacrificio anche in termini economici e quindi più facile pensare a un tool per rendere il php asincrono che magari cambiare tutto lo stack.Questo ragionamento viene supportato anche dal fatto che php è un linguaggio che man mano che il tempo sta passando si sta dimostrando sempre più moderno e non si limita più solo al concetto di request e response che era un pilastro un pillar fondamentale appunto nel momento in cui il php è stato sviluppato perchè il php nasce per scrivere script web e la sua colonna portante era appunto che uno script web partisse da una richiesta e dovesse restituire una risposta e la finiva in qualche modo il ciclo di vita dell'applicazione dello script.Beh, oggi per esempio troviamo delle applicazioni a linea di comando che hanno delle durate molto lunghe, infatti sono delle long-living command line application e troviamo funzionalità come gli streams che hanno senza dubbio dato quei superpoteri al php per poter sviluppare delle applicazioni che vanno un pochino oltre le classiche applicazioni a richiesta a risposta.Diciamo che questi sono degli strumenti base per iniziare a pensare di poter applicare il modello della programmazione assincrona concorrente naturalmente all'interno del mondo PHP.Quando si parla di programmazione assincrona si può parlare di programmazione concorrente o parallela.Che cos'è la programmazione concorrente? Beh, senza dubbio è un tipo di programmazione dove noi non dobbiamo preoccuparci dell'ordine in cui vengono eseguite le operazioni.Perché? Perché in realtà verranno eseguite in modo da ottimizzare i tempi e quindi portarci al risultato in un tempo ridotto rispetto appunto alla programmazione sincrona.il concetto prevede che l'esecuzione di alcuni task possa essere bloccata per dare la precedenza all'esecuzione di compiti successivi per poi ritornare al task che avevamo sospeso e riavviarlo.Quindi mettiamo che noi stiamo che ne so avviando la scrittura di un certo risultato di un'operazione matematica all'interno di un file.Noi facciamo l'operazione matematica, lanciamo la scrittura.In realtà la scrittura è un'operazione di input output, quindi prevede l'utilizzo di risorse diverse dal processore.In questo caso questo processo durante l'esecuzione appunto delle operazioni di input output viene sospeso.Vengono eseguite tutta una serie di istruzioni.Nel frattempo, quando poi l'operazione di input output è terminata, le istruzioni seguenti all'operazione di lettura e scrittura all'interno del file verranno eseguite.Quindi in qualche modo quel tempo nel quale il nostro script, i nostri task successivi rimanevano in attesa perché le operazioni di input output, come vi ho detto prima, sono dispendiosi in termini di tempo, insomma questo tempo viene riciclato, riutilizzato per poter eseguire altre operazioni a livello di processore e quindi ottimizzare appunto il tempo per l'esecuzione di questi compiti.In questo caso il tipo di programmazione viene chiamato concorrente.L'esempio che faccio spesso è quello di partecipare a un contest dove si deve appunto mangiare un numero di hamburger significativo e contemporaneamente cantare.Alla vostra sinistra ancora una volta l'orgoglio dei camionisti d'America, l'imbattibile Red Barclay.E alla vostra destra Homer Nosok.Gli ottoni ai vostri posti.E ingozzatevi.Il premio di questo contest si ha per chi riesce a cantare completamente una canzone dall'inizio alla fine e contestualmente terminare anche 20 hamburger.Che voi cantiate la canzone per intero e poi iniziate a mangiare gli hamburger oppure cantiate metà canzone prima, mangiate gli hamburger e metà canzone dopo oppure una parola e un morso, beh, entrambi questi metodi sono da intendersi concorrenti quindi in realtà non importa come vengono eseguiti i task ma la cosa importante è appunto che non ci siano delle attese e che insomma gli hamburger e la canzone diciamo finiscano nel minor tempo possibile.Per programmazione parallela invece si intende quando due task sono eseguiti simultaneamente.Solitamente questo tipo di programmazione prevede l'utilizzo appunto di processori multicore quindi ogni processore esegue contestualmente una serie di istruzioni nello stesso tempo in cui un altro esegue delle altre ed è un po' come per tornare all'esempio di qualche secondo fa della gara appunto di mangiare hamburger e cantare è come che io mangio gli hamburger e uno di voi canta contestualmente una canzone quindi senza dubbio terminerà prima però c'è da dire che la programmazione parallela presuppone appunto la presenza dei processori multicore e l'accesso concorrente alle risorse per esempio in caso di lettura e scrittura e questo potrebbe essere un problema.Ma allora come possiamo portare il mondo della programmazione concorrente su un sistema single thread come vi dicevo prima che è quello appunto di PHP? Beh il cuore di ogni app asincrona è senza dubbio l'event loop è un pattern che presuppone che le azioni task siano inserite all'interno di una coda e che per ogni azione quindi per ogni evento ci siano tutta una serie di handler di maneggiatori di azioni collegate e quindi quando l'evento è scatta quindi viene triggerato l'handler quindi le collegate all'evento reagisce e quindi eseguono una serie di task.L'event loop rimane sempre in circolo essendo un for senza condizioni di uscita per cui non fa altro che prendere degli eventi e dispatciarli prendere degli eventi e dispacciarli.Se io ho un'operazione di input output durante il dispacciamento di un evento quindi l'esecuzione di una serie di compiti beh verrà in qualche modo avviato il compito sapendo che al termine di questo deve essere in qualche modo creato un altro evento che poi deve essere dispacciato e quindi il ciclo continua a girare anche se un evento è in attesa.Questa diciamo è una cosa che di sua natura javascript ha ed è presente ed è uno degli elementi che ha permesso per esempio al javascript di supportare, di poter appunto realizzare con con javascript quelle interfacce reattive dove per esempio al calcare di un bottone eseguono una serie di operazioni ma non bloccano l'esecuzione degli altri script della pagina.Beh in PHP di per sé questo concetto non esiste ed è stato introdotto con la realizzazione di una libreria chiamata ReactPHP.C'è da fare un piccolo avvertimento.Quando si parla di ReactPHP beh questo non ha nulla a che vedere con il mondo di React appunto legato al javascript ma si parla di una serie di tool scritte in puro PHP che ci permettono di realizzare le applicazioni assincrone appunto partendo dal PHP.Perché questo insieme di strumenti, questa libreria? Perché in realtà all'interno del linguaggio PHP mancano concetti come l'event loop, lo stream e le promises che invece sono elementi fondamentali alla base di qualunque sistema di tipo concorrente.Una Una cosa importante in realtà è che ReactPHP è una serie di componenti.Mi viene da pensare ai Symfony Components.Per chi sviluppa in PHP sa benissimo che è scritto in modo molto modulare dove i moduli sono abbastanza autonomi tra di loro e poi insomma c'è un codice colla che mette insieme tutti questi moduli per creare un framework.di pensare che molti dei moduli di symfony, i components di symfony, vengono utilizzati anche da altri framework come l'aravel.Questo perché appunto sono una serie di tool, un approccio che è stato preso anche da react php che ha sviluppato una serie di componenti che ci potessero permettere di sviluppare applicazioni in qualche modo concorrenti anche utilizzando un linguaggio che appunto non poteva per sua natura essere concorrente.C'è da dire che in realtà non ci sono grosse pretese dai components di ReactPHP, infatti noi possiamo sviluppare un'app completamente concorrente oppure prendere quei componenti e inserirli all'interno di una nostra funzione, una nostra libreria, per rendere magari concorrente quell'esecuzione.Un esempio semplice può essere, che ne so, io ho una web application, un controller che fa una serie di operazioni, beh all'interno di queste operazioni ci sono 3, 4, 5 chiamate a un API.Se io in qualche modo volessi fare queste chiamate API in modo concorrente potrei farlo utilizzando appunto l'event loop e le promises messe a disposizione da ReactPHP.Oltre all'event loop quindi altri due strumenti fondamentali messi a disposizione da ReactPHP sono le promises e gli streams.Cosa sono le promises? Partendo dal presupposto che il codice che noi andiamo a eseguire deve essere assincrono quindi in qualche modo deve reagire in modo assincrono a certe istruzioni noi dobbiamo in qualche modo istruire il nostro compito a come comportarsi una volta che quell'istruzione è portata a termine.Se avete programmato con javascript beh la cosa più semplice che vi viene appunto da pensare è le callback.Callback in realtà presenti in php dal momento in cui all'interno appunto di un parametro di una funzione io posso passare un'altra funzione quindi è possibile comunque fare utilizzare le callback però per chi ha esperienza col javascript beh sarà facile ricordare il tra virgolette callback mess che si viene a creare quando tante callback una dentro l'altra beh le promises è un modo per risolvere questo problema.In realtà cosa sono le promises? Le promises sono delle promesse.Sono delle promesse per qualcosa che deve essere eseguito in un momento successivo.Quindi sono in qualche modo un segno a posto per un risultato che arriverà dopo.E le promises hanno tre stati fondamentali.Pending, Rejected o Fulfilled.Cos'è pending? Cos'è lo stato di pending? lo stato di pending è quello stato in cui la promessa non è ancora stata risolta quindi in qualche modo noi non abbiamo un risultato dell'operazione che noi stiamo postponendo.Rejected è quando c'è stato un errore durante l'esecuzione appunto di quel codice che dovremmo andare a trattare in qualche modo full fillet è completata quindi quando la promises il segna posto per il risultato di un calcolo successivo quindi la promessa che ne stiamo facendo è stata completamente risolta e quindi eseguo le istruzioni successive.Tra l'altro una cosa molto importante è che le promises si possono accodare.Bene le promises sono uno strumento messo a disposizione di react php per semplificare lo sviluppo di applicazioni assincrone.L'alternativa? Beh ci sono una serie di librerie che utilizzano il concetto di coroutine però non abbiamo abbastanza tempo per approfondirlo ma nelle note dell'episodio metto i link per andare a leggere qualcosa riguardo appunto le coroutines.Un altro strumento messo a disposizione da react php sono gli stream.Sappiamo che uno dei problemi che rende le applicazioni lenti è appunto il tempo dovuto alle operazioni di input output che è decisamente maggiore del tempo di esecuzione nel processore delle operazioni.Tempi con i quali per esempio andiamo a impattare quando andiamo a leggere e scrivere dei file e se i file sono molto grandi abbiamo anche dei problemi in termini di memoria.Per ovviare a questo problema beh ReactPHP ci mette a disposizione dei tool riguardanti appunto gli streams questo perché in realtà le letture e le scritture nei file o nel database tipiche delle nostre applicazioni sono delle operazioni di tipo bloccante quindi bloccano l'esecuzione per cui se noi vogliamo realizzare un'app di tipo asincrono dovremo utilizzare delle librerie che vanno a leggere e scrivere i file a salvare nel database o a fare delle richieste ad altri endpoint http in modo assincrono.Per farlo appunto ci sono gli streams messi a disposizione da ReactPHP che non fanno altro che per esempio nel caso dei file di dividere in piccoli chunk, quindi in piccoli blocchetti il file che si intende leggere e scrivere e quindi permettere un accesso diciamo parziale al file.Tra l'altro esistono anche tutta una serie di strumenti che ci permettono appunto di utilizzare gli stream quando parliamo di storage quindi parliamo di lettura e scrittura nel disco, parliamo di network quindi chiamate ad http magari dove le risposte sono molto grandi abbiamo bisogno appunto di questo strumento letture e scritture a cache, log, code e quant'altro quindi diciamo che gli stream sono degli strumenti messi a disposizione da react PHP per poter interagire in modo non bloccante con quegli elementi che comunque prendono tempo nel momento in cui noi andiamo a interagire occupano grande parte del nostro tempo appunto di risposta.Quindi abbiamo capito che ReactPHP è un toolset, un insieme di librerie che ci permettono di sviluppare applicazioni a sincrone.Però queste librerie sono indipendenti, sono svincolate l'una dall'altra, potremmo utilizzarne magari alcune parti e non utilizzarne delle altre e quando si decide di sviluppare un'applicazione reattiva quindi asincrona partendo da zero beh potrebbe essere utile affidarsi a un framework chiamato drift php quindi se i tool sono una serie di strumenti quindi react php è una serie di tool beh i framework non sono altro che un modo per orchestrare organizzare questa serie di strumenti, di funzionalità per creare appunto un ecosistema che possa in qualche modo essere eseguito dall'inizio fino alla fine.Ed è quello che andiamo a fare utilizzando DriftPHP che prende e utilizza i paradigmi che ha il famoso framework Symfony ma li applica a un concetto di programmazione concorrente utilizzando i componenti appunto di react php per farlo deve sostituire alcuni elementi fondamentali di symphony in primis la http kernel noi sappiamo che symphony è basato sul concetto appunto di kernel che non fa altro che prendere una richiesta farla maneggiare da questo kernel e restituire una risposta noi abbiamo detto che questo tipo di approccio lo vogliamo comunque smontare per permettere l'esecuzione appunto di tipo asincrono.Per farlo, anche perché devo dire che l'esecuzione del kernel di Symfony è un'operazione bloccante, quindi per farlo DriftPHP ha dovuto in qualche modo riscrivere il suo kernel in modo che potesse funzionare anche con le promises, quindi con le operazioni di tipo non bloccante, asincrono.Un altro strumento che dobbiamo andare a sostituire è senza dubbio l'eliminazione di web server come Apache ed Nginx.Questa eliminazione diciamo che non ci servono più in questa fase perché in realtà la nostra applicazione di per sé non ha bisogno di un web server esterno perché si connette in modo nativo senza intermediari ai socket per poter rispondere ai client.Quindi diciamo che tutto quel livello potrebbe non essere più necessario.Un'altra cosa interessante che invece fa drift PHP è che è una cosa che mi piaciuto particolarmente mi ha catturato l'attenzione e che in realtà separa in modo stringente in modo significativo le operazioni riguardanti il dominio da tutto ciò che riguarda la platform e l'ecosistema.Quindi diciamo che DriftPHP è quel framework che ci permette di scrivere applicazioni asincrone partendo da zero, quindi quando vogliamo realizzare un'applicazione partendo da zero e ci dà tutta una serie di strumenti e di best practice quindi anche tutta la parte di orchestrazione per realizzare la nostra applicazione.useremo invece react php quando abbiamo qualcosa di veramente custom da realizzare oppure quando vogliamo implementare inserire delle azioni delle operazioni di tipo asincrono all'interno di applicazioni già esistenti.Di qui mi viene da pensare che da grandi poteri ne derivano altrettanto grandi responsabilità.Ricorda sempre, da un grande potere derivano grandi responsabilità.E infatti la programmazione asincrona in PHP non è un silver bullet, che possiamo usare in tutte le condizioni senza nessun lato negativo.Esistono comunque tutta una serie di side problem legate all'adozione di queste tecnologie.e il primo è legato al fatto che l'event loop deve sempre stare in circolo, deve sempre girare e non si può permettere appunto di bloccarsi questo presuppone che in realtà il programmatore debba fare molta attenzione, molta più attenzione sul codice che va a scrivere Non dico che non dovesse prestare attenzione prima quando l'applicazione era eseguita su un processo di tipo richiesta-risposta, ma comunque deve prestare attenzione, per esempio, all'utilizzo della memoria.Questo perché anche se c'è un buon garbage collector, e PHP ha un buon garbage collector, beh, nei processi lunghi la memoria si potrebbe saturare.Stesso problema che si ha anche quando si lavora con Node.js.per cui tutto ciò che riguarda la gestione della memoria in qualche modo non dico che debba essere preso in carico esclusivamente dal programmatore ma un minimo di sensibilità è necessaria da parte del programmatore quindi deve prestare particolare attenzione così come si deve prestare attenzione alla gestione delle eccezioni.Questo perché? Perché se prima il nostro ciclo di esecuzione era legato al processo richiesta risposta oggi abbiamo un event loop che gira per tutte le richieste e risposte per cui se per caso ci scappa un'eccezione un errore che noi non catturiamo e non gestiamo beh tutta l'applicazione si bloccherà rispondendo picche a tutte le richieste che sono state fatte in quel momento quindi non solo rendiamo impossibile l'utilizzo all'utente per il quale si è verificata quell'errore ma blocchiamo praticamente l'applicazione per tutti i nostri utenti.Inoltre il concetto di event loop fa sì che il processo di esecuzione PHP sia un un processo con vita molto lunga.Quando la vita del processo si allunga in modo così significativo, potrebbero capitare delle chiusure di connessioni inaspettate.Quindi è necessario magari monitorare le connessioni affinché queste rimangano attive e gestire le chiusure di connessione per esempio col database inaspettate.E sempre quando si parla di database devo dire che in realtà uno dei limiti ad oggi della programmazione concorrente o comunque assincrona con php è il fatto che comunque molte funzionalità di sistema esempio pdo o la lettura e la scrittura dei file così come tante librerie sono ancora scritte usando una concezione di tipo bloccante per cui in realtà spesso abbiamo appunto il problema di non avere delle librerie che girino in modo assincrono.È importante dobbiamo sempre tenere presente che gli handler, quindi diciamo le azioni da eseguire alla fine appunto di una chiamata asincrona, devono essere non devono essere bloccanti.Questo perché in realtà qualora fossero bloccanti bloccherebbero l'esecuzione di tutti gli altri task e quindi bloccherebbero non solo l'utente x che ha lanciato quell'operazione ma bloccherebbero anche tutti gli altri utenti che hanno dei task da eseguire e questo senza dubbio un problema quindi certo è che la programmazione assincrona porta php a un altro livello gli permette un miglioramento in termini di prestazione significativo ma con questo incremento di prestazioni ne viene anche tutto un pacchetto una serie di responsabilità che prima php si assumeva o in qualche modo evitava di far assumere al programmatore e che adesso invece sono tutte sullo zainetto sul carico dello sviluppatore per cui diciamo che ci sono anche dei contesti dove la programmazione sincrona può essere utile e dei contesti dove diciamo è un po' sovradimensionato utilizzare questo approccio.Spero che questo episodio vi sia piaciuto in realtà PHP è sempre stato il mio primo amore con tutti i suoi lati negativi e ce ne sono tanti ma anche i suoi lati positivi diciamo non fanno altro che col tempo aumentare sempre di più.E' uno di quei linguaggi che in realtà si sta evolvendo in modo molto rapido e sta in qualche modo mutando la sua natura in un modo altrettanto veloce.Senza dubbio l'introduzione della programmazione asincrona nel mondo di PHP riesce ad aprirgli le porte di tanti in tanti ambienti dove il PHP probabilmente non sarebbe stato utilizzato per compiere questo tipo di operazioni.C'è da dire che in realtà ReactPHP non è l'unica libreria per la realizzazione e l'utilizzo appunto di procedure di tipo asincrono.Esistono altre librerie come Swole o AMPPHP che permettono in modi diversi devo dire ma di raggiungere lo stesso obiettivo.inserirò anche i link magari a queste librerie nelle note dell'episodio.Detto questo e prima di salutarci beh mi devo ricordare i nostri contatti.Potete trovare tutte le informazioni sul podcast e su tutti gli episodi nel sito www.gitbar.it oppure potete scrivermi a info@gitbar.it o su twitter @brainrepo se l'episodio vi è piaciuto, aprite il vostro client di podcast preferito e iscrivetevi in modo da ricevere settimanalmente tutte le notifiche di pubblicazione dei nuovi episodi in modo da non rimanere indietro e se vi è piaciuto davvero tanto, aprite l'applicazione podcast di Apple o direttamente iTunes e se vi va naturalmente lasciate un commento con una recensione.questo in qualche modo ci aiuta a salire nelle classifiche di iTunes e a raggiungere più orecchie possibili.Detto questo io vi saluto e vi do appuntamento alla prossima settimana con un altro argomento interessante del mondo dei full stack developer.Da Leon è tutto, ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[MUSICA]
