🦠 COVID-19: Všechna školení nyní také on-line. Přečtěte si mé tipy na vzdělávání v době koronavirové.
Blazor Server Firemní školení Blazoru
Vše, co potřebujete vědět pro vývoj Blazor Server aplikací zabaleno do jednodenního školení ve firmě nebo on-line školení.
Slovenská verzeSlovensko

Školení ASP.NET Core Blazor do firem

Téměř na každém školení, webináři i setkání se na mě vývojáři obracejí s otázkou, zda budu školit Blazor. Dlouho jsem se tomu bránil a snažil se držet pouze REST API. Po prvních experimentech a zkušenostech s Blazorem by mi nicméně přišla škoda se o znalosti nepodělit. Navíc přišla okurková sezóna, která mi vyloženě dala čas se věnovat přípravě zbrusu nového školení.

Miroslav Holec

Miroslav Holec

14. července. 2020

Proč se zajímat o Blazor?

Migrovat klasické .NET Framework aplikace do .NET Core se většinou nikomu nechce. Kromě lepší výkonnosti a možnosti hostování na Linuxu to úsilí nepřináší nic zásadního. Pořád víceméně stejné MVC. Možná někoho (jako mě) zaujmou Razor Pages, nicméně to je spíše kosmetika, kterou řada vývojářů pokryla pomocí tzv. Feature Folders. Technologicky žádná revoluce. Tak či onak hromada C# kódu, který se provádí s každým requestem a jehož výsledkem je vyrenderování HTML celé stránky.

Moderní aplikace už si s tímto přístupem nevystačí. Interaktivní aplikace se dnes staví s pomocí některého JS frameworku. Tedy vývojář typicky použije JS framework + TypeScript + REST API a vytvoří dvě oddělené aplikace. Například front-end aplikaci v Reactu, která si povídá s RESTovým API. Samotné REST API může být napsané v rychlém .NET Core + MVC (respektive části MVC). Toto je zároveň asi nejčastější scénář, ke kterému se vývojářské týmy uchylují při odchodu z tradičního NET Frameworku. To je podle mého názoru ta nejlepší cesta. Existují ale důvody, proč se vám touto cestou nebude chtít jít.

Nemáte vývojáře, kteří by dokázali napsat aplikaci v Reactu? Nechcete vytvářet REST API jen jako backend pro front-end aplikaci? Chcete vytvářet jednotnou aplikaci, která bude plně interaktivní bez toho aniž byste museli psát mraky JS / TS kódu? Pak Vám může dobře posloužit Blazor. Blazor je framework založený na komponentách, které si spolu povídají. Veškerý markup píšete v notoricky známém Razoru a interaktivitu zajišťujete událostmi a jejich handlováním v jazyce C#. Máte-li tedy vybudovaný tým BE a FE vývojářů, Blazor Vám podle mého názoru nic zásadního nepřinese. JS se stejně do určité míry nezbavíte a zbytečně si vytvoříte "vendor lock" na technologii, která může skončit tam, kde před lety skončil Silverlight. Chcete-li ale vytvořit například podnikovou aplikaci, intranetí aplikaci, CMS nebo třeba e-shop s prvky interaktivity, může Vám Blazor vyhovovat.

Blazor Server vs WebAssembly

Vedle řady experimentů jako Blazor Mobile nebo Blazor Electron (Hybrid) vykvetly dva modely hostování pro prostředí webu. Historicky starší Blazor Server (LTS) a nedávno uvolněný Blazor WebAssembly 3.2. Přestože výrazně větší část frameworku je společná a funguje společně, oba modely se liší způsobem hostování. To má velké množství důsledků.

Blazor Server navazuje na současné ASP.NET Core aplikace. Ke svému životu potřebuje technologii SignalR. To samo o sobě značí, že uživatelská interaktivita je vykoupena relativně intenzivní komunikací se serverem. To klade sice menší nároky na stranu klienta, avšak naopak vyžaduje výkonnější prostředky na straně serveru. Komunikace mezi klientem a serverem se musí udržovat po určitou dobu živá. V současné době je například mnoho bugů reportováno v souvislosti s ukončením připojení a neschopnosti browseru navázat nové připojení. Nejhorší situace je v dílně Chromium Edge a Firefox. Tradičně spolehlivý je pouze Chrome. Protože se veškeré aktualizace UI deleguje přes SignalR na server, neexistuje v modelu Blazor Server žádný offline mód. Připojení zkrátka musí existovat po celou dobu, kdy uživatel pracuje s aplikací. Protože musí server navíc uchovat stav klienta (což žere mnoho operační paměti), výrazně se zhoršují možnosti škálování. Obvykle se tedy jde cestou vertical scale. Potíže má Blazor Server také v případě protlačování většího množství dat v rámci JS interops - tedy když například chcete provádět operace s většími soubory mezi JS a Blazorem (ne, že by to nešlo složitě řešit).

Blazor Server má nicméně i řadu výhod, které zatím WebAssembly nesmazal. Oproti WebAssembly se nemusí stahovat na stranu klienta celá aplikace a start aplikace je tudíž rychlejší. To může být důležité zejména pro mobilní aplikace s globálním dosahem a využitím v oblastech, kde chybí pokrytí kvalitním připojením. Protože se vše odehrává na straně serveru, použije vývojář klasický arzenál znalostí z jiných ASP.NET Core aplikací. Používá se stejný model konfigurace, logování i principů dependency injection. Spolehlivě funguje debugging - přesně jak jej známe a pokud má vývojář alespoň základní znalosti z oblasti security, nemůže vytvořit žádnou výraznou bezpečností díru (snad tedy). To je důvod, proč na svých školeních primárně školím Blazor Server. Je to v podstatě nadstavba něčeho, co už vývojáři dobře znají.

