I'm planning a project in which I have a windows service installed in on premise machines (about one hundred of them) which should keep in sync an online azure SQL db with the on premise ones (MS access, third party). That sync happens by calling a Web API.
I then have to build a mobile app which will be used by ~3k users that will access the synced data with Azure mobile app backend.
As for now I've started building a single mobile app backend project which serves both mobile app requests, and webapi2 requests used to sync data.
Furthermore I'll need to add queue/topic section to send realtime notifications from the app to on premise services.
My concern is if is it good practice to keep both "mobile app" and webapi2 in the same project, or should I separate them.
Any suggestion will be greatly appreciated.
Many thanks in advance!
You should, separate them. Based on your description, you should use the microservices architecture, you can read more about it in the links below.
Azure specific:
https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
https://learn.microsoft.com/en-us/azure/architecture/microservices/
In general:
https://microservices.io/patterns/microservices.html
Related
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.
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.
I want to create a Windows Phone mobile app that receive inputs, send the inputs to an exe running continuously on Windows Azure to process and send outputs back to the mobile app. I have the knowledge to create a WP apps but little experience in Azure ,though I have access to it, so I don't know which service to use and how to use it. Please help
Technically, you could run an .exe in a web role on Azure but there might be a better, and easier, way to architect your solution.
Consider using Azure Mobile Services and, as WiteCastle says, re-architect your exe into a custom web API. Here are some examples of RESTful Web API projects from Microsoft's ASP.NET site.
Here are some useful resources to get you started:
Learn how to build secure mobile apps for the enterprise: view
webinar
Learn how to build consumer mobile apps that scale: view webinar
Choosing the best backend for your mobile app: view webinar
Alternatively...
If you're more comfortable with a web based back-end, why not try a product like appery.io, which allows you to create and connect up your app all via a 100% browser based IDE.
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.
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