We got caught by Microsoft's abandonment of Silverlight and focus on UWP. This has ended up with us having to develop two dually focused apps (UWP and Silverlight), which has left us with two apps that cannot be bundled/packed together. We have therefore decided to have of the apps as a companion app.
Both apps use authentication, at present time it is with Microsoft authentication. The services used for authentication is of the type Azure App Service - Mobile. The services besides authentication also provides interfaces to a notification hub, blob storage and SQL storage.
The question is therefore is it possible to have one App Service - Mobile (not mobileservice), and authenticate two different apps using the same service?
Additionally can the same Notification Hub be used to send notifications towards different apps?
Or is it needed that we create two different services for each application to facilitate the use of authentication and push messages. Then we can link the same database to the two App Service - Mobile ? But this would leave the issue of the notification hubs not having the same registrations ?
I dont think you can have more than one apps connected to one Azure mobile app. You can connect same app on different platforms but not multiple applications for same platform as Mobile app is designed to be an individual app back end.
Check this feedback request.
https://feedback.azure.com/forums/218849-notification-hubs/suggestions/3821272-push-notifications-for-multiple-apps
As answered by product group, the idea behind Mobile App is to be the individual backend. For that, Mobile Apps dashboard should have not one field for the PackageId/..., but two or more to be the backend for a different apps. Every connection between app and external service like a authentication provider or push notification platform is "personalized" - by IDs and password or certificates, or many ways.
I can imagine the scenario when someone would need to connect one backend to different apps, but the Azure Mobile App idea is different. And, as App Service is a service, i think that in the current situation what you want to do is impossible.
an Azure Mobile App consists of the client app and a backend in Azure. There's no stopping you reusing the same backend for more than one app.
Related
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.
Can I use one azure mobile app as a backend to support for mobile app and website?
I need it to support push notification and authentication as well as CRUD operation. Should I use API app or Mobile app or something else?
An Azure Mobile App is just a regular ExpressJS app with the Azure Mobile Apps SDK implemented. Here is a good example of a combined web + mobile:
https://github.com/adrianhall/azure-mobile-apps-html-quickstart
The 'public' directory contains the static website, complete with JS and CSS files. The app.js is your app (note the serve-static module usage to serve up the static content).
Now that Mobile App, Web App, and API App are under one roof so to speak you have several options.
They are all part of App Services.
The easiest way to think about App Services is in terms of a VM that hosts multiple web apps in isolation.
You create an App Service that is like a VM and then you create multiple apps that run in that VM.
You could create a Mobile App and a completely separate Web App that share a common database for instance.
You pay for the App Service instance, not each app, so it's really up to you how you want to divide up the functionality.
Now before someone cries foul on my VM analogy, I said it was the easiest way to visualize it, not the most accurate.
What you really get is a "Virtual Virtual-Machine" that could be one or many VMs. You see it as one logical thing in terms of management, deployment, etc. but it could really be multiple VMs. It can scale up or down based on your configured options (eg 1 VM always, scale up to 5 VMs if CPU or Memory exceed thresholds you set, etc.).
I have created an Azure Web App today and it has a Mobile section in the Settings which contains Push notification, Mobile Authentication, etc. You can even download the source code for a mobile client app. I know that this used to be part of Mobile App (Mobile Service). I have created an Azure Mobile App to compare with Web App and they look the same in terms of Settings and Tools. Even the Icon is the same.
My question is what is what is the difference between Azure Web App and Azure Mobile App?
Like you, I couldn't get my head around the difference between the different types of App Service apps (Web Apps / Mobile Apps / API Apps). Judging by the fact that no one has really answered your question, it looks like we weren't the only ones.
It made no sense to me that Web Apps, Mobile Apps and API apps were distinct things: surely the whole point is that you should be able to expose an API that serves your web site, your mobile apps, any other kind of client, making use of whichever features you need for your use case?
And, lo and behold, buried deep in the Azure docs:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
Yep: they're exactly the same.
In old days of Azure, they had 2 offerings - Azure Websites and Azure Mobile services. Some time ago, both of them got rolled into something called Azure App Service which also included two more kinds of apps - API Apps and Logic Apps.
To answer your question specifically, Azure Web App is new name for Azure Websites that you can use to build websites in multiple languages where as Azure Mobile App is the new name for Azure Mobile Service that provides backend infrastructure for mobile applications (or in other words, Azure Mobile App is Mobile Backend-as-a-Service [MBaaS] offering from Azure).
Mobile Service is the "classic" version and is only available in the classic portal. Mobile Apps is part of App Service is only available in the preview portal.
App Service includes Web Apps, Mobile Apps, API Apps and Logic Apps is deployed as one unit. Using the classic way, you would have to create and pay let's say for a Web App and a Mobile Service so you can save money using the App Service. You also get a larger selection of VMs.
Not all Mobile Services features have been migrated yet to Mobile Apps. If you use a Node.js backend, there's no nice UI built-in in the new portal to manage your JS code.
Note that Microsoft has not announced that it will deprecate Mobile Services.
I have found some subtle, but key, differences. Assuming a C# backend, the Mobile App Service controllers will inherit from TableController - which provides out-of-the-box CRUD operations on a table, compared to the Web Api 2 style ApiController (which you can still use in a Mobile App Service). Any less confused now?
Sorry for the late reply. They all are really the same thing. If you look in Azure Resource Explorer (available in the application menu of your app or resources.azure.com) you will see the indication of how we display a different icon for it - "kind": "mobileapp", for Mobile Apps for example. We leverage the different kinds to provide different quick-starts. You can certainly create an Azure Web App and load Azure Web App code to it to get the Mobile Functionality.
I am in the process of building a basic windows phone 8 game with an Azure back-end. I am looking into solutions to implement some form of matchmaking for my game through Azure. I would like to run some form of "game master" in the cloud rather than in the app so if two individuals connect to each other, I can manage the whole game flow using Azure back-end.
I have looked at Azure Mobile Services, but it would seem that it only provides databasing functionality for your app. I think Azure Cloud Service provides such functionality, but I am unclear as to how I connect to Azure Cloud Service from my Windows phone app.
You can expose a regular web service in Azure WebSites or Cloud Service (MVC / Web API) which you could then consume from your WP app:
http://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-rest-service-aspnet-api-sql-database/
http://www.asp.net/web-api/overview/web-api-clients/calling-web-api-from-a-windows-phone-8-application
I am developing a mobile application that makes extensive and continuous use of SignalR to communicate to a SignalR service.
I have previously assumed that I would use a Web Role to host the service, and then add more Web Roles backed by a backplane of Service Bus or Redis as and when the service needs to scale out. Using a Web Role would also allow me to significantly scale up if I wanted to avoid possible latency issues with the backplane.
However when I compare the pricing of the Web Role to Azure Mobile Services it appears that the Mobile Services may be cheaper.
So can Mobile Services be used instead?
And if so what are the pros and cons of doing so?
We are close to rolling out an update to Azure Mobile Services .NET backend which comes with some neat integration with SignalR built in. I'll be posting a blog on it on http://blogs.msdn.com/b/azuremobile/ (and of course on twitter #frystyk) when it's there and how to use it.
Henrik