I know that it uses SignalR and requires a consistent connection over the network, and this mean there will be some kind of sticky session problem, which also mean we cannot just scale the deployment like in k8s in a braindead easy way.
I heard that SignalR can be configured to use a Redis backplane, but there doesn't seem to be an easy to do it with ASP.Net core, what steps do I need to do to scale server side Blazor, where the core part is about scaling SignalR? How do we integrate it with cloud native load balancers?
You can use Azure SignalR for scaling the connections in Azure. The docs might help you out on this.
Related
I'm planning to buid a Server Side Blazor application.
It will be containerized with Docker and deployed to Amazon AWS, so in order to handle the scale-out for the service I don't have the option to use Azure SignalR service as Microsoft recommends in their documentation (see https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/server?view=aspnetcore-3.1#signalr-configuration).
We are curently using Redis as a backplane to manage our SignalR connections for another service, and I was wondering if it is possible to also use it in the same way for the Server Side Blazor application (see https://learn.microsoft.com/en-us/aspnet/core/signalr/redis-backplane?view=aspnetcore-3.1).
What do you think?
Thanks,
Xavi
I Have ASP.NET Core project and want to make it work also with PWA and it needs to work also offline.
I know there are prefetch and preload options but i'm little bit confused
How to achieve that?
Thanks
First, the PWA and the service worker itself are decouple from the server, which in your case is ASP.NET.
As far as what you cache and how that is all up to you. You need to determine what is best for your user experience.
In a way, the service worker can be thought of as a web server and you have to code the application layer to manage your requests.
DO NOT go nuts and try to recreate your ASP.NET and all the server logic in the service worker. Not what you should do there. Seen that too many times already.
I have an article covering basic service worker caching concepts if that helps.
https://love2dev.com/blog/service-worker-cache/
I am building a micro-service-oriented .NET Core web application and now I want to add real-time communication. It is possible to create a SignalR server and publish it on Azure? I want to use it in my microservices to send messages to users when a certain even occurs.
Yes, you can deploy your app to Azure and point your users to your hub endpoint with no problems. You have two options here:
Use SignalR and manually manage the connections and other signalR stuff if you will scale your application. For example, when you have 2 web apps and the client connects to one of them, you need to "tell" to other app that you have a new client connected using for example Redis Blackplane.
Use Azure SignalR and this kind of management is not needed, what you need to provide is only 1 app with the hub logic. So when a client connects to your hub it is automaticaly redirected to the Azure SignalR.
You can read more about this two options here:
https://learn.microsoft.com/pt-pt/azure/azure-signalr/signalr-concept-scale-aspnet-core
Why not deploy SignalR myself?ยด
It is still a valid approach to deploy your own Azure web app supporting ASP.NET Core SignalR as a backend component to your overall web application.
One of the key reasons to use the Azure SignalR Service is simplicity. With Azure SignalR Service, you don't need to handle problems like performance, scalability, availability. These issues are handled for you with a 99.9% service-level agreement.
Also, WebSockets are typically the preferred technique to support real-time content updates. However, load balancing a large number of persistent WebSocket connections becomes a complicated problem to solve as you scale. Common solutions leverage: DNS load balancing, hardware load balancers, and software load balancing. Azure SignalR Service handles this problem for you.
Another reason may be you have no requirements to actually host a web application at all. The logic of your web application may leverage Serverless computing. For example, maybe your code is only hosted and executed on demand with Azure Functions triggers. This scenario can be tricky because your code only runs on-demand and doesn't maintain long connections with clients. Azure SignalR Service can handle this situation since the service already manages connections for you. See the overview on how to use SignalR Service with Azure Functions for more details.
Yes you can, this is the official quick start sample.
https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-quickstart-dotnet-core
I'm planing on creating an native .net app for Windows as well as a native OSX application with swift.
These two applications should be able to communicate with the same server. With that I mean writing and reading from the same SQL Database, and have REST communication with the server.
Now I'm struggling to come up with a solution for the backend. I'm looking into Serverless backends like Azure or Google Cloud, but I'm not sure that I can use these Services with both my applications. Both Azure and Google Cloud have SDKs for .Net but I've never found one for Swift or Objective-C.
Are there such Services that allow me to communicate or should I just develop my own?
Do you have any good solutions for my problem? Or what is the best server architecture to use for this kind of problem? Any inputs are appreciated!
If your servers vend a REST API, no vendor SDKs should be required. REST is platform- and vendor-agnostic. All you need is an HTTP client, which Swift/ObjC most definitely do have. I use a serverless (AWS Lambda) setup from Swift, and it's easy. Though, I have done this kind of thing before :)
What I would do is setup a simple test server, and expose an API endpoint. Make sure you can reach it with curl from your machine. Then, take a look at the NSURLSession APIs in Foundation. They'll help you make an HTTP request similar to what curl can do. From there, you'll need to investigate serialization (like JSON), which Swift can also do easily (as of Swift 4, I believe).
Good luck!
I have one WPF client-server application. Now I have scenario like client will connect to server and server will push data to client periodically. I am bit confused about what technology and way should I choose for notification to clients.
SignalR is best for web application I think and I have desktop application. With WCF service, we can implement push notification through Duplex channel and callback. So can you please guide me what are the merits and demerits in using SignalR or WCF service ?
Thanks
Below are my observations from experiences:
SignalR pros:
Easy to startup, lower learning curve. You can easily run an example found from web
Exception handling (e.g. connection drops, timeouts) is embedded inside the API
SignalR cons:
Only supporting HTTP protocol
Duplex pros:
Supports TCP in addition to HTTP. This may be a serious performance gain if you know your client types and your system is working in a closed network. Also, working over TCP adds more connection stability than HTTP
Duplex cons:
Higher learning curve - harder to startup and have a stable solution. Want to verify it? Download a duplex and a SignalR sample from the web and see how much time you will spend to successfully run each other.
You need to handle all the exceptional cases (connection drops, timeouts, etc.)
I know I am not the only one who faced serious timeout problems when you want to use the duplex service for a long time. We need to make service calls periodically to keep client connections alive.
By the way, there are APIs exist for JavaScript, Desktop and Silverlight projects to consume SignalR services.
SignalR is not just about web. SignalR server side code does not care about the technology of its clients, you just need to have implementors at the client side.
If we isolate pusing data to the client, I would strongly recommend SignalR as it's much simpler than WCF in this aspect, I had my share of problems with WCF and I guess you had some yourself.
I found a simple console/web application sample here.
In general, Duplex WCF and using Callback like here seems very messy to me, there is a lot of configuration server side and this is why I think SignalR is simpler.
In addition, you can't use duplex (AFAIK) with javascript and objective-c.
I think you already got lots of data points about each of them. But selection of SignalR will provide you added advantage over development efforts which is in most of cases major decision block while selecting a technology.
You don't need to worry about API development / testing etc. and can have focus on your own implementation of the project.
Hope it helps!
SignalR can easily be used now with multiple clients from javascript, .NET both WinForms and WPF, and can even be used with a C++ client; Using a self hosted .NET signalr server (OWIN) is really nice way to have a standalone server that pushes / receives / broadcasts to multiple clients. The only thing that may be easier is ZeroMQ using its publish subscribe methodology.
One point that nobody has raised so far:
SignalR 1.0.1 requires .NET 4 on the server and client. Depending on
the version of your client and server that you are targeting that
might be an important factor to consider.
If you just want to update periodically for new data, you might be better to just use WCF and a polling mechanism from the client side rather than using either duplex WCF or signalr.