Porovnání Blazor Server a Blazor WebAssembly

Blazor Server a WebAssembly trochu jinak

Viděl jsem desítky videí a četl stovky článků od nadšenců do těchto technologií. Teprve když jsem poslední měsíce začal s Blazorem experimentovat a propojil si souvislosti mimo svět Microsoftu, začala se skepse rozvíjet i v mé hlavě. Většina nadšeneckých informací, které totiž konzumujeme, jsou silně přifouknuté a zkreslené. Rád bych Vám v tomto delším článku poskytl pohled na to, jak Blazor vnímám já. Bude to velmi netechnický článek, kde se zaměřím na aspekty, které podle mého názoru komunita včetně Microsoftu nešťastně přehlíží a ignoruje vlivem izolace od okolního světa.

Pro pochopení souvislostí je nutné vzít v potaz několik faktů. Blazor obecně zahrnuje celou řadu technologií pro celou škálu zařízení. Já budu v tomto článku psát výhradně o webových verzích Blazor Server a Blazor WebAssembly. Bez ohledu na Vaše znalosti se dále dohodněme, že po zbytek seriálu budeme považovat Blazor Server a Blazor WebAssembly za dvě zcela odlišné technologie. Je to kriticky důležité pro pochopení souvislostí. Na konci článku budete chápat, proč jsem tento předpoklad hned na začátek textu položil.

Tři roky v blejzru

O Blazoru se mluví a píše velmi dlouhou dobu. Poslední roky Microsoft vyšíval primárně na Blazor Server / Blazor WebAssembly a mainstreamová technologie MVC poněkud zaostávala. Vývojáři se dočkali jen drobných vylepšení, přestože zejména oblast REST API by si zasloužila více péče. Namísto podpory existujících aplikací a lepší implementaci přijatých standardů, jako například OAS vsadil Microsoft na nového koně. To se zdálo zpočátku jako dobrý nápad. Na papíře Blazor WebAssembly vypadal sexy. Potíž je v tom, že to bylo ještě někdy v roce 2017/2018. V té době se už dlouhou dobu mluvilo o standardu WebAssembly (dále jen WASM) a možnostech využití. Kdyby se naplnily prognózy webových věštců, měli bychom dnes hromadu technologií postavených nad WASM a svět JS by hořel v plamenech. Poslední statistiky však nic takového nenaznačují. WASM se od roku 2015 rozvíjel dramaticky s příspěním Mozilly, Microsoftu, Googlu, Red Hatu a všech těch technologických gigantů. Poslední roky vystagovnal WASM do jakéhosi MVP a teď to trochu působí, že konsorcium čeká, co bude dále. Microsoft není sice jediný, komu se WASM dostal do hledáčku, je však o velký krok před ostatními. A to s technologií Blazor WebAssembly. Opět je potřeba si uvědomit, že tenhle závod začal někdy v roce 2017. Již zhruba v polovině roku 2017 si střihli Steve Sanderson, Dan Roth, Damian Edwards a spol. první Blazor hackaton, jehož pozůstatky jsou dodnes na GitHubu. Od té doby utekly 3 roky.

Když se ostatní perou a poslední si hraje

Mezitím, co si kluci v Microsoftu hráli s Blazor WebAssembly se začala dramaticky měnit situace ve světě front-endu. Pro zjednodušení budu po zbytek článku používat front-end jako obecný pojem pro klientské technologie z pohledu MS vývojáře. Poslední roky se firmám dařilo a v informačních technologiích vzniklo nepočitatelné množství projektů. Chápejte to tak, že peníze lítaly okny a nikdo se nebál příliš experimentovat. Webovému frameworku WebForms zazvonil umíráček a MVC začal hrát na platformě .NET / .NET Core prim. Jenomže způsob fungování MVC aplikací nikdy nebyl příliš konkurenční kombinaci JS frameworků a REST API. Přestože vývojáři v .NET Core zuby nehty všude cpali jQuery, nedokázali konkurovat vymazleným SPA aplikacím. Vývojářům tak v posledních letech nezbyla jiná možnost, než okusit některý z JS frameworků. Pro další pochopení dění v letech 2017 až 2020 nám může posloužit StackOverflow Survey z těchto let. Záměrně si vyberu pro nás důležité technologie. Následující čísla ukazují oblíbenost jazyků v letech 2017 až 2020 v procentech:

