We're running an ASP.net MVC4.5 web app, and we have this api end point that does the following:
Send Email using SendGrid (normal sync code)
Send Notification using Azure Notification Services (normal sync code)
Trigger another endpoint in a 3rd party soap service (we're using azure storage queues here and a workrole, because the 3rd party endpoint is unpredictable and i might need to retry the call)
My question is, would it be an overkill to use azure storage queues for (1) and (2), I'm having second thoughts because, SendGrid for example, when sending an email using their SDK, I suspect that the email sending action happens instantaneously when im calling their email send endpoint, they are probably using some sort of queues as well and polling from it to send the messages.
This goes for the notification hubs for example, the message is added to their queues as well, so would it make sense to implement azure queues for those?
Related
Hi can I make push notification service with signalR?
for example when user start the app,app can recive message and if app closed again app can recive messgae from servers or clients
Until you can send the message to clients that user is online.
And with the closure of the app, Disconnect Communication server with the client. And the ability to send any message disappears.
If you want to send notification after app closed, It is better to use the google service. (e.g: Firebase Cloud Messaging (FCM) services),
Otherwise you can only use signalR for send message in your app.
I hope this is useful description.
If you want the ability to send messages or have messages available to any client then store them in a database table. When they are connected, you can send those messages to them. When they are disconnected they would stay in the database.
You can control flagging messages as read after they are delivered and then deleting them from the database.
Your "push notification" is just querying for the messages when a client is connected.
I need to azure service bus to notify an end point (Rest - POST) whenever a message comes to a particular topic.
In AWS, it is done this way
AWS llink
What is the equivalent in Azure.
Note: I dont want to write code that will receive the message and then call the end point.
Azure Service Bus is a messaging service, not a Notifications service. As such, it deals solely with messaging, and doesn't create notifications for you.
AWS combines SQS (Simple Queuing Service) with SNS (Simple Notification Service) behind the scenes to allow you the functionality you're describing. This is to allow SQS to have a behaviour of events. Azure Service Bus has a native support for Topics and Subscriptions (if that's what you're looking for). I.e. rather than just sending messages to a queue, the message is sent to a topic and appropriate subscriber(s) will get it.
So the short answer to this question in case you don't want to receive the message and trigger a notification is "no".
Saying that, if you're OK with "serverless" functions (similar to AWS Lambdas), you could use Azure Functions to achieve this goal.
Looks like finally azure released Azure Event Grid which kinds of does this out of the box.. very similar to AWS SQS + AWS SNS combo
https://learn.microsoft.com/en-us/azure/event-grid/overview
What is the difference between the newly release ASP.NET WebHooks and Signal-R? What are the advantages or disadvantages? What are the use cases for each technology?
SignalR is for notification within an ASP.NET app using WebSockets. You can exchange event notifications through WebSockets, however it requires a constant network connection.
WebHooks are for event notification across other web applications and other external services. (Think B2B communication). For instance, you can receive a WebHook when someone sends you money to your PayPal account. PayPal fires off a POST request to your predefined URL handler and then your app does something with that notification. You pre-configure everything on the PayPal side first. You also set up an application to handle the incoming POST request. The event notification is "pushed" to you in (near) real-time. No need to hold open a network connection while waiting for events.
The two can be complementary. For example, when you receive the WebHook from PayPal, you can notify a logged in user on your webapp (using SignalR/WebSockets) that money has been received successfully.
TLDR: Event notification across different web applications
It really depends on service you want to integrate with and how. WebHooks is a simple pattern for integrating event notifications across different SaaS services. If the service you want to integrate with supports WebHooks then you can use that. If it supports SignalR then you can use that. In that sense the two are quite complementary.
Check Henrik F Nielsen post at
http://blogs.msdn.com/b/webdev/archive/2015/09/04/introducing-microsoft-asp-net-webhooks-preview.aspx
I have an Azure web application (Asp.net MVC & WebAPI) that sends emails through SendGrid service. I'm not using SendGrid's API but rather use .net built-in SMTP that I configured in web.config and directed to SendGrid.
I'm now wondering whether I also need message queueing application in my solution that would be used to actually send emails to SendGrid to minimize request/response times of my web app?
Azure already has Queue Storage that I could use but I wonder how others have implemented this? I'm also looking for the most simple example of Azure web app using queueing if one exists.
I expect message queueing will become relevant when I'll have several emails to send during single request to make my app scalable. Currently I'm sending email synchronously when my backend executes code and so far with the low number of emails it works fine.
If your application need to manage and send bulk emails asynchronously, it would be better to have separate application which will take emails as bulk.
In my recent project, I have created separate application using web role, worker role and a service bus queue. Web role is a web API which used for application to post bulk emails and put it into a service bus queue. Then worker role will be responsible for dealing with the queues and send the emails. This allowed me to send emails asynchronously and storing any email messages or message status in a table storage.
Further, this approach helps me to use same notification application (email sending application) in different projects by using a wrapper to handle web api integration.
I've been using ASP.NET and PushSharp to send push notifications to my iOS app clients with the simple following code (after certificate configurations etc):
//ASP.NET + PushSharp
AppleNotification notification = new AppleNotification(PushToken).WithAlert(message);
broker.QueueNotification<AppleNotification>(notification);
This worked perfectly on isolated hosts running classic IIS/ASP.NET but now I'm moving towards Windows Azure. When I try this code on Windows Azure, notifications sometimes fail to send, and restarting the website (Standard mode) helps. However, since this is an unreliable approach I've decided to move to Azure's Notification Hub service. I've created the hub, uploaded my certificates, started coding but I couldn't find the equivalent of my previous code. I don't need to broadcast messages to all users, I need to send a push notification to a single device, given that I have the push token. I've looked at Windows Azure ServiceBus Push Notifications APNS Architecture but the link provided at the answer is extremely confusing and I couldn't understand it. How can I, simply push a message to a push token on Windows Azure? Do I have to use notification hub? (I don't use a VM) Any simple approach is welcome, pure ASP.NET/PushSharp-based approach is preferred as I don't need to change my whole codebase.
I'm not sure what kind of object a PushToken is. The way Notification Hubs work is, rather than providing a one-to-one messaging model (where you must identify each and every recipient of the message, whether that is by channel, device token, or registration ID), it provides a tag-based model. However, this does not mean that tags can't be unique to individual users, and in fact you can used just about any token as a tag.
This is a new model, unlike Azure Mobile Services or direct use of APNS, so it's not likely to be directly portable from your existing code. But, in my opinion, the Notification Hubs model is simple once you understand tags. It supports native payloads (constructed by the server that is sending the notifications) and template payloads (where the template is constructed by the receiving device and provided to Notification Hubs at registration time, and then parameters in the template are supplied by the server when it sends the notifications to the templates).