how to refresh local data automatically when server data changes in azure mobile app(android).Right now i m using a timer that refresh my server request but this approach is not satisfactory as my app keep on sending requests to azure.What is the best approach for doing this?I also tried to understand one of the answer in stack overflow based on Exponential Back Off Delay Based but failed to understand.Kindly just guide me on this
For communicating server-side updates to client apps, use SignalR.
Here's some guidance on using it with Azure Mobile Apps: Real-time with ASP.NET SignalR and Azure Mobile .NET Backend
We just released an update for Azure Mobile Services .NET backend which enables you to use ASP.NET SignalR for real-time, bi-directional communications with your mobile applications. SignalR will use WebSockets under the covers when it's available, and fallback to other “techniques” (i.e. HTTP hacks 😉) when it isn't. Regardless of the mode, your application code stays the same.
Related
I am trying to integrate our socket.io application with azure api management. But I am unable to find any solution, whether it is possible or not. Can any one help me OR give me some suggestions
UPDATE: WebSockets are now supported in APIM. Currently, only passthrough is supported which creates a one-to-one mapping of the connection between the client and APIM, and the connection between APIM and the backend websocket server. Also, do note the limitations that exist today.
Thanks #restfulhead for the bringing this up here
Unfortunately, WebSockets are not supported in Azure API Management as of today. There is a feature request on UserVoice which you could up vote to gain more traction.
Today, for WebSocket applications, you can use Azure Application Gateway which supports websockets.
On another note, Azure SignalR is also a great service for building managed, scalable, realtime websocket-powered applications but is more of an alternative to socket.io in NodeJS for C#.
Let's say, I have an enterprise application runs on Azure Web App Service. Among 100+ pages, I have 3-5 pages needs to be served real-time. to benefit from real-time capabilities of Azure SignalR Service, I want to make clients land on my SignalR application (which runs on RignalR Service). But I couldn't find any related example-article about it. How can I invoke a Hub method outside of the code? Any other approach to solve my problem is more than welcome. My main concern here is the performance of real-time pages.
If you have an ASP.NET Core SignalR Server (i.e. you have classes deriving from Hub in your application), you can't directly send messages to clients via the Azure SignalR Service. You'd have to provide an API in your ASP.NET Core application that does that.
Azure SignalR does also support a "serverless" mode in which you don't have a Hub on the server at all. In that model, clients connect directly to the service (instead of first connecting to your app) and then you can send messages to those clients using the REST API. This is a relatively new scenario so there isn't a lot of documentation. There are some blog posts and videos online on the subject, but not a lot of documentation.
If you already have an ASP.NET Core app, I'd suggest doing this by adding a REST API to your own application that allows other services in your application to send messages by calling this API. In the implementation of this API, you can use IHubContext<T> to send the messages.
I'm reading the very limited information about Azure SignalR service as well as the quick start guide and want to make sure I'm understanding this correctly.
We still seem to have a hub and if I understand this correctly, the function of Azure SignalR service is to simply push the messages to connected clients.
In my case, I store the history of chat so by hitting the hub first, I'm able to still use my backend logic to persist chat history or do any other processing that I may want. Then simply allow Azure SignalR service to push the data to connected clients.
The main benefit seems to be handling the scaling of the service.
Am I getting this right?
Yes, you are totally right.
You will use exactly the same API of ASP.NET Core SignalR to write your business logics, which means you can persist whatever you want when the messages from clients hit your hubs.
Azure SignalR Service will be the underlying transport between your app server and connected clients. For example, when you want to broadcast messages to all your clients, you actually only send one message to Azure SignalR Service and the service will broadcast the message to all clients for you. So that you don't have to worry about the scale-out. Azure SignalR Service will handle the scaling-out for you.
You understand correctly.
SignalR is not yet ready for production (when speaking about ASP.NET Core), SignalR for ASP.NET MVC has been around for a while (stable).
SignalR consists of 2 pieces: server and client. The server is as you describe: a "hub" that you can use to push information to clients.
On a webpage you load a piece of generated javascript (generated automatically from your hub definitions). Basically you let your website visitors (clients) connect to the hub through signalR's mechanism (signalR will choose the proper way to connect depending on the browser), and then 'subscribe' to the different methods you have active in your hub.
The workings are simple: whenever you call code in your hub (can be from clients, or from backend code) communication is automatically handled for you to all subscribed clients.
Note: If you are running this on an azure web app: enable the "always on" setting, and set the "websockets" toggle to "enabled", otherwise you'll see strange behaviour.
Note2: The RC version for signalR core 1.0 has just been released (7th of may 2018) so it might be a while before this software starts becoming stable and available through the public nuget/npm channels.
I am in the process of building a Web based client for a Server application which is running as a Windows Service. The server application currently has a Windows Form based Client Application written in C# and the idea is to obsolete it and provide a new Web based Client Application. The Server application will be exposing REST based APIs and the Client Application would be using the REST APIs to communicate with the Server Application. (Currently the Server App exposes SOAP based endpoints which are consumed by the Windows Form Based App)
The Browser based client application would be written using Angular JS. The Client Application would be used by at max 10 concurrent users. The App is targeted for system administrators and would be used inside the enterprise environment.
Another requirement is to integrate Active Directory Authentication for the Client Application. So given the performance requirement and authentication requirements, I am wondering whether I should use IIS for hosting the Web Application. Or should I just use the existing Server to self host the web pages.
If at all I go with Self Hosting option, would Katana Self host be a good option? Or should i use WCF Rest kit to serve the pages?
What are the performance implications of using a Self Hosted mechanism for hosing the Web Application compared to IIS?
Any suggestion would be greatly appreciated.
WCF REST Starter kit is still in second preview 2 version from 2009 so I'd be pushed to recommend using it.
The question of IIS or self host depends, do you need the features that IIS has out of the box like logging, restart after failure, etc?
My suggestion would be to use ASP.NET Web API (or Nancy, which is an excellent choice too) but keep your hosting layer separate from your application layer so you have the flexibility to decide how you host your service later on.
The second suggestion is performance test early on, pick a hosting mechanism and measure how the service copes under load - you may find out that you're worrying about something that you don't need to.
I have a Windows Azure Mobile Service up and running, however, there is a need for that service to consume some data expose through an external SOAP service and store that information in the mobile service database.
I would like to set up a worker in the mobile service, so the calls to the external SOAP service are executed in a fixed period of time.
I've been looking for a solution to this problem, but haven't found anything yet. So any help that would get me in the right direction would be appreciated.
Unfortunately there isn't an easy way to talk to a SOAP service from your Mobile Service backend. The backend is based on Node.js, and even though there are some Node modules for talking to SOAP services, they are currently not supported in Mobile Services. We are working on a solution that will enable you to use any Node module in your service, but it is not out yet.
If you control the SOAP service and it is written using WCF, you may be able to easily add a REST endpoint to the service with just a few config changes and then consume it from your Mobile Service via plain HTTP requests by using the "request" module.