Ogólnie @wloochacz dobrze to opisałeś. Działa to faktycznie podobnie jak react - wyliczanie diffa DOMu odbywa się na backendzie i ten diff jest wysyłany do przeglądarki przez websocketa.
W takim razie ten virtual DOM na backendzie rozpycha sesję (DOM może sporo ważyć, zwłaszcza gdy mamy np tabelkę 20 kolumn x 1000 wierszy) i może spowodować problemy ze skalowaniem (zawartość sesji jest na tyle skomplikowana i zmienna, że trzeba trzymać ją bezpośrednio w procesie serwera).
Istotnie, sam MS wyraźnie o tym pisze i nie ukrywa, że ta technologia nie zawsze i do wszystkiego jest OK.
Poza tym, Blazor posiada 3 modele hostingowe dla swoich aplikacji:
- Blazor on ASP NET
- Blazor WebAsembly
- Blazor Server
Pierwszy i drugi są bardzo podobne do siebie (sam w sumie jeszcze nie do końca wszytko dokładnie rozumiem, a więc nie wypowiem się teraz).
Trzeci - to już wiadomo.
Najlepsze informacje na ten temat znalazłam u Telerika:
https://www.telerik.com/blogs/a-breakdown-of-blazor-project-types
Dość powiedzieć, że w moim VS.Studio 2019 mam do wybory takie projekty:
I bądź mądry co jest co ;-)
Mogę jeszcze opisać co ma być kiedyś, ale wolałbym dyskutować o tym, jak już będzie ;-)
Jak Blazor sobie z tym radzi? Np co jeśli mamy 100 aktywnych użytkowników z których każdy ogląda tabelkę 20 kolumn x 1000 wierszy i te tabelki się zmieniają np raz na sekundę dochodzi nowa pozycja w losowym miejscu?
Dokładnie to nie wiem.
MS pisze, o tu:
https://devblogs.microsoft.com/aspnet/blazor-server-in-net-core-3-0-scenarios-and-performance/
o tym problemie w ten sposób:
In our tests, a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency. A Standard_D3_V2 instance (4 vCPU, 14GB memory) handled well over 20,000 concurrent clients. The main bottleneck for handling further load was available memory. Will you see this level of scale in your own app? That will depend in large part on how much additional memory your app requires per user. But for many apps, we believe this level of scale out is quite reasonable. We also plan to post additional updates on improvements in Blazor Server scalability in the weeks ahead. So stay tuned!
My mamy aplikację tego typu, tzn trade blotter z dynamicznym odświeżaniem, ale mamy problem ze skalowaniem, więc obsługujemy bardzo małą ilość aktywnych użytkowników (max kilkadziesiąt naraz). Zakładamy, że po przeniesieniu się na SPA ze stanem po stronie przeglądarki skalowalność mocno się polepszy.
Istotnie, to może być problem.
Poczekamy do maja, wtedy dowiemy się więcej.