Blazor WebAssembly je z podstaty hostování zcela odlišný. Aplikaci tvoří JS, který si stáhne celý .NET runtime a další DLLka aplikace na stranu prohlížeče a následně spustí runtime a samotnou aplikaci. Tento nepatrný rozdíl zcela mění pravidla hry. Není tu žádný backend na straně serveru - aplikace kompletně běží na straně klienta a klade na něj tedy i určité systémové nároky. Nešikovný vývojář může napsat neoptimální aplikaci, která dokáže méně výkonným mobilním zařízení dobře zatopit. Vzhledem k tomu, že se na klienta přenáší samotná aplikace, není z pohledu bezpečnosti možné použít klasické přístupy konfigurace a logování, jak je známe z jiných ASP.NET Core aplikací. Mění se také životní cyklus celé aplikace (v podstatě se stává "singletonem") a tudíž i registrace služeb v DI se budou u Blazor WebAssembly lišit. Už se tu musí docela přemýšlet a zejména při přepínání se mezi Server a WebAssembly modelem během dne můžete vytvořit mraky chyb. Ty se vám budou navíc v případě WASM mnohem hůře debugovat. Tedy tím hůře, čím hůře přijmete fakt, že debugging se odehrává logicky na straně klienta. WebAssembly nemá podporu u některých starších a tradičně problémových prohlížečů (jejichž autorem je paradoxně stejná fabrika jako v případě Blazoru). U těch ostatních budete muset tolerovat větší množství stahovaných dat než v případě minimalistického Blazor Server.

I tady ale platí, že Blazor WebAssembly má své výhody. Ty už asi tušíte z předešlého popisu. V zásadě nepotřebujete žádný výkonný server a hostovat můžete s využitím CDN. Po překonání prvního stažení aplikace je Blazor WASM rychlejší než Blazor Server, kde probíhá intenzivní SignalR komunikace. Odpadá kompletně otázka škálování, protože není co škálovat. V neposlední řadě samotná aplikace je na straně klienta a tudíž (je-li jí dopřáno šikovných rukou vývojáře), může fungovat i v offline módu. Čili výhod není sice tolik, ale jsou celkem mocné.

Začněte s Blazor Server

Osobně jsem přesvědčen, že po stabilizaci Blazor WebAssembly (což bude asi na podzim 2021) se vyřeší všechny zmíněné nevýhody. Zmenší se velikost balíčku (už teď je únosný), staré prohlížeče ztratí další procenta z podílu a vývojáři získají čas naučit se řadu specifik WASM. Dost možná v té době nastane i soumrak Blazor Server. Každopádně v současné době je Blazor Server ideální technologií, kterou se má smysl naučit. Sám o sobě pokrývá řadu praktických scénářů, je deklarován jako LTS a představuje nadstavbu nad tím, co vývojáři znají z ASP.NET Core. Stačí se tedy naučit jak poskládat aplikaci z komponent a jak komponenty mezi sebou provázat. Pochopit vázání dat a handlování změn v UI, ponořit se do oblasti JS interops a během relativně krátké doby tak ovládnout celou technologii. Proto je Blazor Server primární technologií, kterou nyní budu školit. Kdo se naučil ASP.NET Core, bude pro něj Blazor Server dalším malým krůčkem. Kdo pochopí Blazor Server, bude mu stačit další (trochu větší) krůček k pochopení rozdílů ve WASM.

Kdy nedoporučuji začít s Blazor WebAssembly

Pokud neznáte vůbec ASP.NET Core framework, nezačínejte přímo s Blazor WebAssembly. Jedině, že byste v životě už nechtěli psát v ničem jiném. Blazor WebAssembly ze své podstaty hostování funguje velmi odlišně oproti všem jiným typům aplikací v NET Core. Vývojáři, kteří například píšou aplikace v tradičním NET Frameworku a nepoužívají ani Dependency Injection se naučí používat novou technologii velmi atypickým způsobem. Po následném kroku například k vývoji REST API / MVC aplikací v ASP.NET Core Vám nebude dost věcí dávat smysl. Velmi zvláštní pozornost se také musí věnovat zabezpečení aplikace. Odlišná je nejen konfigurace, logování a lifetime komponent ale například i způsob autentizace.

Školení Blazor do firmy

Ale zpátky k jádru pudla. Blazor Server včetně zmíněných odlišností je předmětem mého nového školení. V současné době mám kompletní osnovu a nyní vytvářím smysluplné demo. Během srpna budu školení validovat v úzké skupině vývojářů a doladěnou verzi školení začnu ve firmách školit od září 2020. Rezervace termínů jsou možné již nyní. Školení lze objednat zde na webu. Vřele doporučuji této možnosti využít, protože tím získáme ještě čas školení přizpůsobit. Všem týmům posílám podrobnější dotazníky, na základě kterých školení ještě upravuji. Máte tak jedinečnou šanci ovlivnit konečnou podobu školení.


Diskuse

Loading