SignalR vs Wasm | Webinar Clips, Blazor Architecture Patterns

So let me touch on the important parts of webassembly versus signalr from an architectural perspective invariably if you've looked at blazer then you've heard over and over and over and over again server side webassembly server side webassembly but let's talk about how to think about that and how to really decide which one is .

Going to be more appropriate for you so it's not just oh you have these options but no no you can really decide you should use one or the other so in blazer server side remember that the only blazer application the only code that is actually running in the browser is a javascript file that microsoft built blazer.js and that is that is the .

Blazer application that is running in the browser and when someone goes to the url they're downloading that javascript app application that javascript file and running it and then that javascript file the code in there immediately is going to establish a websocket connection back to your server wherever it happens to be could .

Be app service and azure or or just a running process somewhere on a test environment it doesn't matter where and then your blazer app your csharp.net process on the server side will be able to constantly push information up to that javascript application that's .

That's running and the javascript application is going to manipulate the dom the document object model in the browser adding elements removing elements changing elements in the browser itself and so if you if you hit f12 and you look at in chrome or edge .

And you look at what's going across the websocket connection you're going to see all these little binary messages it's really really really chatty really really chatty and you know you can't really make sense of it but that's what's that's what is actually being communicated between the .

Uh the client and the server and so if you've never hit f12 and looked at your websocket connection just go ahead and glance over there just to see every time you you know click a button or do something you're going to see a flurry of these little back and forths now they're really tiny they're not text they're .

Binary so they're small compressed and you can see the size here um you know it's measured in in number of bytes and the framework itself is going to have chattiness back and forth but when you actually send some data some data transfer objects maybe from a query to your database and um .

And uh you send it up actually correction you never actually send that up you actually um paint some html on the screen and then the framework makes a diff of the screen and then that data gets sent up because all we're doing is adding html elements to the screen on the server side and .

So think about that because there are a lot of round trips but they're small okay so raw speed is not going to affect the perception of of snappiness of your application however latency and jitter will so go ahead and measure latency and jitter .

If you're if you're thinking about server side just to see if you have a network topology that's going to be compatible with this you don't need the raw bandwidth okay if you are if you're making web server now flip it over to web webassembly you are running net in the browser and if you're going to call over to .

A web service and say hey give me give me the results of this database query and then that that information is going to be packaged up and packaged up is probably json and then thrown over the wire then all of that raw data is coming over the wire and so if you have a .

What effectively is a select all from this table and you have you know 50 50 columns in that table well you're going to get even if you're using entity framework you're going to get all that data you're going to pull it over the wire and then let's say you only use five for a particular screen you only use five properties of the object that's .

Hydrated with that you are going to have pulled over all that data over the wire and then you only use five five fields and so it's a lot of waste and so in those cases you would need to make sure that you have sufficient bandwidth because you're gonna be a little bit wastefulness on raw transfer however when it comes to .

When it comes to jitter and latency you actually only incur the latency one time because you made a web service call and then you got it back now in reality depending on the size of the data the because you're using transfer control protocol tcp there's going to be a lot of different packets going back and forth and so you .

Are going to incur the latency multiple times but not nearly as many as the chattiness of server side and um so when you're when you're thinking about it um we have we have seen in the real .

World scenarios where uh whether it's in in situations where the wi-fi is just kind of spotty up and down whether it's jitter whether it's latency we could be clicking on a button and the only thing that we need is to type the word okay on .

The screen and the server side just not being able to have a snappy a snappy experience because there is other than just writing raw javascript which you can um other than writing raw javascript we need that round trip to the server in order to even paint a .

Response to um to the user to even let them know that their button click was registered we have to get to the server and round trip and if you're on the west coast and then your data center is on the east coast you know you're getting what is it between 10 and 10 and 30 milliseconds .

Sometimes uh just just to jump across the country so you have to think about that you