I am far from an expert in this topic, so I would need your advice.
Whar are the possibilities of listening to a Azure Service Bus Queue in a Blazor Server web application? When I have looked through more or less all examples on this topic, the messages are usually sent by a web application but consumed by a console app.
What i have done so far is that i have implement the creation of the messages (sender functionality) into an existing rest api. That is straight forward i guess, and it seems to work just fine.
How to handle the web site is another topic, but i want a sign in and out functionality of the listener. We can see it as a go LIVE feature. To manage this, i implemented the processor logic instead on the receiver logic, so that i can sign in and out of the message event.
Can this work? Or shall i do something different instead?
It somehow works, but there are errors that interfere and i am not skilled enough to say if this is possible or not.
You can take a look at the SignalR chat app sample for guidance. You can replace the SignalR code with your ServiceBus client logic and there should be no issue.
The sample also contains buttons to start/stop the chat similar to your requirement for login/logout.
Related
i want to develop a Game using Azure Cloud but i am not sure which ressources i could use for it. Folowing is my problem:
There is one publisher which is providing some messages. I need to find a way to add subscriber on demand. That means whenever i need more subscriber i need to add them without changing any settings on the portal.
All subscriber needs to get the published message at the same time.
Received message from the publisher needs to be deleted for all subscriber at the same time.
Is there a ressource or a way which fits theese needs?
Thanks.
Azure SignalR Service is WebSocket Gateway service that covers all your requirements.
While you could always host your own server, the service supports scaling out.
I have multiple WebApi that are hosted in Azure but some of the API taking a long time to process.
Instead of a calling from the scheduler function in Azure, I was advised to use the Messaging Queue.
Is this a good approach?
Also, let say my API URL.. https://testwebapi.net/api1 and https://testwebapi.net/api2, how can we communicate these API using Message queue and also how to call the WebAPI individually from Messaging Queue?
Is this Azure Bus service is the same as Messaging Queue for Azure.
I would strongly recommend you look at the respective docs on Azure, and start doing some quick tutorials and post more specific questions.
Now, to answer, what I believe is your main question, Azure Bus Service and Messaging Queue.
The thing is, there is no one Messaging Queue, rather three options for Azure messaging - Service Bus, Event Grid, and Event Hubs. Also, there is something called 'Azure Queue Storage', but I dont think you are thinking of that, considering your context.
There is a very cool comparison chart available here - https://learn.microsoft.com/en-us/azure/event-grid/compare-messaging-services
But, I think, my guess, is you are looking for ultimately looking to use Azure Service Bus.
Also, please understand that one does not invalidate the other. As your project develops, you may end up using Azure Service Bus with other options like Event Hubs or Grids or all of them in different places.
Also, you keep using the incorrect terms. for example, you say 'Azure Bus service' but its really 'Azure Service Bus'. Also, there is no thing called 'Messaging Queue for Azure.' as there are so many different messaging services for Azure. This is what I want to add here. Spent some time with the docs and post more specific questions as you continue your project.
I'm trying to figure out how to connect my angular app to azure service bus. The reason I'm trying to do this is to setup real-time pub/sub solution for live auctions. I haven't really seen any start to finish documentation/tutorials on this with MEAN stack so I'm trying to piece it all together. In order to connect to my nodejs backend, what should I be using in Angular to make that connection? All the tutorials I see are referencing SignalR, but they are using .net. Is there a library that is equivalent for Nodejs or do I need to be using something like this?
I appreciate any help/direction!
It's not entirely clear if you are trying to connect your Angular front end to Service Bus as a replacement for SignalR. If so, it isn't a good idea as it would create a serious security hole. Service Bus is primarily for communication between servers. In this scenario, if you had multiple back end node servers, you could use Service Bus to sync the data they are pushing to your clients.
You are going in a better direction with SignalR. The technology you are looking for in real time server-browser communication is websockets. SignalR is just a .NET implementation of that standard. Once you start looking for websocket implementations on the MEAN stack, you should have a lot more success in finding guides. Here's a couple for generic JS implentations just as an example: Link 1 Link 2.
Edit for comment response:
You don't want to connect angular to Service Bus at all. Once you've exposed the keys publically, anyone can read/write whatever they want to your bus. Instead have Angular send the message to a HTTP function and have the function send the message to Service Bus.
The second problem with this plan is that websockets connections, the part that pushes data back to the client, is a long-running connection with constant communication back and forth. The consumption and premium plans are not built for this. Trying to use websockets on those plans will run up your costs a lot higher than they need to be if you have any significant traffic. You'll need to choose a plan that has a flat monthly cost instead. At that point you could still use Functions, but it may be easier to use a traditional web app.
In this case your system would look like this:
Angular new message -> HTTP Function/Web App -> Service Bus -> Websocket Function/Web app => Angular
If you are only running a single server, you can eliminate Service Bus completely.
The other option is to still use a HTTP function to receive new messages, but then use the SignalR service (not the .NET library) to handle pushing the data to the clients. This elimiates Service Bus as well.
This is what it would look like: Angular new message -> HTTP Function/Web App -> SignalR Service->Angular
I have a .NET web application that is deployed as a multi-instance Azure Web App. This web application makes use of SignalR to broadcast messages to connected clients. I'm scaling out using a Service Bus backplane, and this works great.
I also have a continuous WebJob that monitors a Service Bus queue, does some intensive processing, and as part of that processing needs to send out a broadcast message to SignalR clients.
It seems that there are two ways I can go with this:
Treat the WebJob as a SignalR client by connecting with my SignalR Hub running on the Web App using a HubConnection and an IHubProxy. This seems to work well, and is what I'm currently doing.
Somehow treat the WebJob as another Hub, and add it to the Service Bus backplane. I am not sure how I'd do this. I would then just broadcast messages using an IHubContext that I get from the SignalR.GlobalHost.ConnectionManager.
My questions are:
Is one way of doing this substantially better than another?
If option #2 is better, can someone post a link to how I'd go about doing this? It seems that most tutorials are in regards to a multi-instance scale-out using either SQL Server, Service Bus Topics, or Redis as the backplane.
I'm building a game for Windows Phone 8 and would like to use Windows Azure SQL Database for storing my users' data (mostly scores and rankings).
I have been reading Azure's documentation on SQL Database and found this link which describes just the scenario I'm looking for (it's Scenario B in the picture): I want my clients (the game running in a user's windows phone) to get data from an SQL Server through a middle application also hosted on Windows Azure.
By reading further the documentation (personally I think it's really messy and hard to find what you're looking for in there), I've learned that I could use Cloud Services for this middle application, however I'm not sure if I should use a background worker which provides an HTTP API or a worker with a Service Bus Relay (I discovered that I can use service bus in WP8 in this link).
I've got a few questions that I couldn't find an answer to:
1) What would be the "standard" way to go in this case?
2) If both ways are acceptable, are there other advantages to using a Service Bus other than an easier way to connect and send messages to my middle application? What are the disadvantages?
3) Is a cloud service really what I'm looking for (and not just a VM with the middle application code running in it)?
Its difficult to answer these sort of question as there are lots of considerations. I don't believe there is a necessarily 'standard way'.
The Service Bus' relay service's purpose is to help traverse firewalls and NATs, not something that directly relates to your scenario, I suspect.
The Service Bus, though, also includes a messaging capability which provides queues, topics and subscriptions to use to exchange messages between clients or client/server.
You could use the phone client to write and read messages to/from queues. you would then have a worker role hosting your application logic and accessing the database as needed.
Some of the advantages of using messaging include being load leveller, helping handling peaks in traffic (at the expense of latency), helping separating concerns and allowing you to accept requests from the clients when the backend is down as so can help with resiliency.
In theory they can also help you deliver messages to the client in the same fashion, by using a queue or subscription per client, but for a large number of clients this may become a management issue.
On the downside you would have to work with what is a proprietary protocol, and will need to understand the characteristics and limitations of the service bus. you will need to manage the queues and topics over time. there will also be some increased latency, although typically not an issue and, finally, you will have to implement asynchronous messaging on the client side which has advantages but is also harder to implement.
I would imagine that many architectures follow the WEB API route by using a web role cloud service exposing the API. The web role can then perform any business logic and connect to the database in the background.
A third option, which you didn't mention, is to use Windows Azure Mobile Services and implement your business logic as a service API there