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
Related
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.
We are attempting to get Azure SignalR serverless to with a dotnet core API application. With "default" SignalR, we ran into scaling issues in Azure as server instances behind an API App would continue to receive socket connections even as its CPU increases. There is no way to currently to change load balancing behavior or to take an instance out of traffic. As such, we've looked to use "serverless", however, all documentation points to using Azure Functions. However, given that serverless uses webhooks and such, we should be able to use anything that can take an HTTP request. We already have our APIs setup so getting this to work against out APIs is preferred.
Update 1
Effectively, we're looking for support for serverless that Functions get but for APIs. Functions have triggers and Serverless Hubs to inherit from, etc etc. These things handle negotiate calls and deserialization of negotiation data and all the other things SigR has to do. We're looking for something similar for, I guess, API controllers.
Thanks!
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
We are looking to use Windows Azure to host our existing SaaS platform and extend our functionality and capability. WE will be taking adavantage of both the data storage and application and web service functionality of Azure.
My question is as follows:
Some of our clients will not want Public CLoud access. Since our datastore stores sensitive client data many of them will require our whole system to be hosted internally on their own network and servers.
If we setup a full Azure setup of database and connected applications and processes how difficult is it to be able to duplicate that system for a specific client on their own servers and network using existing Microsoft technologies?
I know its a vague question and I also have a liminted understanding of Azure so whatever information you can provide here would be most appreciated.
Thank you
It sounds like you need the flexibility of a hybrid cloud/on-prem solution. Likely the best solution is the Windows Azure Service Bus. Essentially, you configure a WCF web service in the cloud (SOAP, REST, etc) that performs asynchronous brokered messaging between your on-premise application and your web application. This can be performed using queue messages, for example:
The web application (cloud) requests resources from the brokering service (cloud) by sending a queue message
The service handles the queue message and makes it available to the consuming (on-prem) service
On-prem service checks for new messages from the brokering service, gets the request for data, and returns desired data from DB
On-prem service sends message to brokering service with desired data
Web app (cloud) checks for new messages from the brokering service, then uses the data from on-prem service
Service bus is secure, asynchronous, fault-tolerant, and ensures that both components are decoupled.
Another method is to use Windows Azure Connect, which is a VPN solution that sets up network-level connnectivity. I recommend Service Bus because it promotes a more robust and scalable architecture, and fault-tolerance is high.