Ciao, e benvenuto nella quarta puntata della decima stagione. Nelle scorse puntate abbiamo visto i linguaggi del server e il database che custodisce i dati. Ma man mano che le applicazioni crescevano, scriverle infilando pezzetti di logica dentro le pagine, alla buona, diventava un caos ingestibile. Serviva ordine, struttura, un modo condiviso di fare le cose. Oggi raccontiamo l'arrivo dei framework nel backend, e la grande rivoluzione culturale che portarono: l'idea che le convenzioni valgono più della libertà assoluta.
Ricordiamo il problema, perché è lo stesso schema che abbiamo visto per il frontend. All'inizio, la libertà totale dei primi linguaggi era una benedizione: potevi fare qualsiasi cosa, come volevi. Ma quando le applicazioni crescevano, e magari ci lavoravano più persone, quella libertà diventava una maledizione. Ognuno organizzava il codice a modo suo, mescolava logica e presentazione, ripeteva le stesse cose in modi diversi. Il risultato era un groviglio difficile da capire, da modificare e da mantenere. Riprendo l'ottava stagione: senza una disciplina condivisa, la crescita porta al caos. Serviva qualcuno che imponesse un ordine.
E l'ordine arrivò, a metà degli anni Duemila, con un framework che ebbe un impatto culturale enorme, ben oltre il linguaggio in cui era scritto. La sua idea rivoluzionaria aveva un nome quasi filosofico: la convenzione al posto della configurazione. Ti spiego cosa significa, perché è profondo. Invece di lasciarti decidere ogni minimo dettaglio su come organizzare l'applicazione, il framework diceva: c'è un modo giusto e condiviso di fare le cose, seguilo, e in cambio andrai velocissimo. Se sistemi le cose dove ci si aspetta che siano, il framework capisce da solo cosa fare, senza che tu debba spiegargli tutto.
Questa idea, apparentemente tecnica, era in realtà una piccola rivoluzione di pensiero, e vale la pena capirne la bellezza. Rinunciavi a un po' di libertà, quella di fare tutto a modo tuo, in cambio di un guadagno enorme: velocità, ordine, e il fatto che qualsiasi altro sviluppatore che conoscesse quel framework poteva aprire il tuo progetto e capirlo subito, perché era organizzato nel modo standard. La convenzione condivisa diventava un linguaggio comune tra sviluppatori. Riprendo un tema della prima stagione, quello del codice leggibile per gli altri: qui la leggibilità diventava una proprietà garantita dalla struttura stessa.
Insieme a questo, questi framework diffusero un modo ordinato di separare le responsabilità dentro l'applicazione, che merita di essere raccontato perché è diventato universale. L'idea era di tenere ben distinte tre cose che prima si mescolavano. Da una parte i dati e le regole su di essi. Dall'altra la presentazione, cioè come le cose vengono mostrate. E in mezzo, un coordinatore che riceve le richieste, mette in moto la logica giusta e sceglie cosa mostrare. Tenere separati questi tre ruoli rendeva l'applicazione molto più ordinata e comprensibile, perché ogni pezzo aveva un compito chiaro e uno solo. Questa separazione divenne il modo standard di strutturare un backend.
L'effetto di tutto questo sulla produttività fu strabiliante, e cambiò l'economia stessa dello sviluppo web. Cose che prima richiedevano settimane di lavoro paziente diventavano possibili in giorni, o ore, perché il framework offriva già pronte, in modo ordinato, tutte le operazioni comuni: gestire gli utenti, salvare e recuperare dati, validare i moduli, proteggere da certi attacchi. Non dovevi più reinventare queste ruote ogni volta. Potevi concentrarti su ciò che rendeva speciale la tua applicazione, lasciando al framework tutto il lavoro ripetitivo e già risolto. Nacque un'ondata di creatività e di nuove applicazioni, perché costruirle era diventato molto più rapido.
Voglio sottolineare come questo segni una tappa nella professionalizzazione del backend, un tema che attraversa la stagione. Con i framework, lo sviluppo lato server smetteva di essere un artigianato personale, dove ognuno faceva a modo suo, e diventava una disciplina con pratiche condivise, schemi riconosciuti, un modo professionale di lavorare. Emergevano modi di fare consolidati, buone pratiche, un vocabolario comune. Il backendista non era più solo uno che sapeva far girare uno script, ma un professionista che padroneggiava strutture e schemi collaudati. Il mestiere maturava, si dava regole, diventava trasmissibile e insegnabile.
E come sempre, per onestà, c'è anche un rovescio della medaglia, che riprende un tema di questo podcast. La comodità dei framework ha un piccolo pericolo: puoi imparare a usarne uno senza capire cosa fa davvero sotto. Il framework nasconde tanta complessità, e questo è meraviglioso finché tutto funziona; ma quando qualcosa si rompe in profondità, chi non conosce i fondamenti sottostanti si trova smarrito, incapace di capire cosa stia succedendo sotto la magia. Riprendo la prima stagione: i framework sono strumenti potentissimi, ma non sostituiscono la comprensione delle fondamenta. I migliori backendisti conoscono sia il framework sia ciò che accade sotto di esso.
Per oggi ci fermiamo qui. Quando le applicazioni crebbero, la libertà disordinata dei primi linguaggi diventò caos, e servì struttura. I framework la portarono, a metà anni Duemila, con l'idea rivoluzionaria della convenzione al posto della configurazione: rinunci a un po' di libertà in cambio di velocità, ordine e un linguaggio comune tra sviluppatori. Diffusero la separazione delle responsabilità, moltiplicarono la produttività e professionalizzarono il mestiere. Ma non sostituiscono la comprensione delle fondamenta. Nella prossima puntata mettiamo insieme i pezzi nell'architettura classica del backend, e conosciamo il monolite. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.