Azure Mobile Services Workshop

Editor's Notes

• #11: 24 regions as of Oct. 2015 (more than AWS and Google combined)
• #15: Azure Portal Demo
• #17: Slide Objectives: Explain what a Backend-as-a-service is Explain the features (at a high level) that Mobile Services offers Transition: Let’s answer the question, what is Mobile Services? Speaking Points: Mobile Services is a Backend-as-a-Service (BaaS). Instead of coding, testing, deploying, and maintaining your own backend, you spin up a Mobile Service and can instantly take advantage of a ton of great features. These features include: Data storage powered by SQL Database (but not requiring you to be a DBA) Simple and easy to use push notifications User authentication and data authorization Server side logic so you can craft how your application will function on the server. Scaling – so you can meet the demand of your mobile apps when they get featured Logging and Diagnostics so you can get insight into how your Mobile Service is working Backend processing using something called Scheduler Notes: You may want to mention at this time that support exists for other platforms as well (Win Store, Win Phone, Android, iOS, HTML/JS, Xamarin, etc)
• #20: RDFE (RedDog Front End) is the publicly exposed API which is the front end to the Management Portal and the Service Management API (ie. Visual Studio, Azure MMC, etc). All requests from the user go through RDFE. FFE (Fabric Front End) is the layer which translates requests from RDFE into the fabric commands. All requests from RDFE go through the FFE to reach the fabric controllers. ARR: Application Request Routing
• #22: Slide Objectives: Start talking about server side scripts Transition: Speaking Points: In addition to creating a REST API when you generate a table, Mobile Services also creates scripts which intercept CRUD requests against your table As Mobile Services is built off of Node.js, these scripts are Node style scripts By default these scripts just pass through whatever you have sent over to SQL DB However, you can customize your own logic in these scripts to do whatever you want Notes:
• #23: Slide Objectives: Mention some of the modules available out of the box in the server side scripts Transition: There is a ton of stuff you can do in the scripts and we’ve exposed several modules already to make doing things easy Speaking Points: Some of the modules available out of the box are Request – for performing http requests to third party services Push.* - for doing push notifications with APNS, GCM, WNS, MPNS Console – for logging information MSSQL – for performing custom SQL queries and calling stored procedures statusCodes – for returning a status code other than what is expected Azure – for getting access to Windows Azure Table and Blob storage, queues, service bus, etc We also have several partners in the Windows Azure store who offer you other abilities Sendgrid – allows sending emails Pusher – facilitates web socket style real time communication down to mobile apps and websites Twilio – sends SMS messages and offers some other voice capabilities In addition to the modules available out of the box. If you enable source control on your mobile service you can then use the node package manager npm install to install any available node package (e.g twitter, imageprocesing, anything) into your mobile service. Notes:
• #25: Demo Branch – Step 1
• #35: Demo Branch – Step 2
• #37: Slide Objectives: Detail Auth options Speaking Points: Windows Azure Mobile Services enables you to set the following permissions on table operations: Everyone: This means that any request for the operation against the table is accepted. This option leaves your data wide-open for everyone to access. Anybody with the Application Key: Only the correct application key is required to perform the operation. The application key is distributed with the application. Because this key is not securely distributed, it cannot be considered a security token. To secure access to you mobile service data, you must implement authentication. Only Authenticated Users: Only authenticated users are permitted to perform the operation. In this preview release, clients are authenticated by Live Connect services. Scripts can be used to further restrict access to tables based on an authenticated user. Only Scripts and Admins: The operation requires the service master key, which limits the operation only to registered scripts or to administrator accounts. The user parameter is available in all server side scripts methods and can be used to add more granular auth polices on you CRUD operations Notes:
• #38: Slide Objectives: Review the flow of authenticating users Transition: There is a fourth mode of authorization which is “Only authenticated users” Speaking Points: You’ve got a couple options when it comes to authenticating your users. First, Mobile Services has built in support for handling authentication with several popular providers. To use this method, you call a login method from the Mobile Services SDK This opens a webview which goes to a URL in your Mobile Service which in turn directs you to whichever provider you selected Facebook Google Microsoft Twitter When the user finishes logging in, they are handed back to your Mobile Service The Mobile Service then returns to your app with a User ID and an Auth Token The Auth token is important because it’s basically your User ID with some other information that has been signed by the Master Key of your service. The alternative flow is to use a native SDK to authenticate your user. This gives you back a provider token This token can be sent to your Service through another background method which will return a User ID and Auth Token Once you’ve got a User ID and token, you can then hit your API and the security layer will check to make sure that User ID and token are valid and unexpired Notes:
• #39: Slide Objectives: Review different authorization options for permissions on tables and custom APIs Transition: Let’s move into authentication and authorization Speaking Points: When you generate a table, you’re generating a REST API which then passes the request through to your scripts However, there is also a security layer there This security layer makes sure that you have the appropriate permission to make it through to the script layer This permission is something you can set for each individual operation against a table (so insert can be different from delete, etc) The first mode is “Everyone” this means you don’t need any additional checks to perform the operation, if the API endpoint is known, it can be called. The second is App Key, this is where you send over an app key as a header with each request. If you have it and it’s correct, you make it htrough. Note that this should only be used during the development stage because once your app is available, people can get access to the key The third option is Admin / Scripts. This is similar to app key in that you pass the master key over as a header. If you’re sending the master key over, you by pass both the App Key and the Authenticated user restriction we’ll talk about next Notes:
• #40: Slide Objectives: Review different authorization options for permissions on tables and custom APIs Transition: Let’s move into authentication and authorization Speaking Points: When you generate a table, you’re generating a REST API which then passes the request through to your scripts However, there is also a security layer there This security layer makes sure that you have the appropriate permission to make it through to the script layer This permission is something you can set for each individual operation against a table (so insert can be different from delete, etc) The first mode is “Everyone” this means you don’t need any additional checks to perform the operation, if the API endpoint is known, it can be called. The second is App Key, this is where you send over an app key as a header with each request. If you have it and it’s correct, you make it htrough. Note that this should only be used during the development stage because once your app is available, people can get access to the key The third option is Admin / Scripts. This is similar to app key in that you pass the master key over as a header. If you’re sending the master key over, you by pass both the App Key and the Authenticated user restriction we’ll talk about next Notes:
• #48: Slide Objectives: Review different authorization options for permissions on tables and custom APIs Transition: Let’s move into authentication and authorization Speaking Points: When you generate a table, you’re generating a REST API which then passes the request through to your scripts However, there is also a security layer there This security layer makes sure that you have the appropriate permission to make it through to the script layer This permission is something you can set for each individual operation against a table (so insert can be different from delete, etc) The first mode is “Everyone” this means you don’t need any additional checks to perform the operation, if the API endpoint is known, it can be called. The second is App Key, this is where you send over an app key as a header with each request. If you have it and it’s correct, you make it htrough. Note that this should only be used during the development stage because once your app is available, people can get access to the key The third option is Admin / Scripts. This is similar to app key in that you pass the master key over as a header. If you’re sending the master key over, you by pass both the App Key and the Authenticated user restriction we’ll talk about next Notes:
• #49: Demo3
• #56: Demo4
• #63: Demo5
• #67: Demo6 - SignalR
• #69: Slide Objectives: Review Script Source Control, Shared Scripts, and NPM support Demo: Script: http://www.windowsazure.com/en-us/develop/mobile/tutorials/store-scripts-in-source-control/ Transition: When Mobile Services was launched, you were limited to editing scripts in the portal and using only the modules we made available Speaking Points: Thankfully now, we’ve opened things up so you can do so much more. Script source control allows you to: Create a Git repo where you can pull and push your table, scheduler, custom API scripts and permissions Enables you to work on your scripts locally and push them to your Mobile Service Shared Scripts enable you to: Put functionality you need in several places into a single script which you then mark as exported You can then require these scripts from your table, scheduler, and custom API scripts Just like creating an NPM module NPM support allows you to install from the vast array of NPM modules publicly available and then use from your other scripts Notes:
• #71: Manual clone