We are going to develop Web API using Asp.net core 2.2
Now we want to use it as serverless, so decided to use API Management (APIM) for the same.
When we started looking into how to deploy API in APIM, it seems, we 1st need to deploy API in App Service and then configure it in APIM.
As in this case, we are not going with serverless architecture (i.e. paying only for calls) and we are paying for both i.e. App Service and APIM (to have under VNet, £1500 more)
Is this the right approach?
While going thru more on this, i found that we also can write Azure functions using Visual Studio code OR Visual Studio 2017. Hopefully it will be similar kind of development experience as we have with Web API.
So with Azure Functions, it will be serverless architecture.
Only issue is that AzureFunctions#Edge is not available as of now and we need to use 3rd party CDN like CloudFlare for the same.
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.
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
is there any way to publish my API in azure mobile service API instead of using its own. I want just to know it, because assume I have a backup server in amazon and as you know I don't have access to azure sdk in there and it means technically I cant use the API anywhere outside the azure.
Azure mobile services is actually based on the .Net web api in their C# flavor and on node.js on the Javascript side. You could surely write an API using those technology and have the same behavior. You will gain the fact of being more portable, however you will lose some of the preconfigured stuff from Mobile services.
If you are using .NET, please check this to see how to build a Web api! http://www.asp.net/web-api.
If you are using Javascript, here is where you should start : https://nodejs.org/
Both tech are quite easy to learn and super powerfull, have fun! When your API is built, you could just publish them as an azure Web APP (http://azure.microsoft.com/en-us/services/app-service/web/) or an Azure API (https://azure.microsoft.com/en-us/services/app-service/api/) instead of the mobile App
Hope it helps, if you have more questions, please ask!
You can create and publish your own custom APIs in azure mobile service. You could even access in via azure mobile service sdk in client by using "InvokeApiAsync<>()" method.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn614130.aspx
If you want to access the api via fidder/httpclient than AZM SDK, pass the mobile service key in HTTP header as Name:'x-zumo-application' value:'application key from portal'
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 need to connect to a middle tier (think Azure) between both my Windows store app and WP8 app. Windows Azure Mobile Services has been proffered as a/the solution.
But am I reading too much into the name "...MOBILES Services" (as one of the pieces is not a mobile app, but runs on desktops, laptops AND tablets)?
In my case, am I better off with Azure Cloud Services as opposed to Windows Azure Mobile Services?
Windows Azure Mobile Services is a fast, easy way to get a back-end in the cloud for your mobile apps and Windows 8 apps (it's fine if your Windows 8 apps aren't necessarily targeting mobile devices). It includes the things most commonly needed in a back-end, such as authentication, database storage, and push notifications. There's no server-side development needed here, you just request the back-end and moments later it's ready to use; however, if you do want server-side logic you can add it in the form of JavaScript scripts.
Alternatively, you could build your own back end in the cloud using a combination of Windows Azure Cloud Services such as the Compute, Storage, and SQL Database services. You have access to more features at this level, but you also are doing your own development. You can write server-side logic in C#, VB.NET, PHP, Java, Python, etc. as you prefer.
Which should you use?
If Windows Azure Mobile Services meets your needs, and you'd rather focus on your mobile app than learning anything cloud-specific, that's likely the best path for you.
If you're conversant with the Windows Azure platform, and need features different from what WAMS provides, that suggests creating your own back end with Cloud Services.
If you're not sure which way to go, I suggest experimenting first with WAMS since it is quick and painless to get started.
Azure mobile services is designed to get you up and going with storing data, push notifications and authentication whichever of those components you might need.
It abstracts the need of creating a data access layer and a web/wcf service to access it from your applications; it's simply there to boilerplate as much functionality off the bat.
This however does not mean that it is only for mobile applications, behind it all is a normal SQL Azure database and an API that you can use from any .NET based application.
I would reason that if you need more than basic CRUD operations and won't be using authentication and push notifications, I would roll my own set of APIs and DAL and use cloud services instead.
If you need a flexible schema, boilerplate data access and want to use some of the other mobile services, it would suit you quite well.
Here is a link to getting going with mobile services from a non Windows8 or WP - ASP application : link