Related
I am developing Mobile App .Net server and want to use the service on self hosted servers for production usage. The service will be deployed on IIS instead of Azure portal. I am working on offline data sync feature using Microsoft.Azure.Mobile.Server package. And for client Microsoft.Azure.Mobile.Client is being used. And all these packages and dependent libraries are open source as its available on github.
So, what about its licencing? Is there any limitation or licencing clause that restricts from using these applications without Azure portal?
Or its free to use?
As you mentioned, these libraries are open source licensed with Apache 2.0. So, you can use them without any problem, as long as you mention the original authors.
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 have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.
All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.
Authentication
In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.
Push Notifications
Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.
The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.
The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.
But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.
Scale
As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).
Are there any big differences I missed?
Are any of the claims I made are incorrect?
It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).
That's a question I often get when I present Mobile Services at user group events.
For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.
Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.
I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.
I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.
One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)
To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.
The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.
AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.
However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.
If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?
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