3. One Microsoft
Becoming One Microsoft isn’t the beginning, nor is
it the end. It’s something we should be moving
toward every single day.
4. Microsoft Graph
Gateway to your data in the Microsoft-cloud
Users, Groups, Organizations
Outlook
SharePoint
OneDrive
Teams
Planner
Excel
OneNote
Activities
Device Relay
Commands
Notifications
Azure AD
Intune
Identity Manager
Advanced Threat Analytics
Advanced Threat Protection
Mail, Calendar,
Contacts and Tasks
Sites and Lists
Drives and Files
Channels, Messages
Tasks and Plans
Spreadsheets
Notes, and more…
Identity Management
Access Control
Synchronization
Domains
Administrative Units
Applications and Devices
Advanced Threat Analytics
Advanced Threat Protection
Alerts
Policies
and more…
Office 365 Windows 10 Enterprise Mobility + Security
https://graph.microsoft.com
Dynamics 365
12. Kit Components
Client
Factory
Request
Builder
Response
Handler
HTTP
Interface
Request Response
Middleware
HTTP
Handler
Service
Client
Core Library
Native Library
API Models
Common
Content
Generated Library
Tasks
Workflow
Support for scenarios
where a coordinated set
of HTTP requests achieve
a common goal
Services types for
simplified payload
handling
Handling standard
response codes and
deserialization of payloads
Components for
applying cross
cutting concerns
Common container
models for collections,
paging, batch, Multi-part
Provide discovery
mechanism for
resources and
parameters
Provide simple,
language native,
interface for
common use cases
Create native client library
with desired configuration
and middleware
24. • Generated code is only a small part of SDKs
• SDKs can and should add value all
developers
• Don’t throw away the HTTP model
This Photo by Unknown Author is licensed under CC BY-NC-ND
Editor's Notes
Vincent provide great overview of possibilities
Before we get into some technical details
Let’s talk about a softer side of Microsoft Graph for a minute
I think It’s important.
Who remembers this cartoon from Manu Cornet
Various major companies were compared from an organization or cultural perspective
Having Microsoft operate as many competing smaller orgs obviously worked for many years
But for a variety of reasons it wasn’t working any more.
When Satya Nadella became CEO, he started a major cultural shift.
“One Microsoft” was one of those completely new cultural goals.
Microsoft’s employees are rewarded for cooperating with other teams.
I was Microsoft partner and ISV for many years and it drove me nuts the mixed messages
I would get from different teams.
One Microsoft is giving the ability to teams to speak with a consistent message.
Which brings us to Microsoft Graph
Let’s take a look at this familiar slide but from a different perspective
Rajesh E&D
Windows/UST
BAG/James Phillips
Azure AD (owners of Graph proxy and part of DevX)
Brad Anderson
C+E Security
Not only are the core Graph team split across divisions, but all of the major groups in the company are represented.
Microsoft Graph is an actual realization of One Microsoft. This is not a product from a product group.
This is the Microsoft Graph.
My name is Darrel Miller
Here’s my twitter handle
I work for Microsoft as a Product Manager on the Microsoft Graph developer experience.
Today I am going to talk about SDKs, or client libraries for HTTP APIs.
People either love them or hate them
Even API providers who hate them, know that they need to build them.
Because some customers demand them.
I’ve never liked them.
I’ve spent years trying figure out how to build them in a way I would like them.
When I got the chance at Microsoft to make SDKs the way I think they should be done, I jumped at it.
This is how some people feel about SDKs
They feel limited. Constrained.
There’s no flexibility,
Because they are designed primarily for a single use case
TTFC
Getting people started is essential
Showing how simple and easy it is to get stuff done is critical.
Designing for flexibility brings complexity so it is avoided.
And then there is the other challenge with SDKs.
Multiple languages mean code-generation.
Code generation is a double edged sword
It can make somethings easy, but it also makes it easy to make poorly architected code.
Supporting cross platform often means only supporting the lowest common denominator features
There are SDK code generators out there, and some folks assume creating SDKs is minimal effort task.
But the end result is often poor, with limited flexibility.
It’s often “use it all” or use “none of it”, which is why many people choose not to use them.
What we need is a real kit. So we can pick and choose the parts we want to use.
The new users can get the fully streamlined, easy approach.
The folks building products can get under the covers and use just the parts they want.
The parts they don’t want to have to build themselves.
Users need to have choices.
What we are going to look at next the approach we are taking on the Microsoft Graph team to make our SDKs better for all
Request and content can be independent
Request is packaging
The content could be anything
Decoupling Request from Content
Current implementations make it difficult to deal with common graph contents independently of the requests
This makes reuse harder.
27mins
An extra comment about this notion of HTTP content.
This was not our creation.
This follows the pattern designed by Henrik Frystk Neilsen, an author of the HTTP/1.1 specification who was an architect on the HTTP Client library for .NET framework
This model allows content objects to be composable.
It enables Content objects to contribute headers to request/response
And maybe even one day provide Trailer headers.
30mins
Cruise control lets you set the speed and pressing the accelerator and brake is done for you.
Support for scenarios where a coordinated set of HTTP requests achieve a well known goal.
Response code is often inline
However, in reality for HTTP calls they are callbacks
Even though they may look like they are inline
ResponseHandler is about centralizing those callbacks into a response machine.
33mins
Support for scenarios where a coordinated set of HTTP requests achieve a well known goal.
35mins