locked
WASM or Server/SignalR model for data app? RRS feed

  • Question

  • User-1773248901 posted

    I am redeveloping a LAMP app into ASP.NET Core 5.0 with Blazor. 

    The app has a CRUD backend and front end is for display of data using various charts etc. 

    What there is of the GUI is purely for filtering and display of data using assorted data-driven controls (e.g. drop-down lists).  The rest is graphical display of data.

    Let's say user load MAY be up to 20,000.  Server can be scalable (University-based VM).

    Should I go with WASM/Web API or SignalR Server model?  Offline mode is not important.

    Since this app is mainly database driven, I'm thinking it should be Server/SignalR model.  Any reason why WASM might be better for this type of app?

    Thanks

    Peter

    Tuesday, December 15, 2020 7:09 AM

Answers

  • User-474980206 posted

    I'm pretty sure you will have scaling issues with server blazor for your application. 

    offline mode is supported via caching data. say the user fetched the chart data, and is just filtering the chart. this would work without server access. caching does not care how the original data was created, so it works with EF. It all depends on how live the data must be to be useful.

    you don't explain your UI requirements beyond charting. the farther from form fields and click to display, the more difficult you may find it to develop in blazor vs a javascript framework.

    remember the javascript interop is async because under the covers it uses WASM messaging system for WASM or signal/r for server. so you would probably end up writing a javascript content for th charts that blazor called rather than calling d3 directly.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 16, 2020 4:23 PM

All replies

  • User475983607 posted

    Should I go with WASM/Web API or SignalR Server model?  Offline mode is not important.

    My best guess is you are asking if you should use Blazor WASM or Blazor Server.  Blazor WASM is the recommended framework going forward.

    Since this app is mainly database driven, I'm thinking it should be Server/SignalR model.  Any reason why WASM might be better for this type of app?

    Ultimately it is up to you.  SignalR uses web sockets which is a persistent connection to the server.  You app would have potentially 20,000 connections.  You'll need to take that into account.

    The real question is why are you moving to a different framework?  Can you leverage what you've already built?  Generally charts are client side applications.  Blazor WASM will require JavaScript interopt.  Perhaps built a proof of concept before moving forward so you understand what you are getting yourself into.

    Tuesday, December 15, 2020 2:05 PM
  • User-474980206 posted

    Scaling up blazor server is mostly memory. To support 20k user be sure your VM has at least 14 gb memory and 4 procs 

    Tuesday, December 15, 2020 4:01 PM
  • User-1773248901 posted

    mgebhard

    The real question is why are you moving to a different framework?  Can you leverage what you've already built?  Generally charts are client side applications.  Blazor WASM will require JavaScript interopt.  Perhaps built a proof of concept before moving forward so you understand what you are getting yourself into.

    The University no longer supports LAMP stack development for public facing web apps.  Not wanting to debate the pros and cons of that, but it is mainly to do with enterprise architecture, security and support and having a common development framework built around .NET.

    Charting is a mixture of interactive dendrogram trees and heatmaps using d3.js. I would prefer to have native C# charting  but I have not found anything that is comparable to d3.js interactive hierarchical trees.

    I am starting on a proof of concept, hence my question.  If the app is mainly rendering of data, I presumed the server model would be most appropriate. 

    Looking at

    https://docs.microsoft.com/en-gb/aspnet/core/blazor/?view=aspnetcore-5.0

    I would have to use JS interop which is available in both WASM and Server models, which is great, but doesn't help me decide on which model to use.

    One concern is the server model requires the server too handle everything, every interaction.  So scalability may be a problem down the track.

    I like the idea of WASM offline mode though, but since the app revolves around the availability of data from MSSQL Server (using API and Entity Framework Core) offline usage would not be possible, or would it??

    Wednesday, December 16, 2020 1:08 AM
  • User475983607 posted

    pbrowne

    Charting is a mixture of interactive dendrogram trees and heatmaps using d3.js. I would prefer to have native C# charting  but I have not found anything that is comparable to d3.js interactive hierarchical trees.

    D3.js is a JavaScript library that runs in the browser.  An SPA is a better solution if you want to stick with D3.js

    pbrowne

    I am starting on a proof of concept, hence my question.  If the app is mainly rendering of data, I presumed the server model would be most appropriate.

    .

    Having to choose between Blazor WASM and Blazor Server I would go with Blazor WASM for reasons stated above.  I would also craft a REST service with Web API.  If I could choose any solution I would probably go with an SPA and reuse the existing client application rather than starting from scratch.

    Wednesday, December 16, 2020 1:43 AM
  • User-474980206 posted

    I'm pretty sure you will have scaling issues with server blazor for your application. 

    offline mode is supported via caching data. say the user fetched the chart data, and is just filtering the chart. this would work without server access. caching does not care how the original data was created, so it works with EF. It all depends on how live the data must be to be useful.

    you don't explain your UI requirements beyond charting. the farther from form fields and click to display, the more difficult you may find it to develop in blazor vs a javascript framework.

    remember the javascript interop is async because under the covers it uses WASM messaging system for WASM or signal/r for server. so you would probably end up writing a javascript content for th charts that blazor called rather than calling d3 directly.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 16, 2020 4:23 PM