))
Share
R
Request // Response
1 Anthropic MCP, GraphQL vs REST, and API strategies for LLM dev tools | Ken Rose (CTO & co-founder OpsLevel) 27:33
27:33 
Play Later 
Play Later 
Lists 
Like 
Liked27:33
Play Later Play Later Lists Like LikedKen Rose is the CTO and co-founder of OpsLevel. Ken shares the founding journey of OpsLevel and lessons from his time at PagerDuty and Shopify. We debate GraphQL vs REST, API metrics that matter, and how LLMs and agentic workflows could reshape developer productivity. Listen On Apple Podcasts | Spotify Subscribe to Request // Response If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at https://speakeasy.com/post/request-response-ken-rose Show Notes [00:01:08] What OpsLevel does and why internal developer portals matter [00:01:51] Ken’s journey from PagerDuty to Shopify and to starting OpsLevel [00:04:03] Developer empathy, platform engineering, and founding OpsLevel [00:05:02] OpsLevel’s API-first approach and extensibility focus [00:06:26] Using GraphQL at scale—Shopify's journey and lessons [00:08:30] Managing GraphQL performance and versioning [00:10:12] GraphQL vs REST – developer expectations and real-world tradeoffs [00:11:27] Key metrics to track in API platforms [00:12:50] Why not every feature should have an API—and how to decide [00:13:48] Advice for API teams launching today [00:14:44] API consistency and avoiding Conway’s Law [00:15:50] Agentic APIs, LLMs, and the challenge of semantic understanding [00:18:48] Why LLM-driven API interaction isn’t quite magic—yet [00:20:00] Internal APIs as the next frontier for LLM productivity [00:21:43] 5x–10x improvements in DX via LLMs + internal API visibility [00:23:00] API consolidation, discoverability, and LLM-powered developer tools [00:23:54] What great developer experience (DevEx) actually looks like More Quotes From The Discussion Challenges of Running GraphQL "I can tell you as OpsLevel, running a GraphQL API, you know, all the usual things, making sure that like you don't have n+1 queries, ensuring, you don't get per resource rate limiting like you do with REST... You have to kind of be more intentional about things like query complexity. Those are challenges you end up having to solve. Versioning is another big one. We are far enough along in our journey. We haven't done a major version bump yet. I know a few years ago, after I left Shopify, they switched their GraphQL schema to be versioned and now they have much more kind of program management around like every six months they have a new major version bump. They require clients to migrate to the latest version, but that's effort and that's calories that you have to spend in that kind of API program management." DevEx of REST vs GraphQL "We have a customer that has been with us for years, but our champion there hates GraphQL. Like he really hates it. And the first time he told me that I actually thought he was like, you know, joking or being sarcastic. No. He was legitimate and serious because from his perspective, he has a certain workflow he's trying to accomplish, like a "Guys, I just need a list of services. Why can't I just like REST, even make a REST call and fetch last services and that's it. Why do I have to do all this stuff and build up a query and pass in this particular print?" And I get that frustration for developers that, you know, REST is sort of easier to start. It's easier just to create a curl request and be done with it, right? It's easier to pipe, the output of a REST call, which is generally just a nice JSON up into whatever you want versus "No, you've actually have to define the schema and things change." I think GraphQL solves a certain set of problems, again, around over fetching and if you have a variety of different clients. But there is this attractive part of REST, which is "I just made a single API call the single endpoint to get the one thing I needed, and that was it." And if your use case is that, then the complexity of GraphQL can really be overwhelming." API Consistency and Conway's Law "I do think consistency is an important thing, especially when you're dealing with a large company that has disparate parts working on different aspects of the API. You don't want Conway's Law to appear in your API—you know, where you can see the organizational structure reflected in how the API is shipped. So making sure that an API platform team or someone is providing guidance on how your organization thinks about the shape of APIs is crucial. Here's how you should structure requests. Here's how you should name parameters. Here's what response formats should look like. Here's consistent context for returns and responses. Here's how to implement pagination. It's all about ensuring consistency because the most frustrating thing as an API client is when you hit one endpoint and it works a certain way, then you hit another endpoint and wonder, 'Why is this structured differently? Why does this feel different?' That can be tremendously difficult. So having some guardrails or mechanisms to ensure consistency across an API surface area is really valuable." Referenced - OpsLevel (https://opslevel.com/) - Shopify Storefront API (https://shopify.dev/docs/api/storefront) - GraphQL (https://graphql.org/) - REST (https://restfulapi.net/) - Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law) RED Metrics (https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/) - Anthropic MCP (https://www.anthropic.com/news/model-context-protocol) - Agents.js (https://huggingface.co/blog/agents-js) Production by Shapeshift | https://shapeshift.so For inquiries about guesting on Request // Response, email samantha.wen@speakeasy.com.…
