Server-side Blazor maintains connection to the server-side apparently, using SignalR.
SignalR is the service you need to pay for. As many simultaneous connections to SignalR are going to be used as many online users your app has at the moment of time.
Do I understand correctly, that I will need to pay for next SignalR tier once I reach certain SignalR free tier limit? And only because I use Blazor, not that I use SignalR for other purposes.
And two cost-reduction alternatives are:
use client-side Blazor WebAssembly
don't use Blazor at all
We run 3 instances of P3V3 app service to serve ~450 users (it is a LOB app, so open by most users, most of the day)
Our SignalR service cost is double the app service plan.
You can use signalr over websockets instead of the SignalR service, but for some unknown reason it is unstable and you'll see lots of signalr connection drop outs.
There's no way to save costs on SignalR - no reservations, no bulk discounts.
Related
We have an application which has set of APIs developed in .NET CORE and UI which consume these APIs developed in Angular(both are independent projects) . Both are hosted on azure app service.
WebAPI integrates with 3rd Party APIs. Some of those transactional
APIs are very time consuming, so we want to have fire and forget way
of calling those and have them notified when they end.
Once our API receives the response from 3rd party, we want that be notified to UI
So we want some messaging or Pub-Sub mechanism to achieve this
I am in consideration of SignalR and Kafka.
From the documents that I red about SignalR it seems that it can be used between API -client, so I can use this for 2nd scenario.
Can SignalR be used between 2 APIs?
Coming to Kakfa , it seems to be good one for high end data streaming which I consider as over-engineering for our requirement.
Our application will be on both Azure and on-prem so we also went through Azure service bus but there is limit on Message length and cost seem to be problem for us.
So I want to know if there are any ways I can have this communication eased between 2 WebAPIs application?
We're building a real-time Web-based monitoring system for .NET applications (ASP.NET and Windows executable). Those applications can start a long-running operations and statistics are displayed in real-time on Web page.
For ASP.NET ones we found SignalR a perfect solution: Long running operation (even caused by simple WebForms form postback) periodically call JS client-side functions via SignalR RPC to update monitoring page. But we hit 2 caveats:
In ASP.NET we need to monitor several different apps located in several different virtual directories. How do we push data from those different apps onto a single HTML monitoring page?
Another app is a .NET Windows console executable that runs periodically on a schedule. How do we push its run-time statistics to the same monitoring HTML page? One thing comes to mind - have EXE store temporary statistics in a DB and have client pull same data from the DB, but we'd like to avoid polling. Another - periodically at a given intervals the EXE would call the WebApp, passing the data - and WebApp would pass it to client via the same SignalR call. But are there better ways?
One architecture that I've used is a small monitoring collection service, with embedded monitoring clients in every monitored application, Asp.net, Windows desktop app, console app, Windows service, or otherwise.
The collection service is always running. A webapp then connects directly to the service and requests the state of all monitored apps.
Monitored apps run some small embedded client that feeds back application-specific metrics to the monitoring service. The client can either provide data on events or timers, or the monitoring service an ask for it on a timer itself.
With this, we have a unified monitoring architecture - everything that runs just talks to the monitoring service to send updates, and the health viewer clients just ask the service for data using a unified protocol.
It's basically the Application Server pattern applied to monitoring, and takes a couple cues from the design of SNMP.
Very new to SignalR, didn't realize it has multiple clients for different platforms. We will go with SignalR .NET client for all the apps - they will all talk to main SignalR hub directly invoking server-side methods, which in turn update monitoring page.
I am having trouble wrapping my head around whether or not my scenario will require scale out. I have a process in a windows service that pushes messages to a hub hosted in a web app via the signalr .net client. These are user specific messages and are distributed using the Client(connectionid) approach. If this is deployed in a web farm scenario will I need to use a scale out approach? When a user joins I am storing that connection info in the database. I store the url of the webserver and connectionid so I can target that when I publish messages from the windows service.
I would use this if it is an option.
http://www.asp.net/signalr/overview/performance/scaleout-with-windows-azure-service-bus
Louis
I have the following scenario in my project :-
The client makes use of ASP.NET Web API to make HTTP service requests. The Web API sits on top of a couple of WCF services, which in-turn handle all the business logic. The client subscribes to a particular type of event with the Web API. Whenever the Web API receives notifications from the internal WCF services about the occurrence of the event, the Web API in-turn needs to notify (push events to) all the subscribed clients about the events along with their details.
I want to understand the different options which are available for
sending asynchronous callbacks from an ASP.NET Web API to the
clients.(Currently we are working on a prototype for which the
client is a C# Windows Forms application. Later we might opt for
ASP.NET MVC4 web application.).
I also want to know which option would be ideal to send asynchronous
notifications back to the client when the data that accompanies the notification is of large sizes. In our scenario, the notification data that is sent back from the service may be of large sizes (~ in the range of 5KB - 50 MB).
In our scenario which I described above, can SignalR be used for notifying the c# client from Web API, as and when the Web API receives the callback from the internal WCF services?
Note :- The Web API is currently hosted in a Windows Service and the client is a .NET Windows Forms application.
Any pointers to such code samples or directions on how this can be achieved would be extremely helpful.
Cheers
SignalR is a good fit for the scenario you're describing, so I'd suggest using it for the notifications (especially since you want to start with a WinForms application and later switch to browser clients - with SignalR, you'll be able to connect to the same server-side code).
However, I'd also suggest keeping the notication messages lightweight, so instead of sending the data to the client with them, I'd send a token the client can retrieve the data with from WebAPI (SignalR isn't really ideal for large file transfers).
I wanted to know if SignalR work in multiple web servers scenario. we have 4-5 web servers on amazon and want to use SignalR to push custom notification
Let me know, please
Yes it does,
but you need to enable a backplane for it to be able to scale out. Multiple backplanes exist, among others azure servicebus and redis.
Here's an example on how to setup azure servicebus as a backplane: http://www.asp.net/signalr/overview/performance-and-scaling/scaleout-with-windows-azure-service-bus