Nell’articolo Progressive Web App: guida all’architettura PWA abbiamo fatto una panoramica sulle Progressive Web App. Questa nostra precedente guida non si potrebbe considerare completa senza aver toccato anche l’argomento Blazor, che con le PWA ha molto da spartire, anche se non si può considerare “soltanto” una Web App Progressiva.
Ma, andiamo con ordine. Che cos’è questo Blazor, attorno a cui ultimamente sembra esserci tanto fermento?
La storia di Blazor
Blazor è un framework nato con lo scopo di facilitare la creazione di interfacce utente, apparso recentemente all’interno dell’ambiente ASP.Net. Il motivo per cui la sua apparizione ha creato tanto scalpore è dovuto al fatto che Blazor permette di realizzare l’interfaccia di una pagina web senza più scrivere una sola riga di Javascript, ma utilizzando al suo posto il linguaggio C#. Prospettiva che potrebbe lasciare indifferenti alcuni, piuttosto che significare una svolta nella propria carriera di sviluppatori per altri.
Javascript ha i suoi fan, anche se alcuni sviluppatori lo considerano niente più di un male necessario, la cui esistenza dipende strettamente dai limiti con cui l’internet dei primi tempi è stata concepita. Nate infatti come contenitori di elementi statici, le pagine web si sono dovute arricchire con il tempo di meccanismi dinamici per gestire dati ed eventi, e Javascript è stata una delle stampelle che ha permesso all’internet delle origini di trasformarsi nel web così come lo conosciamo oggi. Tuttavia, alcuni programmatori non sono mai stati pienamente soddisfatti delle implicazioni di Javascript, e riprova di questo perenne rapporto di amore e odio è il cospicuo numero di superset del linguaggio sorti negli anni successivi per compensarne i limiti o, addirittura, con l’ambizione (mai realizzata) di rimpiazzarlo.
Di tutte queste estensioni, una di quelle che ha acquistato un’ampia diffusione è il TypeScript. Il suo inventore, Anders Hejlsberg, è anche lo stesso ingegnere che ha disegnato le basi del C# (decisamente un inventore prolifico). Il C# era già impiegato nel coding di applicazioni front end (basti pensare al mondo desktop e, sugli smartphone, a Xamarin), mentre il TypeScript è un ottimo ambiente in cui creare esperienze utenti immersive e moderne (non a caso Microsoft l’ha scelto per lo stack di Sharepoint). Ci è voluto poco perché i due universi collidessero: Microsoft aveva già in corso diversi esperimenti con Blazor, sia come applicazione desktop, sia in un ambiente di sviluppo misto a Xamarin. Sulla spinta di questo sincretismo, Blazor è uscito dai confini già elastici del suo design originale ed è riuscito a proporsi come competitor di Javascript in framework dedicati allo sviluppo di applicazioni web a singola pagina (SPA).
La prospettiva di poter usufruire di un unico tool per realizzare app desktop, mobile e web, e di trovarlo integrato nel già familiare ambiente .NET, ha fatto il resto.
L’architettura: Blazor Server
Al momento della scrittura di questo articolo, esistono due diverse versioni di Blazor: Server e WebAssembly. In realtà, ci sono anche altre varianti su cui Microsoft sta lavorando, ma non essendo ancora in uno stato di release, per ora non ne parleremo.
Blazor Server è stata la prima versione rilasciata, nel settembre 2019. In questo modello l’applicazione gira sopra un completo runtime .Net Core e, quando l’utente carica l’applicazione, sul suo device avviene il download di un piccolo file JavaScript che stabilisce una connessione SignalR con il server. Questa connessione permette ai due componenti di comunicare attraverso un websocket. Sebbene la tecnologia dietro a questo tipo di connessione sia impegnativa, le sue prestazioni in Blazor, grazie all’ottimo lavoro del team di sviluppo, si sono rivelate superiori a ogni aspettativa.
Il vantaggio di questo tipo di app, quindi, è che può offrire all’utente le complete funzionalità del runtime .Net al prezzo di un ridotto footprint. Lo svantaggio di Blazor Server è che l’app può rallentare in caso di latenze nella connessione alla rete e risultare inutilizzabile offline. Qui è dove entra in gioco il collegamento con le Progressive Web Application, che estende il concept di Blazor con l’implementazione WebAssembly.
Blazor come PWA: Blazor WebAssembly
Qui entra in gioco una delle novità disruptive di Blazor. Nella sua variante WebAssembly, Blazor permette di eseguire il codice C# direttamente nel browser del client, rendendo riutilizzabili tutte le logiche e le librerie lato server come parti dell’applicazione. Il codice eseguito nel browser gira in una sandbox simile a quella dei framework Javascript, che ne garantisce la sicurezza proteggendola da tentativi di injection di codice malizioso. I componenti dell’interfaccia di Blazor sono implementati utilizzando un fluido stile di programmazione che unisce algoritmi .NET e sintassi Razor, risultante in un elegante equilibrio di tag Html e istruzioni C#. L’architettura WebAssembly permette all’app Blazor di comportarsi come una vera e propria Progressive Web App. Quindi, l’app Blazor è in grado di funzionare anche con connettività limitata o assente, caricare una propria finestra in cui eseguire il codice, essere lanciata direttamente dalla home del device, e ricevere notifiche Push da un server back end.
Javascript InterOp
Ma non è finita qui. Pensando a quella fetta di sviluppatori che da anni lavora in Javascript, e che, passando al C#, rischierebbero di perdere la possibilità di riutilizzare i tool e le librerie sviluppate nel corso della loro carriera, Blazor introduce un’altra funzione altamente disruptive: la possibilità dell’interoperabilità con Javascript. Interoperabilità significa che, oltre a poter eseguire il porting della logica server-side già scritta in C#, gli sviluppatori avranno accesso anche a una classe di InterOp con Javascript, che permetterà loro di chiamare routine contenute nelle librerie Javascript utilizzate finora. L’interoperabilità con Javascript si basa sull’iniezione dell’interfaccia IJSRuntime nella pagina web o nel code behind in C#, e supporta solo tipi di dati serializzabili JSON.
Una piattaforma per l’ERP?
Alcune peculiari caratteristiche applicative di Blazor WebAssembly, prima fra tutte la fruibilità dell’app anche offline, fanno sì che una PWA scritta con questo framework venga percepita dall’utente finale quasi come una app desktop oltre che come una pagina web. Questo ha acceso l’interesse in questa tecnologia anche da parte di case software specializzate in ERP. La possibilità di funzionare senza collegamento a internet, infatti, lo avvicina molto alla filosofia degli eseguibili Windows legacy, e come tale ha attirato l’interesse di un’utenza aziendale più vicina alle dinamiche dei programmi client/server on premise che delle Mobile App.
Grazie alla sua flessibilità e all’accesso completo all’ambiente .Net, anche in ambito ERP Blazor non ha nulla da invidiare ad applicativi sviluppati con tecnologie tradizionali.
Accesso ai dati in Blazor
L’accesso ai dati con Blazor avviene in due modalità diverse, a seconda che si stia usando la versione Server o WebAssembly.
Con Blazor Server, l’app viene eseguita lato back end e comunica con l’interfaccia lato client per mezzo di una connessione SignalR. In questo scenario l’app può accedere ai dati con tecnologie consolidate come Entity Framework.
Se invece ci troviamo a gestire l’app nella versione WebAssembly, in questo scenario dovremo convertire la modalità di accesso ai dati, implementando lato back end delle API che l’app possa consumare. Le API potranno infatti accedere ai dati utilizzando Entity Framework o la tecnologia di accesso ai dati con cui siamo abituati a lavorare.
La strategia migliore di accesso ai dati, quindi, risiede proprio nell’impiego di API lato back end, che potranno essere consumate sia dalla versione Server che dalla versione WebAssembly dell’app, senza richiedere manutenzioni impegnative del codice.
