Il Frankenstein in digitale che nessuno ha chiesto

Il sito che cambia personalità a ogni click

Avete mai navigato un sito della pubblica amministrazione italiana? Quella sensazione straniante quando cliccate e vi ritrovate catapultati in un universo parallelo. Il menu è diverso, i colori non c’entrano niente, il pulsante “indietro” ha perso la memoria. Nel peggiore dei casi, dovete rifare il login perché siete su un sito completamente diverso.

Questa esperienza orribile è integrazione raffazzonata di sistemi separati. È brutta, frustrante, confusionaria. Ma almeno è onesta nella sua bruttezza. Sapete qual è la cosa peggiore? C’è chi ha guardato questo disastro e ha pensato: “Possiamo fare di meglio! Nascondiamo tutto dentro un’unica interfaccia!”

Benvenuti nell’era dei microfrontend, dove prendiamo il caos di sistemi separati e lo mascheriamo dietro l’illusione di coerenza, creando qualcosa di ancora più mostruoso.

Quando troppi cuochi rovinano non solo il brodo

Il vero problema che i microfrontend cercano di risolvere non è tecnologico, è organizzativo. Avete tre team diversi, ognuno con le proprie preferenze tecnologiche, i propri standard, il proprio ego. Il Team A giura su React, il Team B vive e respira Angular, il Team C ha appena scoperto Vue e vuole usarlo per tutto.

In un’organizzazione sana, questi team si metterebbero d’accordo su una tecnologia comune. Ma siamo nel mondo reale, dove i budget sono separati, le roadmap non si parlano, e ogni manager vuole difendere il proprio territorio. La soluzione politicamente accettabile? Lasciare che ognuno costruisca il proprio pezzetto come vuole, e poi “integrare tutto” in un secondo momento.

Questo approccio è l’equivalente digitale di dire a tre architetti con stili completamente diversi di progettare ognuno una stanza della stessa casa, senza mai farli parlare tra loro, e poi sperare che il risultato finale abbia un minimo di coerenza. Spoiler: non ce l’avrà.

L’arte antica degli iframe riverniciata come innovazione

Per decenni, gli iframe sono stati considerati il modo pigro e disperato di integrare contenuti esterni. Una tecnologia che nessun sviluppatore serio avrebbe usato se non costretto. Ma poi qualcuno ha avuto un’illuminazione: “E se prendessimo questa pratica terribile e la chiamassimo architettura moderna?”

Improvvisamente, ciò che ieri era un orrore tecnico oggi diventa “isolamento dei componenti”. Il fatto che ogni iframe carichi le proprie dipendenze, i propri CSS, il proprio JavaScript, non è più uno spreco di risorse ma “autonomia dei team”. La comunicazione impossibile tra iframe diversi non è più un bug ma una “feature di sicurezza”.

È come se avessimo riscoperto la ruota quadrata e la stessimo vendendo come innovazione nel settore dei trasporti.

Il gioco delle tre carte con l’utente finale

L’obiettivo dichiarato dei microfrontend è ingannare l’utente facendogli credere di essere su una singola applicazione coerente. È letteralmente un gioco delle tre carte: “Guarda, è tutto un’unica webapp! No, aspetta, in realtà sono quattro app diverse, ma fai finta di niente.”

Il problema è che l’utente se ne accorge eccome. Vede pezzi di pagina che si caricano in momenti diversi, con animazioni diverse. Clicca su un pulsante e l’URL cambia in modi bizzarri. Nota che alcuni bottoni hanno uno stile e altri ne hanno un altro completamente diverso. Sperimenta lag inspiegabili quando componenti invisibili si parlano usando meccanismi convoluti.

L’esperienza risultante è peggiore di quella dei siti separati. Almeno quando apri due siti diversi in due tab diverse, capisci che sono entità separate. Con i microfrontend, l’incoerenza sembra un bug, un’incompetenza, un lavoro fatto male. Perché tecnicamente lo è.

I problemi che nessuno vuole ammettere

Parliamo di gestione dello stato. In una normale applicazione, hai un unico stato centralizzato. Con i microfrontend, ogni pezzo ha il suo stato. Coordinate le modifiche attraverso event bus contorti, local storage condiviso, chiamate API ridondanti. È come organizzare una festa dove gli invitati comunicano lanciandosi bigliettini sotto la porta.

Le performance sono un altro elefante nella stanza. Ogni microfrontend carica React? Ora hai tre copie che girano contemporaneamente. Ogni componente ha le sue dipendenze? L’utente sta scaricando megabyte di codice duplicato. Comunicazione asincrona? Goditi i lag percettibili.

I conflitti CSS meritano un capitolo a parte. Tre sviluppatori definiscono indipendentemente classi CSS con gli stessi nomi ma stili diversi. Metti tutto nella stessa pagina. Il risultato è un campo di battaglia dove gli stili si sovrascrivono a vicenda in modi imprevedibili, creando layout che sembrano usciti da un glitch nella matrix.

Il dinosauro digitale che nessuno vuole abbattere

Esiste esattamente un caso d’uso legittimo per i microfrontend: stai modernizzando gradualmente un sistema legacy gigantesco e non puoi permetterti di riscrivere tutto da zero. In questo scenario, i microfrontend sono una soluzione temporanea di transizione. Parola chiave: temporanea.

Il problema è che “temporaneo” nel software diventa facilmente “per sempre”. Quella soluzione di ripiego che doveva durare sei mesi è ancora lì dopo tre anni. Quel microfrontend “di transizione” è diventato la base su cui costruire nuove funzionalità. E così il mostro cresce, si espande, diventa la normalità.

Per ogni altro caso d’uso, i microfrontend sono una soluzione alla ricerca disperata di un problema. Hai team diversi che vogliono usare tecnologie diverse? Il problema non è tecnico, è gestionale. Risolvi il problema alla radice invece di creare un’architettura contorta per accomodare disfunzioni organizzative.

L’istituzionalizzazione del disastro

La cosa affascinante dei microfrontend è come siano stati elevati a pattern architetturale rispettabile. Ci sono libri interi sull’argomento. Conferenze con speaker entusiasti. Framework specificamente progettati per facilitarne l’implementazione.

È come se avessimo preso una pratica che per anni tutti riconoscevano come pessima ingegneria e l’avessimo riverniciata con un nome cool. Ora non è più “integrazione fatta male”, è “architettura a microfrontend”.

Le liste di pro e contro sono esilaranti. I “pro” sembrano scritti da chi cerca disperatamente di giustificare una decisione già presa. I “contro” sono lunghi, dettagliati, preoccupanti, ma sempre accompagnati da “si possono mitigare con le giuste pratiche”. Spoiler: raramente si mitigano.

La vera domanda da porsi

Prima di saltare sul carro dei microfrontend, chiedetevi: abbiamo veramente bisogno di frammentare la nostra applicazione frontend? O stiamo cercando una soluzione tecnica a un problema organizzativo?

Nella maggior parte dei casi, state cercando di mettere un cerotto tecnologico su una ferita gestionale. E come tutti i cerotti su ferite profonde, prima o poi si staccherà, lasciando esposto un problema ancora peggiore.

I microfrontend non sono architettura moderna. Sono un compromesso politico mascherato da scelta tecnica. E come tutti i compromessi politici nel software, finiranno per creare più problemi di quanti ne risolvano.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT