In a previous solution, I recall setting up code-behind-type hub connections for unit testing. I believe I used code from the previous SignalR Hubs C# Client GitHub wiki.
In the SignalR Hubs API guide there is an example of using a console-based client:
stockTickerHubProxyProxy.On("Notify", () => Console.WriteLine("Notified!"));
In an upcoming application there will be notifications to be pushed to several clients. Some of these clients will be UI-based (JS), and others, will be some back-end code that will perform some task.
I am familiar with the JS-based client connectivity. My question centers around attaching code-behind-type clients, and how their methods "notified".
I understand that with a UI-based client, the mechanism is to push the update to the client through dynamic invocations to client-side "methods". Since it's been a few months since I've touched SignalR, what is the best way to accomplish this where there is no UI involved?
To verify that I am understanding the documentation correctly , when valid transport method is used, a C#-based (non UI/JS) client is notified (push) through the SignalR framework - no client polling required?
The essential mechanism is the same for JS and C# clients. The solution is exactly what you mentioned in your question. The 'On' method will subscribe the client to any "notify event" triggered by the server. You can refer to the documentation to get a better understanding:
http://www.asp.net/signalr
Related
I have an older C# app that is being migrated to the cloud. It uses SignalR, but only direct client/server connections. No SignalR service is involved yet.
I am extracting some processes that are well suited for an Azure function, but one feature I would prefer to not have to redesign for this MVP is a SignalR message back to the user that tells them the percent complete for this job.
I am reading the MS documentation from here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-signalr-service-output?tabs=in-process&pivots=programming-language-csharp focusing on Isolated-Processes.
I can see how I can send messages to the Azure SignalR service, but I am unclear how I might be able to just send a message back to the caller.
I would really like to set up a simple Hub and send messages directly to the client as the function progresses.
I would suggest giving web pub sub a look? Microsoft has a good comparison article here. Summary, it is a bit more language agnostic, and if you're already using azure then it has less setup overhead than SignalR.
https://dev.to/albertbennett/how-to-azure-pubsub-service-2ccb
I'm new to gRpc and now learning this tech
I'm wondering if gRpc can replace SignalR for updating notification bar on my client-side app (React).
Is that the case? or should I keep using SignalR for this matter?
(I'm asking it just to make sure I understand the purpose of the gRpc tech, by few articles I read it's more a web API replacement and few others compare it to SignalR)
Thanks!
y-me
Assuming you meant browser-based clients, then NO you cannot use gRPC. The gRPC protocol relies on HTTP/2 framing and in particular the ability to send and receive HTTP trailers. While browser themselves can and do use HTTP/2, current browser APIs (XHR/Fetch) don't expose HTTP/2 semantics.
There is however an alternative protocol, gRPC-web, that supports a subset of gRPC functionality you can utilize from a browser-based application. Given that it is a different protocol, your server will need to support it or you will need to employ a proxy like Envoy that can translate gRPC-web calls to gRPC.
I can't answer your question has if it is usable for Server/Client communications, just offer some thoughts. SignalR is made for the purpose of real time communications between Client and Server because of it's adaptability, and gRPC by it's constraints (HTTP/2 and HTTPS) is more reserved for backend micro-services communications.
I have an application written in Python (PIKA) and C# (official NuGet package). Those applications are publishing new messages into RabbitMQ queues.
Until now, I used this syntax to publish a new message into the queue:
model.BasicPublish(exchange, routingKey, basicProperties, body);
I found that BasicPublish function always returns with success. I also read in RabbitMQ documentation that in case of broker destroyed, the messages that didn't send yet will be removed without sending it to RabbitMQ.
I want to avoid the loss of messages. So, I found 3 options to submit those messages to publish:
Transaction - Very slow.
Confirmation - I found it tricky to implement in a multi-threaded environment.
with REST API - What do you think about that?
I think that it will be ideal for me yo use REST API for inserting messages into queues.
The Question:
The way that I found to send a message with API is to send POST message to this endpoint:
http://localhost:15672/api/exchanges/vhost/amq.default/publish
As you can see, this port (15672) belongs to the RabbitMQ management system.
Is this the right way to use RabbitMQ with REST API?
Can I trust the RabbitMQ management system in the production environment?
Can you recommend an alternative to REST API that will accept to message enqueue immediately after insertion (blocking)?
No, don't use the HTTP API. It is not intended for production use for publishing or consuming messages.
You must use publisher confirms. The technique described in this tutorial applies to the .NET client library as well.
You could also investigate libraries written on top of the official .NET library that may correctly implement publisher confirms for you. EasyNetQ is one such library.
Another good resource to read with concern to 100% reliability is this blog post.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I want to implement a feature like, if anything has been updated on Server-side like in database(the change can be from a client or another resource), then an event should be triggered and i come to know what change has been made. Then, through a rest api, i will send the response to UI with an event code, message and the new data from database.
And on UI, i have the approach to handle the events.
Please, tell me the approach or study material to implement this feature.
To use bi-directional communication between the clients and server you can use one of the following frameworks depending on your requirments:
SignalR
WebAPI and WebSockets
Socket IO (framework for Node.js)
Alchemy-Websockets
Fleck
SocketCluster (framework for Node.js)
I have a chat SignalR server, the chat support group chatting.
I also have a server which actually creates the groups and other group managment tools.
Whenever a user leaves a group (via http post ) to server, I want the chat service to trigger some methods, such as LeaveGroup and some other logictics.
I bound the connectionId to userId so I got the parsing request covered.
QUESTION IS: What is the best practice of communication between server/service and the signalr server.
Taking in mind, I dont want to compormise on scalability on each of my servers/services.
My idea is more or less host a web api server inside the SignalR server, but I can't seem to find any topics suggesting that could damage the performance.
Ideas?
Thanks alot.
p.s
I know that there is no code involved in here. but it seems irrelevant. I have self hosted web api in a window service I have, so the code is pretty much the same.
I would love to provide more data/information if thats neccesary
It seems like this documentation is most applicable to what you're trying to do: https://www.asp.net/signalr/overview/getting-started/tutorial-server-broadcast-with-signalr
It speaks specifically about how to communicate from your server/service application to the signalr clients. Communicating from the client to the server/service could be done either through the signalr hub, or with other web API.
From a best practice perspective, the documentation specifically states (https://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-server#callfromoutsidehub):
If you need to use the context multiple-times in a long-lived object,
get the reference once and save it rather than getting it again each
time. Getting the context once ensures that SignalR sends messages to
clients in the same sequence in which your Hub methods make client
method invocations. For a tutorial that shows how to use the SignalR
context for a Hub, see Server Broadcast with ASP.NET SignalR.
If you're really into scalability, you might want to look into integrating your signalr communications into some other message queueing system, but that's probably overkill for most circumstances.