Azure Mobile Services .NET Backend
•Télécharger en tant que PPTX, PDF•
0 j'aime•2,855 vues
When you thought Azure Mobile Services couldn’t become more awesome the .NET backend was thrown into the mix. This gives us an extremely powerful, scalable and easy to work with backend – in the cloud! In this session, I’ll show you how to get hacking with the .NET Backend for Mobile Services, how to cater for different connectivity patterns by taking data offline and how to leverage other data sources such as Mongo!
Recommandé
Recommandé
Contenu connexe
Similaire à Azure Mobile Services .NET Backend
Similaire à Azure Mobile Services .NET Backend (20)
Dernier
Dernier (20)
Azure Mobile Services .NET Backend
- 1. Azure Mobile Services Mobile Services <3 Web API Filip Ekberg
- 2. Page / Copyright ©2014 2 by Readify Pty Ltd @fekberg
- 3. Page Filip Ekberg C# MVP http://fekberg.com @fekberg C# Smorgasbord / Copyright ©2014 3 by Readify Pty Ltd
- 4. @fekberg Page Agenda › Quick re-cap: What is Azure Mobile Services? › The .NET Backend for Mobile Services › Offline Data › Alternative Data Stores / Copyright ©2014 4 by Readify Pty Ltd
- 5. @fekberg Page What is Azure Mobile Services? / Copyright ©2014 5 by Readify Pty Ltd
- 6. @fekberg Page Scalable backend in the cloud › Runs in Azure › Backed by Node.JS › Dynamic data schema / Copyright ©2014 6 by Readify Pty Ltd
- 7. @fekberg Page Cross-platform capabilities › iOS › Android › .NET › REST API / Copyright ©2014 7 by Readify Pty Ltd
- 8. @fekberg Page Push Notifications › Windows Store › Windows Phone › Android › iOS / Copyright ©2014 8 by Readify Pty Ltd
- 9. @fekberg Page Authentication & Authorization › Microsoft Account › AD › Twitter › Facebook › Google / Copyright ©2014 9 by Readify Pty Ltd
- 10. @fekberg Page NodeJS / Copyright ©2014 10 by Readify Pty Ltd
- 11. @fekberg Page The .NET Backend for Mobile Services / Copyright ©2014 11 by Readify Pty Ltd
- 12. @fekberg Page Powerful backend with WebAPI / Copyright ©2014 12 by Readify Pty Ltd
- 13. @fekberg Page Host Anywhere / Copyright ©2014 13 by Readify Pty Ltd
- 14. @fekberg Page Cross-Platform capabilities / Copyright ©2014 14 by Readify Pty Ltd
- 15. @fekberg Page Debugging in the cloud / Copyright ©2014 15 by Readify Pty Ltd
- 16. @fekberg Page Demo Using WebAPI and Mobile Services / Copyright ©2014 16 by Readify Pty Ltd
- 17. @fekberg Page Going Offline / Copyright ©2014 17 by Readify Pty Ltd
- 18. @fekberg Page Different connectivity patterns › Always connected with High-Speed Internet › Always connected with Mobile Internet Connection › Occasionally Connected › Barely Connected / Copyright ©2014 18 by Readify Pty Ltd
- 19. @fekberg Page We need to cater for all connectivity patterns / Copyright ©2014 19 by Readify Pty Ltd
- 20. @fekberg Page Delivering data costs money! / Copyright ©2014 20 by Readify Pty Ltd
- 21. @fekberg Page Managing Offline Data / Copyright ©2014 21 by Readify Pty Ltd
- 22. @fekberg Page Out of the box support for SQLite / Copyright ©2014 22 by Readify Pty Ltd
- 23. @fekberg Page Synchronizing Data / Copyright ©2014 23 by Readify Pty Ltd
- 24. @fekberg Page Handling concurrency / Copyright ©2014 24 by Readify Pty Ltd
- 25. @fekberg Page Who wins in a collision? / Copyright ©2014 25 by Readify Pty Ltd
- 26. @fekberg Page Concurrency Strategies / Copyright ©2014 26 by Readify Pty Ltd
- 27. @fekberg Page Optimistic Concurrency › No locks! › Notified about conflicts › Ask the end-user which version to take? / Copyright ©2014 27 by Readify Pty Ltd
- 28. @fekberg Page Advanced Conflict Resolution › Can we merge data? / Copyright ©2014 28 by Readify Pty Ltd
- 29. @fekberg Page Demo Taking Data Offline / Copyright ©2014 29 by Readify Pty Ltd
- 30. @fekberg Page Alternative Data Stores / Copyright ©2014 30 by Readify Pty Ltd
- 31. @fekberg Page Use your on-premises solution / Copyright ©2014 31 by Readify Pty Ltd
- 32. @fekberg Page Supports a wide range of stores / Copyright ©2014 32 by Readify Pty Ltd
- 33. @fekberg Page Demo Going offline with SQL Server & MongoDB / Copyright ©2014 33 by Readify Pty Ltd
- 34. @fekberg Page Summary › Mobile Services just got a whole lot more powerful › Create a powerful backend using WebAPI › We can easily debug our WebAPIonce in the cloud › Offline data let’s us cater for all usage patterns › Support for a wide range of different data stores › Synchronization problems(collisions) can be handled in multiple ways / Copyright ©2014 34 by Readify Pty Ltd
- 35. @fekberg Page Questions? / Copyright ©2014 35 by Readify Pty Ltd
- 36. Page Thank you! http://fekberg.com @fekberg C# Smorgasbord / Copyright ©2014 36 by Readify Pty Ltd
Notes de l'éditeur
- We’ve got a packed Agenda today with everything from A quick re-cap of what mobile services is How to use .NET for the Mobile Service Backend How to take our Data Offline And how to use alternative data stores If you have ANY questions during the talk, please feel free to interrupt me any time! If you don’t like to ask questions here, grab me after the talk, I’ll happily help out and answer the questions to the best of my knowledge
- Quick 1-2 minute Mobile Services recap How many Mobile Service Experts do we have in the room? How many of you have never seen Mobile Services Before? How many of you can’t be bothered to raise your hand?
- How many of you have used the NodeJS Backend? How many of you actually like working with it? How many of you ENJOY debugging it? NO MORE CONSOLE LOGGING DEBUGGING!
- I Give YOU the .NET Backend For Mobile Services
- Hosts our controllers, everything else is maintained by Azure “Platform as a Service ++” – “The next generation of platform as a service” Bring Your Own Controllers! Lets us more easily filter data before sent to client Use built in [Authorize] when introducing Authentication
- You don’t need to host this in Azure But why wouldn’t you?!
- Integrates with the SAME platforms as before: iOS Android Windows Phone Windows Store REST.. The contracts/api is the same as before!
- The NodeJS backend we all loved to debug is in the past, we can now debug our application like any other .NET application EVEN when it’s published to the cloud!
- Let us now take a look at building a Mobile Service, backed by Web API that we can run, debug and work more easily with both locally and in the cloud
- I want to tell you a story… When arriving in Australia – The first thing that I did was to run around with my soon to be wife in Sydney CBD to find a GOOD, fast and reliable mobile carrier. After understanding that there’s no such thing here, I went with the one giving me the most data for the buck – to my surprise even if you are allowed to use a lot of data this doesn’t matter if there’s no reception Time went by and me and my fiancée were quite happy with the 4GB of data that we could use each month, especially since the coverage in Sydney isn’t that too bad! However, once summer approached and our plans to jump on a plane to Cairns and go for a road trip with her parents for 10 days were in action – the fact that coverage in Sydney was good didn’t mean coverage in the roads in the wilderness would be just as good. Now, being on the road for 10 days with your fiancée’s parents is an interesting achievement on it’s own – but when there’s 4 social media addicts in a car without internet coverage – I can just tell you: wow. I don’t know how we survived, but we certainly did This experience had me thinking, a lot of countries outside Australia, especially European countries are so spoiled when it comes to great internet connection When apps are being developed by developers in these countries, they don’t consider us poor souls that have to go on road trips and enjoy ourselves here in Australia – no – they cater their applications towards people with constant 100/100 Mbit connections What if we could use our social media, to for instance just publish our pictures on the trip, do check ins and all that and have this sync whenever we have a connection? This is where I wish these developers thought more about allowing data to be used offline, as well as online
- What if the developers of the applications that we so desperately needed on our journey would think of the different connectivity patterns? We have people using high speed wifi all day long We have people using 3G/4G connections more often than wifi We have people on less good mobile connections such as 2G, they rarely want to sync their data because it is too slow. These people may occasionally connect using wifi We have people on airplanes, people working on the farms, we have a lot of spots in Australia where there is no connection what so ever, the people working on these locations primarily – they are barely connected at all
- We need to cater for all these different connectivity patterns Our applications may, or may not allow a lower amount of functionality in the different connectivity states – but that is OK! We just don’t want to tell our users to ALWAYS be online to use our applications, unless it is a true online only solution Even Streaming services like Spotify allows a offline mode! (Swedish company by the way!)
- In Australia, delivering data both over the mobile network and on your home internet connection will cost money This means we need to think about how much data we send, and when Can we let the user decide?
- Taking Data Offline seems like the obvious decision to make How many in here have “rolled their own” Offline sync? We need a good way to manage data we want offline – with all the difficulties that comes with it! Where do we store the data? What happens when data has been produced, modified or deleted from different sources?
- How many have heard of or used SQLite? SQLite is a database engine that is: Self contained which means it doesn’t rely on third party libraries or special frameworks to run Server-less – you work directly against the database on the file system No configuration needed! Transactional SQLite runs on a WIDE range of devices, which makes it EXCELLENT for cross-platform development iOS Android Windows Phone Windows Store Etc.. SQLite is supported on all platforms Mobile Services is supported on! The support comes out of the box, we simply need to point to a place where our SQLite database is located
- Keeping the local version and the server version up to date is key Mobile Services supply us with an easy way to push and pull changes This will also tell us about potential problems with the push for instance When do we want to sync data? Do we want to sync every time a user comes online? Remember the different connectivity patterns: Barely connected users may want to sync manually when they are on their good corporate wifi again Always connected can be fully automated to look at the device status
- Syncing data can cause problems that we need to handle How many of you LOVE concurrency problems? We need a good way to handle concurrency This means that we need a way to handle when data has been changed Remember when I was on my road trip, what if I needed to do some quick work done on a document in a custom built system. Imagine I got this text from my boss sends you a text: I NEED THIS CHANGE ASAP! – Completely forgetting about the lack of connectivity! Now, being in the wilderness surrounded by crocodiles, there’s a few other things on my mind so not taking to much into consideration that I don’t have a good 4G connection – my data isn’t synced Few hours later I got to a 4G spot – my data tries to sync We all know that URGENT messages goes to more than one person, so this document was updated by a co-worker instead, he pushed his change before mine Now I had two problems – Being afraid of nearby crocodiles and sync problems – I really don’t know which one is worse!
- So how do we decide what version wins the collision war? In this case here, we have a few people working on the application, pushing their changes occasionally We forget about our friends working out in the wilderness, that rarely have connections They come online and tries to sync their data BAM – doesn’t work because there’s a concurrency issue So who wins? How do we weight which version is the best to take? Last in wins? First in wins? Do we pre-lock data?
- In the case of Mobile Services, we have a few concurrency strategies that we can take into consideration We could just overwrite the change whenever there is a push – but that is just avoiding the problem!
- We do not want to lock the data, as this requires us to be online When I was running from crocodiles, being haunted by SMSes from my boss – do I really want to start looking for a 4G spot to lock my data? I think not! We can use something called Optimistic Concurrency This means we can notify the user about the concurrency and we’re not locking any data in advance When there is a conflict, we can simply ask the user what version to take We all know that people will always say “CHOOSE LOCAL VERSION” Hands up if you handle sync conflicts by saying “CHOOSE LOCAL VERSION”!
- What if two independent fields of an object changed, can’t we just merge? We won’t look at how to implement a more advance sync, where you allow users to merge It is certainly something to keep in mind, users might want to get the options to merge their data instead of overwriting
- Let us now take a look at how we can introduce offline data in our application We will look at how to connect to our pre-existing mobile service Without changing anything on the server, we will introduce a local store for our data on our devices We will then make sure that the data is downloaded and synced when there is a change Need to install SQLite extensions Install-Package WindowsAzure.MobileServices.SQLiteStore -pre
- We have seen how to setup a new Mobile Service and connect to a SQL Server that is hosted in Azure This may have indicated to you that you could really tell your Mobile Service to connect to any store Bring Your Own Database!
- Our On-Premises solution may already have a Web API and a data store attached to it We can easily take our existing Web API controllers and host that with our Mobile Services This pre-existing solution may of course include a connection to a different data store than what comes out of the box with a new Mobile Service
- What stores? Table Storage SQL Server MongoDB It is very easy to connect to your on-premises solution In terms of SQL Server What happens with advance mappings? – AutoMapper What happens if we don’t want all data exposed from our existing backend? – Allow subset of the data
- Let us now take a look at how we can change our backend to instead connect to a data store like Mongo and SQLServer Connecting to Mongo is much easier than you might think, even though the data store is a bit different from storing something in SQL Server or Table Storage Offline sync with Mongo requires a bit of tweaking Connecting to our on-premises SQL Server requires us to define a mapping, using AutoMapper so that we can tell our service which data to expose To use Mongo: WindowsAzure.MobileServices.Backend.Mongo Let’s get to it!
- We’ve seen a lot of REALLY exciting changes coming from Microsoft in this space Mobile Services just got a whole lot more powerful as we can bring in our existing Web API, use Web API to define our .NET backend hosted in Mobile Services and use everything that we already know and love about Web API It’s so awesome that we can hook up our debugger to the cloud and see what is really going on when our application is running – this is an amazing pain point that they have looked after! The next time I’m on a Road Trip – which will actually be later this year – I really hope more developers have incorporated the idea of offline data Not EVERYONE have access to 100/100 Mbit all the time No matter if you are coming in with a Mongo DB, SQL Server or Table Storage – you can introduce this with your Web API and Mobile Service! Doesn’t matter where you host your Mobile Service – You can host it in your private cloud in your basement – or go for the more scalable and reliable option – Azure Finally we’ve discovered different ways to handle concurrency and collisions – it may not be as easy as we think!