I am a newbie to Windows Azure platform.
My team is developing a web and a mobile application and we are thinking of going with this platform. But I have few doubts taking that:
My web and mobile application will access the same database, so is it possible to have a same cloud database in windows azure allowing both mobile and web application to access it
Few examples and references will help a lot.
Note: I have a request and reponse operations from both client and server, so its two way communication process for mobile and web app.
Thanks!!
We built a project recently that was built using webAPI on MVC 4.0. We built an Azure Cloud service project in Visual Studio 2012 ,and created a web role that hosted both webapi (REST based Services) and MVC web application.
To secure our API, we implemented a token based security mechanism over the WebAPIs for user authorization. We created two different Routes /Rest/API (to handle CRUD) and REST/RPC(to handle additional operations.
In all, we had following layers in the solution
MVC Web Project
--API (APIControllers - REST + RPC)
--Controllers (MVC Controllers)
-- VIEWs
MVC Web ROle Project
-- Mapped to the MVC Project in the web
Repository
-- Repository classes for entities
Data Access
-- Data Access classes for each entity using DAPPER
Models
-- POCO Classes representing entiries
Related
I have reading about the new Azure offerings and trying to figure out what is what. The documentation I have been finding all over seems to have more information about the frameworks that are not valid anymore like this one here. Most of what they talk about at 4.8, 5.23, 12.13 into the video are no longer valid.
So far what I understand is that Mobile Services was offered in the past. That will soon be discontinued and App Services will take over. App Services are the top level services that contain Api Apps, Mobile Apps and Web Apps. Is this correct?
I am confused as to why we have Api Apps and Mobile Apps. Don't they do the same thing? And now that we have Web Apps in addition, are they only limited to UI related applications? The only simple thing to understand and one that has no similar other offering is the Logic app. This seems to be something that can only be done on the Azure portal. Visual Studio has no project template for it. Is there something that needs to be installed for creating logic apps in my visual studio only?
Also, in Visual Studio 2015 what is the difference between the Asp.Net Web Application project template under the WEB node and the CLOUD node? They both seem to be holding the same templates within.
Why do we have Azure Mobile App and Azure Mobile Service right under the Cloud node like here below..
..and also after selecting Asp.Net Web Application
On the face of it, both look the same. Are there any subtle differences that one needs to know about?
Also, why are all these options also not available for Asp.Net 5 templates? With all the changes happening is it a good idea to put apps developed under the latest versions to production?
Thanks for any pointers.
Azure Mobile Apps are the next version of Azure Mobile Services. Azure Mobile Services has been deprecated, and you can't provision it on new subscriptions. Mobile Apps has a lot more features over Mobile Services. To learn more, see I use Mobile Services, how does App Service help?.
Mobile Apps, Web Apps, and API Apps are all essentially the same thing, they just have some extra features for building particular solutions. You publish each of them to an App Service Plan, which is the actual underlying VM that hosts your service.
Once you've provisioned one of these app types, you can publish a Web API to it, regardless of what app type it is. For instance, you can publish your API to a Web App or Mobile App. Once you've picked a particular app type, you aren't locked in, you will just see a slightly different UI in the Azure Portal.
Mobile Apps also have a Mobile Server SDK for Node.js or .NET. The .NET server SDK is an extension of ASP.NET Web API. It doesn't yet support ASP.NET 5, mainly because there is a dependency on the OData library, which doesn't yet support ASP.NET 5. However, Mobile Apps is under active development and will support ASP.NET 5. Unfortunately, we don't have a timeline to share, mainly because not all the dependencies are complete.
For Mobile Apps in particular, you get the features of client SDKs that support authentication, offline sync, and push notifications. The easiest way to learn about the offering is to follow the quickstart guide: Create a Windows app on App Service.
You can learn all about the SDK and try them out, even without an Azure Account. Here's documentation about the .NET server SDK: Work with the .NET backend server SDK for Azure Mobile Apps.
API apps have a few extra features like creating a metadata endpoint for you automatically, which you can then use to generate client library using Visual Studio.
Currently, only Web Apps and Mobile Apps have a demo experience available at Try App Service, but you can see the API experience if you use a Microsoft Account to sign in, and then manage the app in the Azure Portal. You will see all of the API app and Mobile App options in the portal.
Note that Web and Worker roles are part of Cloud Services, and are a totally separate service. To learn about the difference between these, see Azure App Service, Virtual Machines, Service Fabric, and Cloud Services comparison.
I just describe what is the difference between Azure App Service, Mobile Apps and Api Apps, hope it helps:
Web and Mobile Apps o Mobile Apps offer a mobile application development platform with a rich set of capabilities. Based on Azure Mobile Services, Mobile Apps provide developers with a comprehensive set of client SDKs including Windows, iOS and Android as well as multi-platform environments such as Xamarin and Cordova. With Mobile Apps, you can easily send push notifications to your app, add login, and store data in the cloud with offline sync to any mobile client.
With API Apps, you can select from a rich library of existing on-premises and cloud APIs as well as contribute their own APIs easily for public or private use by Logic, Web, and Mobile apps in Azure App Service.
Azure app service, is a solution for creating web and mobile apps, is a cloud services that unifies everything you need to quickly and easily create enterprise apps that run on any platform or any device.
Azure app service is composed of: Web Apps, Logic Apps, Mobile Apps and API Apps
There is no longer API Apps in Azure, there is now only Web Apps.
I have been doing quite a bit of research into Azure's various offerings and what they can do, however, it is quite hard to figure out how they might fit together. I have set up a Mobile Service to act as my mobile app's back-end, managing push notifications and data storage etc. This populates a SQL database I have provisioned, all good so far. However, I would now like to display this data in a dashboard type web app. Do I create a private API and host it on another Azure App Service and call it from a separate web app which populates a dashboard, or populate the dashboard directly by querying the SQL database? Not sure of the security implications of either set up, or implementation issues?
Azure App Service can combine both mobile and web components. You didn't mention the preferred language, but ASP.NET (MVC5) and Node.js are supported for the mobile component.
If you have not started using the Mobile Service in production, add the Mobile Apps SDK to your website, update the client SDK to point to the Mobile Apps SDK and just have one site.
Refs for the Server SDKs:
* node
* ASP.NET
Your best bet here is probably to create an empty Web App Service (Website) and have the Mobile Service populate the data on this website, in order to visualize it.
So keep the Mobile Service you have now, and connect it to a new website.
I installed VS2015 and the latest Azure SDK. I'm somewhat confused by the addition of new project templates compared to VS2013 and the previous Azure SDK. I'm trying to get my head around the new Azure App Service.
I used to create a Web API project and publish it as an Azure Cloud Service. Now, I'm offered more options:
1) Azure Cloud Service -> ASP.NET Web Role -> Web API
I'm familiar with this one.
2) Azure Cloud Service -> ASP.NET Web Role -> Azure API App
Why would anyone create an Azure API App and publish it as a cloud service?
3) ASP.NET Web Application -> Web API
4) ASP.NET Web Application -> Azure API App
These two are essentially the same as the first two without the cloud service template. However, the way they are published confuse me even more. You could publish each as a Microsoft Azure Web App or Microsoft Azure API App.
How do the following compare and contrast:
Web API -> Published as a Web App
Web API -> Published as an API APP
API App -> Published as a Web App
API App -> Published as an API APP
I agree, the tooling has confused this a little. Here is how I am dealing with it:
"Cloud Services" seem to be a thing of the past, any new project I am doing I am going with AppService and scripting the set-up of that app service with an ARM (Azure Resource Manager) template. You will find a template for this under Cloud->Azure Resource Group in VS 2015. This is entirely optional, but is a great best practise.
As you point out above, all 4 combinations are valid. In fact an Azure API App uses the same technology under the surface as the website does (it is a little buried away in the portal, but you can navigate down from the API app to the underlying website by opening the API App in the preview portal, and under the label for "API App Host" double click).
Using the API App template in VS2015 you will just get a standard asp.net website like you do with the web app templates, but the main difference is that the API App is slimmed down by default unlike the website template that will have lots of libraries that are of no use to an API app (no jquery, bootstrap RazorViews etc). The smaller footprint should mean that there is less to load when asp.net starts-up, hence faster start-up times.
API apps have easy integration points for use in Logic Apps (think a workflow from Salesforce defined in the Logic app that requires to call your API to update data to your database). You could do this with a web app, but there will be more plumbing to do.
I believe the plan in the near future is a marketplace of API apps (app store style) that will allow us devs to sell APIs.
Swagger out the box. The API app template has Swashbuckle pre-installed for generating the Swagger documentation for you API (arguably you could just install this via nuget into your web app template).
On the whole API apps have the exact same functionality as web apps, but slimmed down with extra bits in places.
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.
I have developed an MVC5 web application which uses Code First Migrations to build out the database. Now I am attempting to develop a mobile app (using PhoneGap if that matters) that exists as a native option to access the data of the application. However, I am having trouble finding a way for the databases to work nicely together.
Ideally, I'd like to use the same database schema entirely, and just have the application and the mobile app point to it. The database is hosted on Windows Azure. The issue I'm having is that with Azure, the standard way of handling databases with mobile apps is to use an Azure Mobile Service. However, when that service creates a database, it creates its own schema named after the service, whereas the web application uses the dbo schema. So the Users table might exist in dbo.Users for the web app, but in myAppName.Users for the Mobile Service.
I've already explored this solution, which seems to mirror my problem. However, there is an additional issue. The .NET MVC5 Authentication services use dbo as the default schema and there seems to be no way to change that.
Bottom line, if I use the default schema, the mobile app cannot access the database, but if I move the tables to the Mobile Services schema, the Login/Authentication fails because the tables don't exist in the default schema anymore.
Am I missing something here? It seems like it should be a fairly common task to have a web app and mobile app accessing the same database, but I've been investigating this for days without finding a solution.
Thanks for any help you can provide.
The standard way of using a database for mobile apps in Azure is not Azure Mobile Services. I mean, I would not call it standard but just one of the options.
When Azure Mobile Services creates a database it does not create the database with its own schema. Azure Mobile Services does not have a predefined schema. You can define your own schema. The only predefined logic is the addition of the azure mobile services tenant name as a prefix to all table names. This is done to help you host multiple azure mobile service accounts in a single database. You can override this logic if you write the app in .NET. I'm not sure if that's possible if you roll a JavaScript based Azure Mobile Services account.
My suggestion to you would be to roll your own ASP.NET Web API project and host it in Azure. You can host in Azure Web Sites or Cloud Services according to your requirements. Once you have your own APIs running in Azure you should have no problem accessing the APIs from a web site or mobile app.
Hope this helps.