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
Related
I want to create the Xamarin Form app for both android and iOS in which when something events occurs or data update on server than server call my xamarin app and i will perform some task in my app. Push notification and SignalR both are not suitable for my case. is there anything like webhook in Xamarin form. There are many example for Web application but nothing i found in case of mobile application.
You can use the RESTful web service as a webhook.
Representational State Transfer (REST) is an architectural style for building web services. REST requests are made over HTTP using the same HTTP verbs that web browsers use to retrieve web pages and to send data to servers.
More informations you can refer to this website:
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/data-cloud/web-services/rest
I am developing a mobile app using react native. My backend application is developed using springboot. My app talks to backend using REST.
I want to send some notification to the user of the app from my backend (via one of the options mentioned below). This cannot be a Push Notification as user can disable push notification for my app.
On recieveing this notification the app will communicate with backend using rest api's to fetch more details and complete the transaction.
I want to know what would be a better strategy to send a notification for the user.
Websockets
Using Firestore event listener(since I am already using Firebase to send Push Notitification for users who have enabled it)
SSE(server sent events)
Periodic polling from the app to backend (I do not like this approach)
I know this is a bit broad topic. I just need some pointers as to which option is better in terms of fault tolerance, performance and scalability.
I want to know how this is generally implemented. I am new to app development.
In my opinion Firebase is the best option for mobile apps, websocket can be be closed by android and are not always controllable. They also consume a lot of energy which can drain phone battery.
I have the same requirements for a project where need to send notification regardless of using a third party application like Firebase. How I achieve this I will share with you may be it will help you.
Backend -> ASP.NET Core
Real time communication -> SignalR Core
Protocols -> Websocket, Server sent events, Long Pooling
RN Package -> react-native-push-notification
It was completely fine except for one drawback that it will only communicate and send push notification when app is running (background/foreground) I think it depend on your situation and your requirement if your app is continuously will in the main app this will work for you otherwise you need to use the third-party service like Firebase and it will also work when your app is not running just need to be connected with the internet.
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).
I have the following scenario in my project :-
The client makes use of ASP.NET Web API to make HTTP service requests. The Web API sits on top of a couple of WCF services, which in-turn handle all the business logic. The client subscribes to a particular type of event with the Web API. Whenever the Web API receives notifications from the internal WCF services about the occurrence of the event, the Web API in-turn needs to notify (push events to) all the subscribed clients about the events along with their details.
I want to understand the different options which are available for
sending asynchronous callbacks from an ASP.NET Web API to the
clients.(Currently we are working on a prototype for which the
client is a C# Windows Forms application. Later we might opt for
ASP.NET MVC4 web application.).
I also want to know which option would be ideal to send asynchronous
notifications back to the client when the data that accompanies the notification is of large sizes. In our scenario, the notification data that is sent back from the service may be of large sizes (~ in the range of 5KB - 50 MB).
In our scenario which I described above, can SignalR be used for notifying the c# client from Web API, as and when the Web API receives the callback from the internal WCF services?
Note :- The Web API is currently hosted in a Windows Service and the client is a .NET Windows Forms application.
Any pointers to such code samples or directions on how this can be achieved would be extremely helpful.
Cheers
SignalR is a good fit for the scenario you're describing, so I'd suggest using it for the notifications (especially since you want to start with a WinForms application and later switch to browser clients - with SignalR, you'll be able to connect to the same server-side code).
However, I'd also suggest keeping the notication messages lightweight, so instead of sending the data to the client with them, I'd send a token the client can retrieve the data with from WebAPI (SignalR isn't really ideal for large file transfers).