In questa sessione faremo una panoramica a 360 gradi su Blazor, la nuovissima tecnologia Microsoft nata da una (geniale :-) idea di Steve Sanderson per lo sviluppo di applicazioni Web client basate su WebAssembly.
Nell'introduzione parlemermo brevemente di WebAssembly, spiegando di cosa si tratta e del perché questa tecnologia abbia tutte le premesse per portare uno dei più grandi "disruptive changes" nel modo di sviluppare applicazioni Web client. Passeremo poi a Blazor esaminandone prima gli aspetti architetturali e procedendo con un behind the scenes per svelare in che modo avviene la "magia" dell'interazione con il browser. Verranno poi presentate le feature che questa tecnologia offre (template project su VS, components, layouts, binding, dependency injection, hosting) sia attraverso slides che, di pari passo, con delle demo di un'applicazione funzionante realizzata in Blazor. Vedremo poi quali sono le problematiche legate a performance, deployment e distribuzione parlando delle possibili future ottimizzazioni. Infine chiuderemo con un confronto tra Blazor e i maggiori framework ora in uso per lo sviluppo di applicazioni Web client (Angular, Vue, Knockout, ecc.) e con alcune considerazioni sull'impatto che Blazor e tecnologie simili potrebbe avere a cascata per lo sviluppo Web futuro, in una sorta di "butterfly effect" nel mondo Web client.
3. #vssatpn
Agenda
Che cos’è Blazor
• Il concept di base
• Caratteristiche principali
Blazor in un progetto reale
• I due modelli architetturali
• Demo: Blazor in Enterprise CRM
• Il futuro di Blazor: piano dei rilasci
5. #vssatpn
Il concept
Ideato da Steve Sanderson nel “tempo libero” ☺ come progetto sperimentale si
basa su un concetto semplice (e nemmeno del tutto nuovo a dirla tutta):
Far eseguire il runtime del .NET Framework su un browser.
“OMG: Un altro Silverlight???”
6. #vssatpn
Il concept
Al contrario di Silverlight non è necessario un plugin: il “motore” è costituito da
WebAssembly, una Low Level Virtual Machine (LLVM) in grado di eseguire codice di
livello basso (da qui il nome assembly) all’interno del browser:
• runtime bytecode altamente performante, vicino al 2x rispetto a compilato assembly
nativo!
• Cross-compatibility nativa rispetto a tutti i browser!
8. #vssatpn
Blazor page lifecycle
Le modifiche vengono
propagate dalle “Blazor JS API”
al DOM HTML della pagina
Il click viene processato da
Mono che esegue le .NET dll
client side e genera le modifiche
all’HTML
Il click viene inviato attraverso le
“Blazor JS API” al .NET Framework
(Mono) residente su browser
Blazor.NET
9. #vssatpn
Blazor e il DOM HTML
L’elevata efficacia da parte di Blazor nel manipolare dinamicamente il DOM della
pagina HTML si deve a RenderTree, una astrazione del DOM simile ai virtual DOM
usati in altri framework JavaScript based come Angular, Vue e React.
Proprio come in questi framework, solo le sezioni di DOM modificate dal codice C#
che gestisce l’evento vengono rigenerate, mantenedo inalterate le altre.
10. #vssatpn
Supporto di Blazor
Ad oggi Blazor è supportato dalle versioni correnti dei maggiori browser:
• Chrome (anche in versione per Android)
• Firefox
• Safari (anche in versione per iOS)
• Edge
Solo nella versione Server viene offerto supporto anche da parte di Internet
Explorer 11 attraverso l’uso di polyfill JS (questo perché IE non supporta wasm)
12. #vssatpn
Il modello di Blazor
Vediamo quali sono gli elementi principali di Blazor:
• Component: file .razor con mix HTML – CSS – C# (cfr. partial view - tag helper MVC)
• Page: component con supporto alle route (cfr. view MVC)
• Motore di binding bidirezionale: pattern MVVM alla Angular/Vue, observable
13. #vssatpn
Component
Nelle moderne applicazioni (SPA e tradizionali) i component sono il mattone
fondamentale per la costruzione delle UI. Sono ormai irrinunciabili perché
garantiscono isolamento e riusabilità. In Blazor:
• ogni file con estensione .razor è un component. I component sono costituiti da markup
HTML, sintassi Razor e codice C#.
• Un component può essere inglobato all’interno di un altro component usando una
sintassi a "tag HTML" dove il nome del tag è il nome del file .razor.
• la loro sintassi supporta un modello di binding bidirezionale agganciato ai tag HTML via
attributi (stile Angular o Vue, per intenderci)
• possono ricevere dei parametri dal Component "parent" e possono accedere allo stato
dell’applicazione.
14. #vssatpn
Blazor pages
Sono dei tipi particolari di Component, praticamente identiche alle Razor Pages:
• sono individuate dalla direttiva @page posta all’inizio
• al contrario degli altri Component supportano le route. Attenzione però: si tratta di route
"virtuali" (alla Angular) che non vengono impiegate in un modello request/response nelle
comunicazioni tra client e server ma "vivono" solo client side e sono usate dal motore di
paginazione di Blazor per dare l’"illusione" del cambio pagina (mentre, come per tutte le
SPA siamo sempre dentro alla stessa pagina HTML)
• ovviamente possono inglobare al loro interno altri Component (di tipo non @page)
15. #vssatpn
Routing
Uno degli elementi fondamentali per una SPA è disporre di un meccanismo di
routing che permetta all’utente di navigare virtualmente (perché in realtà la pagina
HTML resta sempre la stessa) all’interno delle diverse "pagine" della nostra
applicazione.
16. #vssatpn
Routing
In Blazor la chiave del routing è il path che segue la direttiva @page
nell’intestazione della pagina:
• @page "/": la pagina che contiene questa route viene caricata con l’url di base
dell’applicazione, ad es. https://blazordemo.xedotnet.org/
• @page "/about": la pagina che contiene questa route viene caricata con l’url:
https://blazordemo.xedotnet.org/about
• @page "/about/{text}": sono supportati parametri di url con questa sintassi. Il binding
con le property della pagina viene fatto via naming convention (case insensitive). Es:
https://blazordemo.xedotnet.org/about/Andrea
17. #vssatpn
Binding
Un altro degli elementi fondamentali per una SPA è disporre di un meccanismo di
binding che permetta a noi dev di legare il "model" alla "view" in maniera veloce ed
efficiente. Blazor offre un meccanismo di binding bidirezionale incredibilmente
intuitivo e facile da apprendere ma allo stesso tempo potente:
• ricalcando i meccanismi di binding di Razor segue un modello dichiarativo, attraverso
custom attribute dei tag html (@bind, @onclick)
• implementa "dietro le quinte" un modello ad observable praticamente senza richiedere
al dev di scrivere codice
18. #vssatpn
Altre features di Blazor
Come MVC e le Razor Pages, Blazor supporta nativamente:
• Autentificazione
• Layout
• Validazione delle form (via data annotation)
• Dependency Injection
Inoltre è possibile interagire client side con codice JS via:
• JavaScript interop
19. #vssatpn
Awesome Blazor
Infine si trova su Git il repo https://github.com/AdrienTorris/awesome-blazor dove
sono messi a disposizione component e tool per gestire tutti gli aspetti importanti
di una SPA:
• Blazor-Fluxor (Flux/Redux based library for state management)
• Storage (HTML5 storage API for Blazor)
• Telerik UI for Blazor (UI component)
• … e molto altro (esempi, tutorial, games…)
20. #vssatpn
Per una demo più approfondita…
… godetevi questa presentazione fatta da Steve Sanderson, il papà di Blazor, alla
NDC (Norwegian Developers Conference) Sidney (14 – 18 ottobre 2019):
• https://youtu.be/6BT2AF9PO5g
22. #vssatpn
Le due architetture di Blazor
(Dan Roth, “Building Full-stack C# Web Apps with Blazor in .NET Core 3.0”, .NET Conf 2019)
(Maggio 2020) (Rilasciata)
23. #vssatpn
Client side vs Server side: caratteristiche
Blazor WebAssembly
1. Richiede un download iniziale più corposo (Mono
runtime 2,5 MB già compresso)
2. La logica UI viene eseguita a carico del client
(ottima scalabilità).
3. Non è richiesto nessun Web server ASP.NET Core
based per ospitare l’applicazione. Sono possibili
scenari di deployment serverless (ad esempio via
CDN).
4. Può essere integrato con applicazioni ASP.NET
Framework (WebForms) e anche non MS-based.
5. Il runtime Mono-WebAssembly viene eseguito
attraverso un interprete IL: non è presente JIT e al
momento AOT non è supportata (ma lo sarà
presto secondo quanto dichiarato da Dan Roth).
Blazor Server
1. Download iniziale minimo (solo il proxy JS Signal-
R).
2. La logica UI viene eseguita lato server
(ripercussioni sulla scalabilità)
3. E’ richiesto un Web Server ASP.NET Core based per
ospitare l’applicazione.
4. Può essere integrato con applicazioni ASP.NET
Framework (WebForms) e anche non MS-based
ma solo in modalità “SPA” (no Razor Component
“ibridi”)
5. L’applicazione gira su ASP.NET Core e quindi sfrutta
a pieno tutte le caratteristiche del Framework: JIT
compiling, pre-rendering server side, debug ed
uso di tutte le API del framework
24. #vssatpn
Progetto reale, scenario 1: inserire Blazor in
una nuova applicazione
E’ lo scenario ideale: possiamo decidere senza vincoli quale modello architetturale
di Blazor adottare tra:
• SPA con Blazor WebAssembly (da maggio 2020!)
• SPA con Blazor Server
• Applicazione ASP.NET Core 3.0 "ibrida" (non SPA) che mescoli architetture "tradizionali"
(MVC, Razor Pages) ai Razor Component (sempre via Blazor Server)
25. #vssatpn
Progetto reale, scenario 2: inserire Blazor in
un’applicazione esistente
Qui le cose si complicano. Se l’applicazione è già implementata in ASP.NET Core
allora possiamo usare le stesse architetture appena viste (magari migrandola da
versioni precedenti alla 3.0). Se invece è un’applicazione full Framework (es. 4.7.x)
o, peggio, non implementata con tecnologie MS abbiamo solo due possibilità:
• SPA con Blazor WebAssembly (da maggio 2020!)
• SPA con Blazor Server
27. #vssatpn
Perché il modello Client side?
• L’idea originale era poter eseguire C# su browser…
• … in modo da poter avere un’alternativa agli UI framework JS-TS based…
• … e lo sviluppo futuro di Blazor sarà sempre più orientato al client
28. #vssatpn
Perché rilasciare prima il Server side?
Aver rilasciato per prima la versione Server side è stata una scelta dettata da vari
fattori:
• il time-to-market
• mettere a disposizione i (Bl)-(R)azor Component anche se server side (in alcuni contesti
possono rappresentare la scelta migliore per implementare le UI)
• il fatto che, secondo le dichiarazioni di Dan Roth: "Faremo tutto il possibile per
mantenere la promessa di poter switchare tra Server side e Client side cambiando solo
poche righe di codice".
29. #vssatpn
Blazor in Enterprise CRM
Vedremo ora nella prossima demo un esempio di integrazione di Blazor all’interno
di un’applicazione ASP.NET WebForms con .NET Framework 4.7.2. L’applicazione si
chiama Enterprise CRM (nome in codice Tustena), è il CRM di TeamSystem e si
tratta del prodotto leader in Italia per il settore. È stato sviluppato a partire dagli
albori del .NET Framework (vers. 1.0) e ha seguito l’evoluzione di ASP.NET (per
quanto possibile) fino ad oggi.
L’integrazione con Blazor è una "proof of concept": non è in produzione e manca di
molte feature per essere completa, ma è sufficientemente sofisticata per capire le
possibili problematiche architetturali che possono emergere da un tentativo di
"merge" di un’applicazione esistente con Blazor.
31. #vssatpn
Demo:
Blazor in Enterprise CRM*
(* Il codice della demo non è disponibile in quanto sviluppata su di un prodotto non open source di proprietà di TeamSystem)
32. #vssatpn
Criticità riscontrate
Ecco le maggiori problematiche emerse dalla "proof of concept":
• problemi nelle route correlate all’URL di pagine aspx (Blazor WebAssembly)
• interazione con il DOM/funzioni JS di altre parti della pagina (fuori dalla "shell" di Blazor)
• gestione del bubbling e default behavior degli eventi degli elementi del DOM
• gestione dell’<iframe> (modalità Blazor Server)
• debug (modalità Blazor WebAssembly)
• pre-requisiti architetturale dell’applicazione "host" (business logic esposta via servizi
REST)
34. #vssatpn
Il futuro di Blazor: piano rilasci
Web
Desktop
+ Mobile
Blazor Server
Blazor WebAssembly
Blazor PWA
Blazor Hybrid
Blazor Native
Esecuzione Server side (già rilasciato)
Esecuzione client side su browser (maggio 2020)
Esecuzione su OS come Progressive Web App
Esecuzione su OS con Electron
Esecuzione su OS con UI non Web (in
fase di valutazione)
(Dan Roth,“The Future of Blazor on the Client”, .NET Conf 2019)
35. #vssatpn
Considerazioni finali
• Nel nostro modello di PMI avere un dev C# che sia finalmente in grado di scrivere
una UI “moderna” ed “equi-potente” ad una UI Angular/Vue senza ricorrere ad
un secondo sviluppatore JS-TS è una grande fattore di attrazione per un Project
Manager.
• La possibilità (nel caso l’applicazione sia interamente realizzata secondo un
framework che supporti il .NET Standard 2.0) di condividere dll tra server e client
costituisce un risparmio di lavoro sia in fase di implementazione che di
manutenzione (pensiamo ad es. alla condivisione tra Web API e client di una
libreria di DTO)
36. #vssatpn
Riferimenti
Documentazione on line
• https://blazor.net (official site)
• https://blazor.net/docs (official documentation on Microsoft Docs)
• https://github.com/AdrienTorris/awesome-blazor (Git samples and resources repo about
Blazor)
Video
• https://youtu.be/6BT2AF9PO5g (Steve Sanderson, “Blazor, a new framework for
browser-based .NET apps” NDC Sidney, October 2019)
• https://www.youtube.com/watch?v=MetcuX1OHD0 (Dan Roth, “Building Full-stack C#
Web Apps with Blazor in .NET Core 3.0”, .NET Conf, September 2019)
• https://www.youtube.com/watch?v=qF6ixMjCzHA (Dan Roth, “The Future of Blazor on
the Client”, .NET Conf, September 2019)