Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Server remoting using XHR instead of Websockets
See original GitHub issueCorrect me if I’m wrong, but I was under the impression that Bolero’s server used websockets for real-time server remoting. But when I ran the dev server using dotnet run -p ./src/Baseline.Server on the template app (specifically https://github.com/srid/Baseline), and checked the Chrome inspector, the getBooks call is making a new HTTP request, instead using any websocket connection (there is none).
How should I expect it to behave? Are there documentation on this? Can we make the Bolero app using Websocket? What’s the relation to SignalR if any? (I’m new to .NET).
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (1 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
You can run SignalR on the client in WebAssembly mode (blazor docs). My app is hosted with ASP.NET but it might work with other hosting models as well. I ended up dropping the remote services and replacing server-client communication with a SignalR connection hooked into Elmish subscriptions to trigger updates as recommended in this issue. It would be cool if you could setup remoting with a SignalR connection like this out of the box but I haven’t looked into the remoting implementation and it might not be trivial to provide that option.
One disadvantage of the Blazor Server (server=true) approach is that any UI event needs to go over the network along with the resulting html diff. In WebAssembly mode you can do a lot of logic on the client and only send what you need to the server, such as persistence data. There are other considerations nicely outlined here.
Ah, my first question is out of misunderstanding I guess. The render mode is in the context of the server serving a path request, where it makes the decision to just dump the HTML (statically) or have the client build it, or prerender it and hydrate it on client. https://stackoverflow.com/a/58231378/55246
Still not sure why a statically generated response won’t be able to use websockets in the client; Oh maybe something to do with SignalR?
In any case, I’d rather have prerendering enabled anyway, and don’t need the performance of full static rendering. So server=true works for me.