Download to read offline
![mutation newArticle {
createArticle(
article: {
slug: “Riverbank flood…",
title: "Seine Highest",
status: live,
relatedArticles: [
{ id: 12345 },
{ id: 56789 }
]
})
}
Document
Store
Relationship
Store](https://image.slidesharecdn.com/gjonesapimeetup-180525181750/85/Graph-API-Strategies-CQRS-for-the-API-Economy-11-320.jpg)
Uploaded byGareth Jones
Graph API Strategies: CQRS for the API Economy
This document summarizes Gareth Jones' presentation on Graph API strategies. It discusses using CQRS and Graph APIs to enable self-service and sustain API velocity. Three Graph API approaches are mentioned: GraphQL, OData, and JSONAPI.org. CQRS with a document store and relationship store is presented as a way to separate commands and queries for API sustainability.
More Related Content
Similar to Graph API Strategies: CQRS for the API Economy
![Jorge de la Cruz [Veeam Software] | RESTful API – How to Consume, Extract, St...](https://cdn.slidesharecdn.com/ss_thumbnails/jorgeslides-201026172621-thumbnail.jpg?width=640&height=640&fit=bounds)
Graph API Strategies: CQRS for the API Economy
- 1. Graph API strategies CQRSfor the sustainable API Economy APIs and IPAs Meetup May 2018 Gareth Jones Principal API Architect @garethj_msft This Photo by Unknown Author is licensed under CC BY-SA
- 2. This Photo byUnknown Author is licensed under CC BY-NC-SA
- 3. Self-service => Businesssea change
- 4. Sustain velocity This Photoby Unknown Author is licensed under CC BY-NC-ND
- 5. You need tomake change ITSELF self-service. @garethj_msft
- 6. Mobile Apps demanddata THEIR way
- 8. Traversing links answersquestions What photos were taken recently by my favorite photographers? Which colleagues have recently created documents? All without adding new API surface. Relationships enable self-service This Photo by Unknown Author is licensed under CC BY-NC-SA
- 9. 3 Graph API Approaches 1.GraphQL 2. OData 3. JSONAPI.org
- 10. Take Graphs ANDREST into the shower? This Photo by Unknown Author is licensed under CC BY-NC
- 11. mutation newArticle { createArticle( article:{ slug: “Riverbank flood…", title: "Seine Highest", status: live, relatedArticles: [ { id: 12345 }, { id: 56789 } ] }) } Document Store Relationship Store
- 12. Command and QueryResponsibility Segregation Blog.codecentric.de
- 13. Sustainability Don’t fear Graph APIs ThisPhoto by Unknown Author is licensed under CC BY-NC-SA
- 14.
Editor's Notes
- #2 Good afternoon, my name is Gareth Jones, and I’ve been with Microsoft for twenty years now, working on APIs for about the last 5 or six. I spent a couple of years as an architect for the Microsoft Graph in the core team, and more recently in our Education team focusing on building a platform on the Graph for app-builders targeting the classroom. I’d like to take this brief twenty minutes or so to pitch an architectural style I believe can help us sustain the momentum of the API economy.
- #3 So let me start with a question to you? What do you consider were they key drivers of the first wave of the API Economy? Anyone?
- #4 IN my view, the key driver was SELF-SERVICE. Integrations between systems were suddenly cost-effective because they didn't require a complex business relationship and a large systems integration project. Instead they were largely self-service due to published APIs - internal or external. This generated wonderful moments of business value to cost ratio.
- #5 But this only gets the initial version of a project delivered. What happens when requirements change and more is needed from APIs we’ve consumed? Suddenly we are thrown back into the world of needing that deeper business relationship, as we need to ask our API supplier for additions. We’re back into an old-school project style and the velocity that characterized the API economy is at risk.
- #6 In my opinion, the thing that will power a second wave of the API economy and keep our momentum going is if we can do for change what we did for project initiation. You need to make change ITSELF self-service. Where does most change come from today? It's either adding new pieces - a new value here or a new resource there. Any decent versioning policy can handle that. And that often tends to be driven from the provider side.
- #7 Or it's reshaping requests and remixing the resources required. We see this mostly in the explosion of mobile apps. Most people building mobile apps are super-sensitive to the number of round trips to create the experience. Whether because of performance, or network reliability, getting things down to the holy grail of a single round trip to your service is always the goal.
- #8 Fundamentally, graph-shaped APIs ENABLE data-shaping in one round trip by PREDEFINING RELATONSHIPS between resources. This example happens to be a part of the relationship set for the Microsoft Education Graph API that I work on. Many REST proponents worry that from an evolvability perspective, predefined relationships are constraining, but core relationships really don’t change. People have jobs and parents and contact lists and teachers. These things don’t radically change. Of course it depends on your domain.
- #9 But those relationships really enable self-service queries well beyond the scenarios you originally envisioned when designing your API.
- #10 When I say Graph APIs, many of you might be thinking only about GraphQL, as tis had so much buzz lately, but don’t fall into that trap. There are at least three viable Graph API implementation techs with realistic stacks behind them, and indeed OData and JSONAPI are already hybrid REST/Graph approaches, so in many ways, GraphQL is the least sophisticated, despite its popularity. But why does this matter? Given my claim that supporting self-service change is critical, why does REST matter? Shouldn’t being able to work purely with the Graph be sufficient?
- #11 Graphs are really great for querying. You can see what customers use cases are over time and optimize with the right level of prequerying and caching. You can throttle where your system would find a query hard to serve. BUT, and it is a big BUT – updates are simply trickier to deal with.
- #12 When we allow updating via a Graph, we create an impression that the Graph surface is a resource instead of a spanning query. In most real-world systems, interesting graph queries span multiple back-end systems. User tables mixed with transactions. Document stores mixed with comment stores or link stores. Updates across those stores are unlikely to behave atomically. Behavior for partial success is difficult to define if the client is not involved in the logic. Usually REST just works better. Hang on, we’ve seen this architecture before.
- #13 A few years ago, CQRS-based architectures were all the rage. Essentially it’s a codification of extreme separation of responsibilities. Using a different pipeline for read than for updates and highly optimizing both.
- #14 So here’s my call to action: Don’t be afraid of Graph APIs. Use them to give your customers flexibility and enable self-service change. If you don’t need that, probably they won’t help you. But if you do, don’t feel like they will constrain your ability to evolve your API.