• JavaScript z 62.5 - 69.8 - 67.8 - 67.7
• C# z 34.1 - 34.4 - 31.0 - 31.4
• TypeScript z 9.5 - 17.4 - 21.2 - 25.4

Z čísel je patrné, že oblíbenost JavaScriptu vůbec neklesla a také je vidět, že oblíbenost jazyka C# rozhodně nevzrostla. Excelentně se dařilo TypeScriptu, který je dnes používán společně s většinou JS frameworků. Samozřejmě je tato čísla nutné brát s rezervou. Poskytují nicmén základní obrázek o tom, že ve světě programovacích jazyků se mimo TypeScript revoluce nekonají. Podobně dobře se už dařilo pouze Pythonu.

V kategorii frameworků je situace komplikovanější, protože se v různých letech za frameworky považovalo vždy něco jiného. Pro zjednodušení budu ve zbytku článku do frameworků řadit i jQuery a React, přestože se jedná technicky o knihovny. Za poslední 4 roky:

• lze stále za krále považovat jQuery (což je na prehistorickou knihovnu úctyhodné)
• React jednoznačně předběhl Angular a nadále se mu vzdaluje
• ASP.NET a .NET Core jsou na tom víceméně stejně (a pro zajímavost výrazně lépe než Laravel v PHP)

Mezi nejrozšířenější front-endové frameworky dnes patří React.js, Angular / Angular.js, Express a Vue.js. Jaká je situace ve světě .NETu z žádné ankety nevíme. Z konzultací ve firmách to vnímám jako plichtu mezi Reactem a Angularem. Samotný .NET Core a C# se sice těší oblibě, nelze ale pozorovat žádnou výraznou migraci vývojářů od konkurenčních technologií. Vývojáři z jiných platforem (zejména Java) spíše používají .NET Core na výpomoc.

Mezitím, co Microsoft vyšíval na Blazor WebAssembly a Blazor Serveru (který nám přihrál spíše ze zoufalství), dotnetí vývojářské firmy se naučily používat kombinace JS frameworků a REST API. Nic jiného jim ani nezbylo. Vývojáři mají ve Visual Studiu dlouhodobě k dispozici šablony jak pro Angular tak pro React projekty s REST API backendem. Firem, které by doposud nezačaly s vývojem SPA je stále méně.

Blazor WebAssembly je od května v GA - není však stále deklarován jako LTS. Jedná se tedy o technologii, která vstupuje na přebraný trh pouze s 3 měsíčním supportem. Ještě k tomu v době, kdy firmy kvůli koronaviru seškrtávají rozpočty a jejich nálada investovat do nových technologií a vzdělávání je tatam. S ohledem na historii mnoha jiných technologií od Microsoftu, například Silverlight, lze chápat ze strany vývojářských firem jistou zdrženlivost.

Posedlost full-stackem

Nyní hodím vidle mezi Blazor WebAssembly a BlazorServer. Aby bylo jasno, Microsoft nikdy nepovažoval Blazor Server jako primární technologii. Když pročítám články vývojářů a program manažerů z Microsoftu, vždy z nich cítím vůni a posedlost full-stack vývojem. Zde vnímám velký rozdíl mezi Microsoftem a konkurenčními firmami. Potíž je především v tom, že Microsoft věnuje extrémní množství energie k vytvoření něčeho, co trh zkrátka nechce nebo nepotřebuje. Tím se odlišuje od často zmiňovaného Applu, který zpravidla tvoří něco, co trh potřebovat bude, ale ještě o tom neví. Když tedy napíše nadšeně Daniel Roth "Full stack web development with .NET is now here!", nelze než nechápavě kroutit hlavou a ptát se proč.

