Putting Kit back in SDK
- 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
- 5. Let’s code!
- 6. Putting Kit back in SDK @Darrel_Miller
- 7. How do you feel about SDKs for APIs? This Photo by Unknown Author is licensed under CC BY-SA-NC
- 8. Do they make you feel like this? This Photo by Unknown Author is licensed under CC BY-NC-ND
- 9. TTFC This Photo by Unknown Author is licensed under CC BY-SA
- 10. Made by a machine This Photo by Unknown Author is licensed under CC BY-SA
- 11. This is what we need
- 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
- 13. Middleware magic This Photo by Unknown Author is licensed under CC BY
- 15. Request vs Content This Photo by Unknown Author is licensed under CC BY-NC-ND
- 17. Content is composable This Photo by Unknown Author is licensed under CC BY
- 19. Tasks – Higher order functions This Photo by Unknown Author is licensed under CC BY-NC-ND
- 20. SomeTask Current State Http Client API Request Respons e Input Parameters State Change Event Action
- 21. PageIterator Task let somePagedCollection: PageCollection = await client.api("/me/messages").get(); let callback: PageIteratorCallback = (data) => { console.log(data); return true; }; let pageIterator = new PageIterator(client, somePagedCollection, callback); pageIterator.iterate();
- 22. Response Handler This Photo by Unknown Author is licensed under CC BY-NC
- 23. Response Machine Applicatio n State DispatcherAPI Respons e Response Callback Response Callback Response CallbackResponse Callback Status, Content- Type, Link Relation
- 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
- #2: 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.
- #3: 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.
- #4: “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
- #5: 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.
- #7: 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.
- #8: 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.
- #9: 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
- #10: 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.
- #11: 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.
- #12: 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
- #16: Request and content can be independent Request is packaging The content could be anything
- #17: Decoupling Request from Content Current implementations make it difficult to deal with common graph contents independently of the requests This makes reuse harder.
- #19: 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
- #20: 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.
- #21: 33mins 35mins
- #22: 37mins Return false stops the iteration. Resume iteration. Transform PageSize helpers? 39mins
- #23: 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.
- #24: 33mins Support for scenarios where a coordinated set of HTTP requests achieve a well known goal. 35mins