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'
Related
I built a web application using react and node , and also i want to build a mobile app , so i'm trying to build REST API to manage the database . I heard about the Azure API management and trying to using it but couldn't find any tutorial that relevant with javascript
Does Anyone know good tutorial to refer??
Azure API Management is not intended to create API, it is intended to act as a proxy, to harden your API against attacks from outside. You should be using WebApp or ApiApp to create your API.
I assume that you want to build Mobile App back-end on Azure with node.js SDK.
About how to use the Azure Mobile Apps Node.js SDK, you could refer to the official documentation here: https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-node-backend-how-to-use-server-sdk.
Also, you could take the following complete series tutorial on the Node.js SDK as reference: https://shellmonger.com/30-days-of-azure-mobile-apps-the-table-of-contents/.
Any further concern or my misunderstanding, please feel free to let me know.
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.
Microsoft Azure Mobile platform, Windows Azure Mobile Services WAMS, or its new version, App Services, are great Cloud and MBaaS tools for building mobile backends. They use a NodeJS Restful Service Engine combined with an ORM Engine to provide a very easy-to-use platform.
Does anyone know if it is possible to use this framework outside the Azure Cloud environment, i.e. in an on-premises environment ? Is this kind of NodeJS framework open ? What is the name of this framework ?
The Azure Mobile Apps Node.js SDK to Mobile Apps is an express middleware package which makes it easy to create a backend for your mobile application.
The SDK package is still in development, but you can get all the code and documents at https://github.com/Azure/azure-mobile-apps-node
About Mobile Service in Node, there is no full code project repository, but you can glance the entire code in KUDU console site of your mobile service, the URL should look like: https://<your_mobile_service_name>.scm.azure-mobile.net/DebugConsole. The root directory is D:\home\site\wwwroot
Azure Mobile Services and/or Azure Mobile Apps are only available in Azure. There is no 'framework' that you can download and install on your own infrastructures.
Besides the Node.Js version of Mobile Services there is also an .NET version which is basically just an MVC Web API with some additional 'services' added to it (notifications, authorization, etc.)
So, you could just build an MVC Web API app and manually add the missing components by using oAuth, entity framework, etc. However, this is probably not what you are looking for :)
Hope this helps!
Edward
Kudu is the engine behind git/hg deployments, WebJobs, and various other features in Azure Web Sites. It can also run outside of Azure. It can run on premise https://github.com/projectkudu/kudu but unfortunately the rest of mobile services cannot
We have built a simple mobile app that connects to ASP.net Web-API 2.
We would like to use Microsoft client SDK for it's offline sync support.
Now that Azure Mobile Apps support custom authentication we could actually take the leap.
I want to know out if the offline sync SDK absolutely requires us to use Azure Mobile App or Azure Mobile Services.
Microsoft documentation is full of how-to guides but does not explain what happens under the hood. The best I could understand, both are just OData rest API's and swagger for documentation.
Can the Azure Mobile Client SDK work with API server created on top of ordinary ASP Web-App, outside Azure?
What is it about the Azure Mobile App that makes the magic happen?
Vladmir,
On top of OData, in order to support features like soft delete, offline sync and others, the Azure Mobile Client SDK expects the server to implement a certain protocol. So although the answer to your question:
[does the] sync SDK absolutely requires us to use Azure Mobile App?
... is no, and in theory, you could implement your own API, but I would recommend against doing so, since (among other reasons) even if you manage to implement the expected conventions and behaviors, this will become a maintenance challenge down the road if you need to upgrade the client SDK to take advantage of bug fixes and/or new features.
The good news is that with the latest release of the Azure Mobile Apps server SDK, adding mobile capabilities to an existing ASP.NET Web API application is trivial, and you should be able to enable the scenarios you're looking for simply by adding the appropriate Table controllers. So you can just enhance your existing application and not have to develop and maintain the Azure Mobile Apps specific logic yourself.
About your last question, since both, the client and the server SDK are both open source and developed in the open, you can look at what what makes the magic happen here:
https://github.com/Azure/azure-mobile-apps-net-server
https://github.com/Azure/azure-mobile-apps-net-client
I hope this helps!
The answer for your first question: Yes the SDK can be used in any Server API you have since it will be your entry point to work with Azure Mobile Services.
The Azure Mobile app creates a mobile services instance which has push notifications and SQL tables to store all messages you would like to send with the capability to customize the message as needed. Also it creates a notifications hub instance under the hood to manage notifications for all mobile platforms. Azure mobile apps provide offline capabilities through native sync services between db on your devices and the server when connectivity is present.
Feel free to ask more questions to have a full understanding on How mobile apps works.
Hope this helps.
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.