Mezi základní výhody Blazor WebAssembly patří z pohledu Microsoftu právě možnost "full-stack" vývoje v jazyce C# místo JavaScriptu. Samosebou s tím je obvykle zmiňována skvělá výkonnost a pak pár marketingových výhod, které jsou spíše nezbytností. S ohledem na již zmíněné statistiky a historii je však otázkou, kdo je cílovou skupinou Blazor WebAssembly. Těžko si představit nadšence front-endu migrující od JavaScriptu k C# a .NET Core. Stejně tak podivná je představa PHP backendistů nebo Java backendistů hrnoucích se do vývoje front-endu v Blazor WebAssembly. Kdyby se něco podobného mělo stát, už by se tak dělo dávno migrací na .NET Core. Dle statistik nám ale obliba .NET Core ani C# nijak zásadně nevzrostla. Blazor WebAssembly tak zůstává sexy opět jen pro některé .NET vývojáře. A navíc tak jednoduché to není.

Myšlenka full-stack vývoje je dnes překonaná. Nechat backend vývojáře sahat do front-endu nedopadá dobře. Bavíme se o uživatelském rozhraní, použitelnosti, kvalitě produkovaného HTML a CSS s ohledem na SEO faktory, bavíme se o JavaScriptu / TypeScriptu a frameworku nad ním. To všechno by měl společně s backendem vývojář zvládat? Full-stack development je obyčejné zotročování vývojářů k široké paletě činností za mizernou finanční odměnu. Dokud to vývojářské baráky (zejména ty orientující se na .NET a na Javu) nepochopí, budou manažeři vyhazovat peníze za HR a fňukat do kapesníků s tím, jak málo je kvalitních lidí. Kvalitní člověk nemůže nikdy pokrývat takovou škálu kompetencí, jakou si firmy představují. Lidé přitom v dnešní době více než kdy jindy chtějí žít smysluplné životy a relaxovat. Vývojáři živící se dlouhé letní noci zářením z monitoru jsou spíše výjimkou. Když si připustíme, že full-stack je zkrátka přežitek, bude jednodušší si uvědomit, že Blazor WebAssembly toho zase tolik nepřináší. Je zkrátka jen další UI framework.

Kde není API, tam pšenka nekvete

Ať už jsou Vám poslední odstavce sympatické či nikoliv, můžeme se na celou oblast podívat i jinou optikou. Blazor WebAssembly je UI framework. Je to často přehlížený fakt. S ohledem na bezpečnost a typické scénáře užití dojdeme k jednoduché skutečnosti - Blazor WebAssembly slouží k vytvoření UI, které bude muset stejně vždy komunikovat s REST API. Minoritní případy nemá příliš smysl provařovat. Zkrátka celá myšlenka full-stacku je postavena spíše na tom, že vývojář si vystačí se C# a .NET Core. JS prý nebude potřebovat. Z této mylné představy ale procitnete po prvních hodinách práce s Blazorem bez ohledu na model hostování. O JavaScript začnete zakopávat velmi brzy a díky interops bude práce s ním ještě větší pruda, než v přirozené podobě. Nehledě na to, že většina současných JS frameworků vývojářům už stejně nabízí luxus TypeScriptu, který jako by jako z oka síšarpu vypadl. Jak by ne, když společným architektem je Anders Hejlsberg. Koneckonců už jsme si ukázali, že obliba TypeScriptu za poslední roky extrémně vzrostla. TypeScript je v podstatě průmyslový standard a JS se lze velmi jednoduše vyhnout.

