Blazor: are we ready for the launch?
- 1. #vssatpn Visual Studio Saturday 2019 Blazor: are we ready for the launch? Andrea Agnoletto MCSA Web Applications - MCSD App Builder
- 2. #vssatpn Introduzione • Il taglio di questa presentazione sarà architetturale • Obiettivo: integrare Blazor in un’applicazione relae
- 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
- 4. #vssatpn Che cos’è Blazor: il concept di base
- 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!
- 7. #vssatpn .NET Framework WA LLVM toolchain compiler Blazor.NETMono Runtime (C++) La versione di .NET che è stata compilata in wasm è un subset di Mono e rispetta le specifiche .NET Standard 2.0.
- 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
- 21. #vssatpn Blazor in un progetto reale: i due modelli architetturali
- 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
- 26. #vssatpn Il modello da prediligere è… il Client side
- 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.
- 30. #vssatpn Pattern architetturale UI: paradigma Hyperlink Blazor WA Blazor ServerKnockoutJSWebForms (Daniele Morisinotto, “Frontend solutions for Enterprise App”, XeOneDay 2019) .aspx .aspx .aspx .aspx
- 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)
- 33. #vssatpn Il futuro di Blazor
- 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)
- 37. #vssatpn Contatti • Andrea Agnoletto MCSA Web Applications – MCSD App Builder • email: andrea@agnolettodev.net • linkedin: https://it.linkedin.com/in/andreaagnoletto • community: https://www.xedotnet.org