I have a WIP chat tool with SignalR hub running on my server and would like to add translation feature to it.
So far I set up Azure Translator Text API, Service Bus and Functions. And I've made the SignalR server casts messages to the service bus, then the function triggers upon existing messages on the bus, and posts it to the translator api.
Flow of Messages
[Users' Browser] -> [SignalR Hub] -> [Service Bus] -> [Functions] -> [Translator API]
Here my concerns are:
What is the advantage of using service bus or functions? It is also possible to directly post messages to translator API from my server, but I assume service bus make it easier when I want to scale out my server, is that correct?
Related to 1., I know there's Service Bus Relay that enables two systems directly communicate to each other. Is this useful for this kind of project?
Where should the messages translated through functions be posted back to? The SignalR hub on my server, or the service bus with some tag that distinguishes whether the message is raw or translated?
Related
I have mainly worked in AWS and there is AWS SNS which can send SMS and email notifications. The alternative in Azure appears to be Azure Notification Hub, which cannot do this. Apparently it only sends push notifications.
Is there a service that I could use to implement SMS and Email notifications (including email templates) in Azure?
Azure Communication Services are cloud-based services with REST APIs and client library SDKs available to help you integrate communication into your applications. You can add communication to your applications without being an expert in underlying technologies such as media encoding or telephony.
From: What is Azure Communication Services?
Azure Communication Services provides quite a few options, among which are chat, email and SMS.
There are decent articles on how you can Send an SMS message or Send an email.
EDIT:
Azure Logic Apps is a cloud platform where you can create and run automated workflows with little to no code. By using the visual designer and selecting from prebuilt operations, you can quickly build a workflow that integrates and manages your apps, data, services, and systems.
So Logic Apps is not a service to send SMS or email. Logic Apps is a low-code platform that enables you to very easily call a service that sends an SMS or an email. And one such service could be Twilio, since ...
Twilio powers personalized interactions and trusted global communications to connect you with customers.
Of course there are other providers, too, like MessageBird, Spryng, CM.com and more.
for sms/emails try Azure Communication Services: https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/sms/send?tabs=windows&pivots=platform-azcli
For email notifications only you have also different choices. You can buy "kiosk" from 365 business licence, so you can create account only for this licence in your tenant, send email from code is standard smtp approach. For templating you can use whatever you want, as you can send html message loaded for example from resx file. You can also use service nammed SendGrid from Twilio. I recomend using SendGrid, only if there are really plenty of emails.
It seems to me that Azure Web PubSub is a combination of both Event Grid and Event Hub using web sockets, instead of HTTP. However, I'm not 100% sure and could not find any articles that have a direct comparison between the 3 services.
To answer your question let me explain all the three services one after another.
Azure Event Grid
Azure Event Grid is a complete event routing service actively running on top of Azure Service Fabric. It issues events from various services like Azure Storage Blobs to different handlers like Azure Functions. It is event driven publish-subscribe model ( reactive programming).
Azure Event Grid can connect to any application that you create, and the Events generated by the application can be pulled and published to different other destinations.
Azure Event Hub
Azure Event Hub is a data ingestion service that streams a huge count of messages from any source to provide an immediate response to business challenges. It streams millions of events per second from any source to build dynamic data pipelines and immediately respond to business challenges. Think it as multiple source big data streaming pipeline (telemetry data).
The difference between them is that Event Hubs are accepting only endpoints for the ingestion of data and they don’t provide a mechanism for sending data back to publishers. On the other hand, Event Grid sends HTTP requests to notify events that happen in publishers.
Azure Web PubSub
PubSub is the short form for Publish Subscribe. If you have ever used Azure SignalR or WebSockets before to send things between publisher and subscriber, then that is what Web PubSub also does. So Azure Web PubSub is a managed service for handling real-time communication with your application.
When you are using WebSockets, you have these long running connections between clients and app server but it gets tricky to scale them as you are handling long-running requests. This problem is solved by Web PubSub service, which comes in the middle of your clients and app server. Now your clients can talk to this server and you can do http in between Azure Web PubSub service and the App Server. So your app server remains http only, but all the hard WebSocket logic is handled by the service for you.
The Azure Web PubSub service is build on the same core fundamental platform as SignalR but the main difference between these two is Azure Web PubSub is purely serverless and in SingnalR you need to use SignalR client but with Web PubSub you can use any client and any language.
Lastly, I would suggest you to read these Choose between Azure messaging services and Azure Web PubSub documentation for more information.
I have the following message transport scenarios
Client -> Calls SignalR -> Calls NServiceBus -> Process Message internally -> Calls NServiceBus Gateway service with Result -> Calls SignalR Hub -> Updates the client with result.
In choosing whether to use SignalR vs. long polling, I need to know if SignalR is scaleable. So in doing my homework I came across SignalR on Azure Service Bus. The setup is done on the Global.asax application start.
Ultimately I need to be able to do this, from inside an NServiceBus handler:
var context = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
context.Clients.Group(group).addMessage(message);
The question is if context will be jacked up, because I'm (potentially) calling it from another machine than the one the client was connected to?
Also what is the sharding schema that the SignalR implementation uses to seed the topics? I know I can configure it to use N-number of topics, but how is it actually determining which message goes to which topics and if it's relevant from an external caller PoV.
You should be able to use GlobalHost.ConnectionManager.GetHubContext in any application where you have registered ServiceBusMessageBus as your IMessageBus via SignalR's GlobalHost.DepenencyResolver. This is done for you if you call GlobalHost.DepenencyResolver.UseServiceBus(...) in the application.
If you do this, a message will be published to Azure Service Bus for each call to addMessage or any other hub method on the IHubContext returned from GetHubContext. If there are subscribed clients connected to other nodes in the web farm, the other nodes will pick up the message from Service Bus and relay it to the subscribed clients.
Which topic a message goes to should not be relevant from the PoV of an external caller. You can use multiple topics to improve throughput, but for most use cases one should be sufficient.
If you choose to use more than one topic, you can think about the topic a message goes to as being essentially random. The only thing that is guaranteed is that messages from the same sender will go to the same topic. This allows SignalR to keep messages from the same sender in order.
Caveat emptor: SignalR has not yet had an official release supporting scale out. The 1.1 version will be the first release to support scale out officially.
How do I fetch individual messages to multiple clients, from the Azure Service Bus relay, without having to have a namespace for each client?
Background:
I have a web service, which has multiple users, which are businesses. Not a huge number, but a few hundred. The users are mostly on NATs and behind firewalls, so I created a Windows Service to be installed on the users local machine, and that service listens to a Azure Service Bus Relay Service.
How can I deliver individual messages to these users/clients via the service bus relay? Do I have to create a new namespace on the service bus for each user? Or is there something smarter than that I can do?
Thanks!
This was answered well over at the Windows Azure forum on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/windowsazureconnectivity/thread/235c1515-d507-4b78-9d84-9e04a49e038b
I read that Signalr on Azure requires a service bus implementation (e.g. https://github.com/SignalR/SignalR/wiki/Azure-service-bus) for scalability purpose.
However, my server only makes callbacks to a single client (the caller):
// Invoke a method on the calling client
Caller.addMessage(data);
If don't need Signalr's broadcasting functionality, is an underlaying service bus still necessary?
The Service Bus dependency is not something specific to Azure. Any time you have multiple servers in play, some of your signalR clients will have created their connection to a specific server. If you want to keep multiple servers in sync something needs to handle the server to server real time communication. The pub-sub model of service bus lines up with this requirement quite well.
dfowleR lists a specific case of this in the comments. Make sure you read down that far!
If you are running on a single server (without the sla on Azure) signalR will work just fine on a Cloud Service Web Role as well as the new Azure Web Sites. I did a screencast on this simple scenario that does not take on a service bus dependency, but only runs on a single server.
In order to support the load balance scenario, is it possible to enstablish a "server to server" SignalR PersistConnection between multiple instances (ie on Azure) ?
If so, we can use a SQL Azure Table where all instances register at startup, so newest can connect to previous ones.