Po konečném součtu nám tedy zbývá UI framework, který nás od JS jen trochu odstíní a je tak vlastně jen alternativou k ověřeným JS frameworkům jako Angular nebo React. Jako alternativa se však nikdy široce neuchytí, protože ona výhoda jazyka C# je zároveň nevýhodou pro všechny ostatní komunity. Máme tu komunitně specifický framework s mizernou podporou ze strany výrobce, který zatím nikdo moc neovládá, který nebyl zatím ověřen na žádných větších projektech a ke kterému zatím neexistuje velké množství neplacených komponent. Pokud nemáte hluboko do kapsy, můžete samozřejmě sáhnout po DevExpress, Telerik nebo jiných, a ne zrovna laciných komponentách. Další náklady Vás bude stát proškolení týmu a vyšlapávání slepých cestiček, protože samotná technologie je ještě příliš mladá. Vývojářů ovládajících Blazor WebAssembly je méně než šafránu, takže s hledáním vhodných kandidátů do týmu přeji mnoho štěstí.

Jít cestou Blazor WebAssembly znamená odvážnou investici s velmi nejistým přínosem. Alespoň taková je situace v srpnu 2020. Microsoft rozehrál zkrátka hru, ve které bude muset do sebe zapadnout příliš velké množství kostiček. Většina týmů pravděpodobně bude vyčkávat a nadále zvolí jistou cestu kombinace REST API a ověřeného JS frameworku. Šikovného React či Angular vývojáře si i menší studio najme za pár šupů a s jeho pomocí se naučí technologii i další členové týmu. Blazor WebAssembly koneckonců není o nic jednodušší ani složitější než dnešní front-end frameworky. Mnoho zmíněných nevýhod vychází z toho, že Blazor WebAssembly je ještě mladá technologie. Časem se situace může změnit a Blazor WebAssembly zaujme ve světě .NETu čestou pozici. V prostředí konkurenčních JS platforem však nemá podle mého názoru sebemenší šanci prorazit. WASM není argument.

Než začnete ronit slzy, vezte, že je tu blejzr, který Vás zahřeje.

Když nedáte malovaný, dejte aspoň bílý

Nyní bych se rád vrátil zhruba do poloviny roku 2018. V té době se na Blazoru vyšívalo už celkem dlouhou dobu na to, aby si vývojářský tým uvědomil, že jsou sotva v první zatáčce celé své velkolepé práce. V tehdy ještě experimentálním vydání Blazor 0.5.0 se poprvé objevila technologie Blazor Server (tehdy Server-Side Blazor). Technologie Blazor Server byla postavena na jednoduché myšlence. Blazor poběží na straně serveru a interakce v UI se odhandlují skrze SignalR. Tedy každá interakce v UI způsobí odeslání dat po SignalR na server, kde se efektivně vygeneruje diff se změnami, které se zpropagují zpět do UI. Uživatel má v konečném důsledku stejný pocit, jako kdyby pracoval s SPA aplikací. Přestože tento model hostování komunitu obecně nenadchnul, v praxi nabízí přesně to, co Microsoft slibuje v onom zprofanovaném "full-stack vývoji na .NET Core".

Blazor Server byl od počátku vnímán jako ústupek. Cesta k finální verzi Blazor WebAssembly byla ještě dlouhá. Projekt byl stále zcela experimentální a bez příslibu, že bude dokončen. Na klienta se tou dobu pořád ještě přenášela velká data a debugging experience byla téměř na nule. Nápad s Blazor Server dával dokonalý smysl. Oproti Blazor WebAssembly je totiž postaven na ověřených a funkčních základech .NET Core a ASP.NET Core. Běží na straně serveru, tedy všechny moduly (DI, logování, konfigurace) fungují tak, jak je vývojář zná. Plně funkční je logicky i debugging a na klienta se přenáší jen vyšší desítky kilobajtů JS kódu. Systém komponent je stejný, takže není nic jednoduššího, než přidat onu SignalR komunikaci. Dotáhnout ke svému konci Blazor Server bylo pro vývojáře v Microsoftu mnohem snazší, než Blazor WebAssembly. V prosinci 2019 je vydán ASP.NET Core verze 3.1 a součástí LTS releasu je i Blazor Server. Verzi Blazor WebAssembly tak výrazně předstihl. LTS verze Blazor WebAssembly není v srpnu 2020 stále k dispozici.

Blazor Server - Z outsidera lídrem

