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.).
Related
I have two App services which I deployed to the same resource groups within the same region. The icon associated with them are different while both of them identify as App Service. Why are the icons different and what do they mean? Any cost implications?
Azure App Services come in different flavors including Web Apps, API Apps, Mobile Apps, and technically Function Apps (Azure Functions). The first App Service in the above image is a Mobile App and the second is a standard Web App. They are all technically web apps but the Mobile and API apps offer some subtly different default configurations and features that target the specific needs of supporting mobile app back ends or hosting APIs for example.
You should ensure you're deploying to the desired app service type before continuing. Generally speaking you would know if you needed to deploy to a Mobile App so if this is by accident I would recreate the resource as a standard Web App App Service. More details available at https://learn.microsoft.com/en-us/azure/app-service/app-service-web-overview
i have a web app that has a seperate nodejs backend and angular frontend.
is it possible to make them both run on the same azure web service? or do i need a stand alone service for each?
my nodejs server is just a light API that feeds my angular app with some statistical data to render it. if it is possible what would be the way to do it?
since i am using typescript i know i need to push my nodejs using zipdeployment and i know i need to use visual studio to push my angular project to azure. but when i want to run both on the same service, how do i do it?
is it possible to make them both run on the same azure web service? or do i need a stand alone service for each?
If you choose the Web App on Windows OS, IIS allows you to configure multiple virtual applications within a single website. For this approach, you could follow Deploying multiple virtual directories to a single Azure Website. Note: The multiple virtual applications would share the same application pool.
As kim mentioned, you pay for the App Service Plan, not for the Web App. You could also host nodejs backend and angular frontend in different web apps under the same app service plan.
For the deployment, you could leverage VS publish wizard or manually upload your files via KUDU or FTP. Moreover, you could also follow Deploy the app section about various approaches for deployment.
You can run multiple web sites in different web apps in Azure so that they are sharing the same Azure App Service.
You can think of the App Service as a virtual machine offering resources for your applications. How many web apps you can run simultaneously depends on the size of your plan, see this page for details.
This way you can deploy them separately, manually or automatically using e.g. VSTS.
I have a web application that was being developed using Web Roles in Azure. It is a relatively complex application in which clients communicate with each other via the web server. Client to server communication is via SignalR and within server instances Web Api is used.
It was critical that it was tested against multiple instances of web roles since the all of plumbing needed to potentially communicate across the various instances of web roles.
This was easy to do in web roles since in Visual Studio's project properties you would simply up the instance count and the Azure Compute Emulator would open a bunch of instances for you.
After attending a recent Microsoft technical briefing, it was suggested that web roles were being superseded by Web Apps in Azure App Service. Indeed on the surface these appeared to be a better fit to my problem and I have been investigating this as an architecture.
The problem I have found is how to simulate multiple instances? Web Apps in development spin up in a single IIS express instance and thus have the same IP address on my development computer. Web Roles spin up in difference instances and all have different IP addresses which makes testing easy. From what I understand on production, web apps, if configured to have multiple instances, will get different IP addresses (and/or ports) since they may be running on different servers
So how do I test multiple instances of Web Apps in the Azure App Service that need to cross communicate in development?
...or am I just missing something big here?
Thanks in advance.
Dave A
You can use the ARRAffinity value to specify which instance you want to hit, allowing your request to hit any instance you want.
You can find more details here: http://blog.amitapple.com/post/2014/03/access-specific-instance/#.VhLIGXmFMis
Could you run full IIS (w3wp) locally for testing? If so, you could create multiple sites or applications using different application pools, and hence processes.
I found this. http://blog.tylerdoerksen.com/2013/11/01/azure-websites-vs-cloud-services/
In short, given that I need to have some internal communication then Web Apps in Azure App Service should not be used.
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'm fooling around with a WebAPI application I've developed in two solutions: one solution is the WebAPI / serverside solution with db access using SQL server, the other is a durandalJS client application. I have the WebAPI bits hosted in an Azure Website right now, but I'm not sure where to put the client solution.
Should I throw it in its own website and just have it make requests within azure across to the other website? I want to avoid putting them in the same solution because I would eventually like to practice load balancing the front-ends when I have more dough to play with.
Idea of cloud like Azure is pay as you go. If you do not have the volume currently to load-balance, why create two websites and pay for them both regardless of the usage? You can have just one web site and host both the web application and web API. In the future, if you want to separate out API piece and load balance web app, you can do that when you have the volume. For this approach to work, structure the solution like this. The Web API piece will be just an assembly which you can reference in the Web application itself and host it in the same web site as the web application. In future, if you want to separate out, create a new empty ASP.NET Web application and host the Web API referencing your Web API core assembly.