I am new to Azure so forgive me if my question sounds unclear but I will try to explain the best I can.
I think it is common nowadays to need some kind of push notifications rather than pulling data in a timed interval.
So, if I have a mobile app, a web app, and a desktop app all talking to Azure, if one of these apps updates something in Azure SQL database, I would like to avoid to have to pull for this change in my other apps but instead get pushed these changes automatically to them.
I think there should be some kind of mechanism in Azure notifying the applications (whether web, mobile, desktop) about these changes.
Is there something like that? What should I look into?
UPDATE 1
Assume I have an web (Angular or whatever) Azure app talking to Azure SQL database storing cars information. This app allows me to do CRUD operations so I can add, update, delete, read cars from database.
Database currently has info about BMW and Toyota only
User logs into my web app and sees info about BMW and Toyota which is info
existing in my Azure SQL database.
User logs into my mobile app which connects to azure and pulls info from database and shows BMW and Toyota on screen
User logged in web app adds new info about Honda (or deletes an existing car, or updates an existing car), info is stored in
database and Honda shows in web app
User logged into mobile app would now have to tap on refresh button to pull the latest data from database.
How can this data be automatically and immediately pushed to mobile app instead of having mobile app pull it in some interval or on tap on a Refresh button?
Absolutely! Azure has several messaging solutions to solve this type of problem. But without fully understanding your problem space, the semantics of your data or your overall architecture, it's hard to give precise and tailored guidance. Given that you've mentioned that some of your clients will be mobile devices, you should opt for something lightweight such as Azure Notification Hubs. You should also review the Service Bus and Event Hubs here.
With whatever service you choose, I wouldn't recommend sending the actual data itself in these push notifications. Keep notifications extremely lightweight. A client, upon receiving the notification, can react by polling your backend for the actual data change.
Related
I have a web application in Azure. There are 2 instances, with Azure Front Door being used to route all traffic to the primary instance only, with the secondary one only ever used if the first is unavailable. We have some in memory data that gets updated by users. The database is subsequently updated with the changes. The data is kept in memory as a function of a genuine performance requirement. The issue we have is the data is fetched from the database only on application start up, meaning that if the primary instance becomes unavailable the secondary one could very well have information that is out of date. I was hoping that Front Door could be configured to trigger an API when any sort of switch - from primary to secondary or vice versa - occurs. However I can't find any reference to this in the documentation.
We have a series on web jobs that run, one of which is triggered every minute. However using this to keep the data fresh still doesn't guarantee that an instance will necessarily have the latest information.
Any thoughts on how to rectify this issue very much appreciated.
[EDIT]. Both web apps talk to the same database instance
Unfortunately Azure Front Door doesn't have any native support for firing events to something like an Event Hub but you could stream your logs to one. For example you could stream "FrontDoorAccessLog" to an Event Hub and have a script receive these events. When the "OriginName" value changes you could inform the failover app to update its state via an API.
Is there a reason why both Webapps have their own database if they have to be somewhat synchronized? Why not have both Webapps talking to the same DB?
Following is the proposed transition in our application:
Web Application is deployed in on-premises IIS (Web Server 1).
Web Application has one functionality (for example, Generate Invoice for selected customer).
For each new request of Generate Invoice, the web application is writing message to the Azure Service Bus Queue.
Azure function gets triggered for each new message in Azure Service Bus Queue.
Azure function triggers Web API (deployed on-premises).
Web API generates Invoice for the customer and stores in the local file storage.
As of now, we have everything setup on-premises, and instead of Service Bus and Azure function, we directly consume Web API. With this type of infrastructure in place, we are currently logging all events in an MongoDB collection, and providing single consolidated view to the user. So they can identify what happened to the Generate Invoice request, and at which level and with which error it got failed (in case of failures).
With the new proposed architecture, we are in process of identifying ways for logging and tracing here, and display consolidated view to the users.
The only option, I can think of is to log all events in Azure Cosmos DB from everywhere (i.e., Website, Service bus, function, Web API), and then provide consolidated view.
Can anyone suggest if the suggested approach looks OK? Or if anyone has some better solution?
Application Insights monitors the availability, performance, and usage of your web applications whether they're hosted in the cloud or on-premises. It leverages the powerful data analysis platform in Azure Monitor to provide you with deep insights into your application's operations and diagnose errors without waiting for a user to report them.
Workbooks combine data visualizations, Analytics queries, and text into interactive documents. You can use workbooks to group together common usage information, consolidate information from a particular incident, or report back to your team on your application's usage.
For more details, you could refer to this article.
Below is one of the features of Azure Mobile Apps - Office Data Sync
When your app is in offline mode, users can still create and modify data, which will be saved to a local store. When the app is back online, it can synchronize local changes with your Azure Mobile App backend.
As per the above, does that mean the synchronization of the local changes happens only when the app is online (user needs to explicitly open the app)? Or the data gets synchronized to server automatically when the mobile connects to internet via some background service?
For an overview of offline data sync, see Offline Data Sync in Azure Mobile Apps, particularly How offline synchronization works.
The SDK does not do anything automatically with regard to the sync operation itself. You have to either add code that syncs on a timer, or detects network connectivity changes. If you want to sync as a background task, you will have to register the sync code with the OS and call PullAsync and PushAsync in that code.
Basically, the SDK tracks changes for you and sends them when you call PushAsync, but your code manages when this happens.
As the document says:
Changes are stored in a local database; once the device is back online, these changes are synced with the remote backend.
Which means user should open the app first before syncing data.
I am planning to use Azure Mobile Services for the mobile app I am planning to develop. Its a bit of social kind of app. (I am expecting a lot of data - relations and storage(pics etc. ). For the app, I wish to use Azure Mobile Services for easily adding oAuth authentication for my app, Mobile services also provide other useful features like granular control to data access, push notifications etc.
I plan to use Azure SQL for hierarchical data and Azure Storage for images etc. So for my data service API, writing custom API in Mobile service seem to be the natural way.
But I am bit apprehensive about developing my data service API in Mobile Services; when I think what if my data grows huge, somehow I have doubts will Mobile services API be able to handle huge data, thick and fast flying data requests.
(The size of data I am looking at is - on an average each user may add 'one' post of lets say 1000 words and 3 picture files on an average, not sure how many users, but users will be worldwide)
Does someone has any experience with performance/scalability- elasticity of Custom WepAPI? If you can kindly share your experiences/knowledge in this regard, I'll really appreciate
Azure Mobile Services does provide scaling... This means getting into the paid services, for example: http://www.windowsazure.com/en-us/pricing/details/mobile-services/
You can also scale out the SQL database used in your mobile services. For some detail: http://msdn.microsoft.com/en-us/library/windowsazure/jj193178.aspx
If you think even that might be an issue, I'd recommend wrapping the use of the services so you can swap them out easily.
We have our own application that stores contacts in an SQL database. What all is involved in getting up and running in the cloud so that each user of the application can have his own, private list of contacts, which will be synced with both his computer and his phone?
I am trying to get a feeling for what Azure might cost in this regard, but I am finding more abstract talk than I am concrete scenarios.
Let's say there are 1,000 users, and each user has 1,000 contacts that he keeps in his contacts book. No user can see the contacts set up by any other user. Syncing should occur any time the user changes his contact information.
Thanks.
While the Windows Azure Cloud Platform is not intended to compete directly with consumer-oriented services such as Dropbox, it is certainly intended as a platform for building applications that do that. So your particular use case is a good one for Windows Azure: creating a service for keeping contacts in sync, scalable across many users, scalable in the amount of data it holds, and so forth.
Making your solution is multi-tenant friendly (per comment from #BrentDaCodeMonkey) is key to cost-efficiency. Your data needs are for 1K users x 1K contacts/user = 1M contacts. If each contact is approx 1KB then we are talking about approx 1GB of storage.
Checking out the pricing calculator, the at-rest storage cost is $9.99/month for a Windows Azure SQL Database instance for 1GB (then $13.99 if you go up to 2GB, etc. - refer to calculator for add'l projections and current pricing).
Then you have data transmission (Bandwidth) charges. Though since the pricing calculator says "The first 5 GB of outbound data transfers per billing month are also free" you probably won't have any costs with current users, assuming moderate smarts in the sync.
This does not include the costs of your application. What is your application, how does it run, etc? Assuming there is a client-side component, (typically) this component cannot be trusted to have the database connection. This would therefore require a server-side component running that could serve as a gatekeeper for the database. (You also, usually, don't expose the database to all IP addresses - another motivation for channeling data through a server-side component.) This component will also cost money to operate. The costs are also in the pricing calculator - but if you chose to use a Windows Azure Web Site that could be free. An excellent approach might be the nifty ASP.NET Web API stack that has recently been released. Using the Web API, you can implement a nice REST API that your client application can access securely. Windows Azure Web Sites can host Web API endpoints. Check out the "reserved instance" capability too.
I would start out with Windows Azure Web Sites, but as my service grew in complexity/sophistication, check out the Windows Azure Cloud Service (as a more advance approach to building server-side components).