Blazor Server osobně považuji za mnohem smysluplnější technologii než Blazor WebAssembly. Z dosavadního textu je zřejmé proč. Samotná WebAssembly mi osobně přijde přeceňovaná a nic nenasvědčuje tomu, že bych se v tomto ohledu mýlil. Stačí se podívat na stav W3C standardu a relativně malé množství frameworků, které se s WebAssembly snoubí. Za těch několik let se z toho nikdo na zadek neposadil.

Na rozdíl od Blazor WebAssembly je Blazor Server součástí LTS releasu. Pokud jej tedy použijete, máte jistotu podpory minimálně do prosince 2022. Technicky je Blazor Server postaven na již ověřených technologiích. Běží na straně serveru a využívá většinu toho, co znáte v .NET Core aplikacích. Stejným způsobem tedy používáte například dependency injection, logování nebo systém konfigurace. Nové pro vás budou především komponenty a vše, co s nimi souvisí. Model hostování navíc používá SignalR (typicky WebSockety), čili další ověřené technologie. Naučit se Blazor Server pro vás bude o něco jednodušší, než Blazor WebAssembly.

Protože běží Blazor Server na straně serveru, nemusíte řešit žádné specifické otázky spojené se zabezpečením aplikace. Platí stejné zásady, které znáte z jiných ASP.NET Core aplikací. Oproti Blazor WebAssembly se neposílají DLLka na klienta. I když je doporučené použít Blazor Server pro vývoj UI a komunikovat proti REST API, můžete zcela bez obav komunikovat i přímo s databází například s využitím EF Core nebo Dapperu. V tom vidím velký benefit, protože právě REST API řada týmů vytvářet nechce. Stavíte-li aplikaci, kde máte mnoho různých specifických dotazů, nebude REST API naplňovat Vaše představy. V Blazor Server naštěstí můžete používat běžnou architekturu aplikace jak jste zvyklí a skrze repozitáře posílat optimální dotazy do DB. Single codebase je luxus, který si v Blazor WebAssembly nebudete moci dovolit.

Aplikace postavené na Blazor Server budou mít nepatrně širší podporu v prohlížečích. V řadě případů to nic neznamená a v řadě případů to může znamenat rozdíl plus mínus procento z obratu (například v e-commerce). Na stranu klienta se nepřenáší žádný velký balík dat a spuštění aplikace tak bude vždy rychlejší. Samotná komunikace po SignalR je standardně také velmi rychlá. Oproti WebAssembly je často zmiňována nevýhoda v podobě rychlosti. SingalR samozřejmě oproti aplikaci běžící na klientovi způsobí síťovou latenci, nebude se však jednat o nic dramatického. Podle měření, která zveřejnil Microsoft bude aplikace běžící na Standard D1v2 Azure plánu (1 virt. CPU + 3.5 GB RAM) schopna obsloužit v jeden moment až 5.000 klientů bez znatelného vlivu na výkonnost. To by stačilo i českému rohlik.cz zvládnout těžké chvíle během koronavirových nákupů (rohlík avizoval něco přes 3.000 uživatelů během březnových špiček). To je pro naprostou většinu aplikací zcela dostačující. Komu by ani toto nestačilo, může vertikálně naškálovat na výkonnější stroje. Škálování je obvykle zmiňováno jako nevýhoda Blazor Server aplikací, byť jeho pozice je víceméně stejná jako v případě většiny dnešních monolytických aplikací. Aplikace Blazor Server může být zranitelnější vůči nárazovému trafficu (DDoS útoky) a je nutné ji bezpečně ochránit. Samotná síťová latence může vadit ve scénářích, kdy je vyžadována plynulá reakce na změny v UI. Příkladem budiž reakce na pohyb myši nebo posun sliderů. Pokud výše uvedené vezmete na vědomí, dokážete s tím snadno pracovat.

Vzhledem k tomu, že Blazor Server potřebuje kontinuální připojení k serveru, může Vám chybět podpora off-line módu. Jestliže jste nikdy aplikace podporující off-line mód nevytvářeli, zřejmě to oželíte i v tomto případě. Vývoj aplikace s podporou fungujícího off-line režimu je velmi náročný. Uživatelé se připojují z více zařízení a způsobují na datech změny, které není jednoduché následně sjednocovat. Proto se podpoře off-line vývojáři často cíleně vyhýbají. Pokud jste výjimkou, Blazor Server Vám podporu pro off-line mód neposkytne.

Blazor Server není dokonalá technologie. Má svá omezení, která ji ubírají na univerzálnosti. Vývojáři přitom hledají kladivo na všechno. Své doby jím byly WebForms i MVC. Dnes kombinace oblíbeného JS frameworku a REST API. Přesto má Blazor Server řadu nesporných výhod. Pro řadu týmů se stane výchozí technologií pro vývoj aplikací a pro další týmy bude alternativou pro specifické druhy projektů. Blazor Server bude excelovat v podnikových aplikacích, intranetech, různých CRM, CMS a v systémech podobného charakteru.

Další blejzry ve skříni

Jak jsem naznačil v úvodu, existuje více variant technologie Blazor. Architektura Blazoru je navržena tak, že dostatečně chytře odděluje způsob provádění změn v UI a způsob, jakým jsou změny na UI aplikovány. Právě druhá část je realizována pomocí rendererů, kterých existuje hned několik. Vedle těch webových například Electron Renderer nebo MobileBlazorBindings Renderer. Čili s použitím Blazoru by mělo být stejně možné postavit mobilní nebo desktopové aplikace využívající nativní prvky cílové platformy. Bavíme se o experimentálních verzích produktů, kterých existuje mimochodem ještě o něco více, než pro jednoduchost zmiňuji. Blazor je ambiciózní technologie s celou řadou zajímavých hostingových modelů a možností. Přes neskutečnou šikovnost a odhodlání vývojářů se však vzhledem k velikosti týmu vyvíjí extrémně pomalu.

Svého času nás Microsoft oslnil skvělým Windows Phonem. I ten ale vstoupil na rozebrané trhy a díru do světa neudělal. Obávám se, že zmíněný Blazor WebAssembly čeká podobný osud. Nakonec se snad dočkáme LTS verze a Blazor WebAssembly se stane alespoň komunitně uznanou technologií. S ohledem na očekávání Microsoftu je však otázka, zda je toto vítězství, pro které bude Microsoft technologii dále ochoten rozvíjet. S ambicemi dobít svět front-endu to totiž může skončit debaklem.

Blazor WebAssembly a Blazor Server jsou často považovány za jednu technologii s odlišným hosting modelem. Tato na první pohled drobná odlišnost ale kompletně mění pravidla hry a smysl celé technologie. Ačkoliv chytře napsané komponenty bude možné mezi oběma verzemi přenášet, způsob vývoje aplikace je do značné míry odlišný. Přechod mezi Blazor Server a Blazor WebAssembly je u větších aplikací (bez dodatečného cíleného úsilí) spíše utopie. Více utopický scénář pak platí pro migraci z Blazor Server nepoužívající REST API na Blazor WebAssembly.

S ohledem na stav technologií k srpnu 2020 mohu za sebe vřele doporučit začít s Blazor Serverem na projektech, pro které dává naprostý smysl a nespoléhat se na scénáře zahrnující migraci z jednoho modelu na druhý. Je-li pro Vás vhodnější Blazor WebAssembly, doporučuji vyčkat do vydání LTS verze produktu, jakožto "příslibu", že to Microsoft myslí vážně a nedá od svého díla ruce pryč. Máte-li již sehraný tým, který staví aplikace metodou REST API + Angular/React/Vue.js, pak bych doporučil se této metody minimálně pro rok 2020 držet a úsilí raději nasměrovat do vylepšení procesů, komunikace mezi FE a BE týmy nebo nastudování Blazor Server.

Věřím, že Vám článek pomůže udělat správná rozhodnutí.

📹 Video: Blazor WebAssembly

📹 Video: Blazor Server