# Transcript
Source: https://speakeasy.com/blog/request-response-ken-rose

import { NewsletterSignUp } from "@/components/newsletter-signup";
import { PodcastCard, PodcastPlayer } from "@/components/podcast";
import { kenRoseEpisode } from "@/lib/data/request-response";

<div className="max-w-4xl mx-auto my-8">

[Ken Rose](https://www.linkedin.com/in/klprose/) is the CTO and co-founder of [OpsLevel](https://opslevel.com/).

In this episode, Ken shares the founding journey of OpsLevel and lessons from his time at PagerDuty and Shopify. We discuss:

- GraphQL vs REST
- The API metrics that matter
- How LLMs and agentic workflows could reshape developer productivity.

### Listen on

[Apple Podcasts](https://podcasts.apple.com/us/podcast/anthropic-mcp-graphql-vs-rest-and-api-strategies-for/id1801805306?i=1000703080125) | [Spotify](https://open.spotify.com/episode/3gDRkAk1rq0Y4f1PFNL51y?si=_aRaEq7cSlGZ1kZBhWLByw)

<PodcastPlayer
  title="Request // Response Episode 3: Anthropic MCP, GraphQL vs REST, and LLM API strategies"
  id="a04f4bc3"
/>

</div>

<PodcastCard {...kenRoseEpisode} />

<NewsletterSignUp />

## **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://web.archive.org/web/20250908222822/http://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](mailto:samantha.wen@speakeasy.com).



## Introduction

[00:00:05] **Nolan**: Hey guys, this is Nolan. I do developer relations at Speakeasy. Thanks so much for taking the time to listen to the podcast. This is a new format for us and we're actively looking to get feedback from the community. Would love if you guys could drop us an email, you can email me, nolan@speakeasy.com, or our producer Ira, ira@speakeasy.com.

[00:00:23] If you're enjoying the content, don't forget to sign up below, drop us your email, and you'll be the first to hear about new guests that are coming on. Get episodes straight to your inbox as soon as they release. Thanks so much for listening and enjoy the rest of the episode.

## Welcome and OpsLevel Introduction

[00:00:34] **Sagar Batchu**: Hey everyone. Welcome to another episode of Request and Response. I'm your host, Sagar, co-founder, CEO of Speakeasy. I'm joined today with Ken Rose, CTO, and co-founder of OpsLevel. Ken, how are you doing today?

[00:00:47] **Ken Rose**: I am doing great. Thank you. Thanks for having me on the show.

[00:00:49] **Sagar Batchu**: Absolutely. I hear you're a pro at doing podcasts, so really I think we should swap places here.

[00:00:55] **Ken Rose**: It's definitely new for me to be in the guest seat. It's been a while. Normally I'm the host, but yeah, it's fun to be on this side of the aisle today.

[00:01:01] **Sagar Batchu**: That's awesome. Yeah. Cool. To kick things off, I would love for you to share a bit more about OpsLevel and what you guys do.

[00:01:08] **Ken Rose**: Yeah, definitely. So at OpsLevel, we make a product called an internal developer portal. And really this is a tool that helps engineering teams manage the complexity of really large software environments. And we help consolidate a bunch of the context from various tools that sort of exist out there across the building of software, the deployment of software, the management of software and production into a single, consolidated place so that engineering teams can ship more reliably and more securely.

## The Journey to OpsLevel

[00:01:35] **Sagar Batchu**: That's amazing. It honestly sounds like a product I know a lot of our customers would be interested in. I've worked at a few companies where building out like this single pane of glass is such a tough thing to do at scale. So it sounds like you're solving a real problem. How did you come to working on this problem? What's your journey to OpsLevel?

[00:01:51] **Ken Rose**: Yeah, it actually begins, oh man, like more than 12 years ago now. My co-founder, John, was the first employee at PagerDuty, right? The kind of, you know, big incident management company. And I was considering being their first Canadian employee. I was, I'm based here in Toronto, and at the time, again, it's 12 years ago now. It was like, actually I wanna go start a startup. I really wanted to start my own company and do my own thing.

And I tried something in like real estate and it didn't really go anywhere. And then I was like, you know, kind of went back from my tail between my legs "yeah, John, is that job offer still there?"

[00:02:19] I thought, you know, go back to PagerDuty. I worked for a year and then try again. Oh, that one year turned to four and John and I became really, you know, good friends and yeah, kind of like that seed was always there. And so I ended up going to another company after PagerDuty. It's a small e-commerce company here in Canada called Shopify.

[00:02:35] And then I actually was on a parental leave. My daughter was born at the time and I kind of had that space to think about, what do I want in life? You know, what's next? And that entrepreneurship bug was kind of still there. And so John also had a similar kind of fire brewing in his belly, and he reached out and we started, you know, getting to talking.

[00:02:52] And we had the, you know, the kind of list of all the possible startup ideas where a big list of 50 things, but whittled it down to two. And so one of them was a better applicant tracking system. So John and I had both done as engineering leaders, just a lot of interviews with engineering candidates.

[00:03:05] I won't name which tool we use, but it wasn't very good. It's still around, so I don't wanna name them. But we're like, okay, we can build something better here. But in doing a lot of discovery, we realized the buyer for that is gonna be HR people. And I love my HR VP, but I wasn't sure if I wanted to commit 10 years to working with that person or that persona.

[00:03:21] And the other idea was something in and around OpsLevel, and we had seen this idea of cataloging your services, building internal tooling to help development teams move more efficiently. We had seen that problem being solved internally as an internal tool at just a variety of organizations. We talked to Spotify before they'd open source Backstage, Shopify had their own version, LinkedIn, Microsoft, Groupon, like all these companies had basically reinvented the wheel, solving the same problem.

[00:03:45] And the thing we also love was the personas just it's other developers, it's other folks that were like John and myself. It's developers, it's platform engineering leaders. It's engineering leadership at large. That's my jam. I just, I love those folks, right? I, that's the area I live in. The amount of empathy I have for that, the set of problems that those groups have is huge.

[00:04:03] So that was just, it was a very natural pull. And you know, we're really fortunate years later, our, you know, company's still thriving, growing, adding on new customers, and just really lucky to be able to kind of found lightning in a bottle and being able to build this great product for all of our customers.

## APIs and OpsLevel

[00:04:16] **Sagar Batchu**: That's amazing. I can resonate with so much of that story to be honest, that platform engineering is something I nerd out on so much. It honestly is that core part of many tech businesses today that is kind of silent hero in the background, giving the rest of the company velocity and the ability to create amazing products.

[00:04:35] The internal API and just more overall problem that OpsLevel is solving is not too far from actually why we started Speakeasy and wanting to kind of go after and bring consistency and governance and really, you know, just sanity to API development. I honestly feel like OpsLevel is, yeah would be something I could have used at any of the past companies I worked at, so that's really amazing.

[00:04:57] Does OpsLevel have an API or how do APIs kind of fit into the OpsLevel story?

[00:05:02] **Ken Rose**: Yeah, no we have a large API, in fact so before starting OpsLevel years ago, again, when I was at PagerDuty, I was responsible, I as the sort of technical lead for their API. And then when I moved over to Shopify, I was the lead for their GraphQL API. Shopify has, as you know, massive API. Also, they had this API patterns team that was responsible for shepherding a lot of the shape of the API and was responsible for those kind of cross-cutting API concerns.

[00:05:25] For our API, we are very much like an API driven company. If you think about what goes into an internal developer portal, there's an aspect of a software catalog. There is aspects of standardization, there's aspects of developer self-service. There's a ton of automation that has to go into driving each of those pillars.

[00:05:44] And the only way to achieve that automation is through an API. So pretty much everything we build as part of our platform strategy, we need to be API first because we really wanna be able to solve a large percentage of our customer's problems, you know, as a product, but there's always gonna be some long tail that we won't be able to solve directly, right?

[00:06:01] Our scrappy team of product dev folks. And so for that, we need our APIs to be allowing for extensibility allowing for customization so that our customers can self-serve themselves. So, if there's some tool we don't support, if there is some particular workflow that like, makes sense maybe for one customer, but not for our base at large, we wanna make sure that our APIs are present and there to be able to do that.

[00:06:20] So that means that pretty much everything, and it's a very broad product suite that you can do through the UI. There has to be an API for as well.

## GraphQL vs REST: The Shopify Experience

[00:06:26] **Sagar Batchu**: That's fantastic. Going back to really cool that you worked at Shopify during, I think such an amazing time there. One thing that stands out to me as an API developer, Shopify always got a lot of attention for being a company that actually used the GraphQL API externally with their customers.

[00:06:42] And I thought it was really cool to see that hot new technology actually go to scale and be used publicly. I feel like since then maybe this is a hot take, but since then, kind of the popularity on GraphQL, especially for external use cases, has gone up and down. There's been a lot of debate around whether, you know, REST or GraphQL is the ultimate option.

[00:07:02] I know there's no true answer, but I'm curious if that ever came up at Shopify. Did your customers, were they ever surprised that they had to integrate with GraphQL?

[00:07:10] **Ken Rose**: So I mean, I can talk a little bit and, you know, there's history there, right? So I'm trying to remember this, like 2017, 2018, right? So I believe there was the marketplace API, and then there was the admin API. So I actually launched the admin API when I was there, right? It was Shopify has their marketplace API which was it marketplace or storefront? It might've been storefront, but it was like a smaller subset, APIs.

[00:07:31] And that was almost like the test bed for GraphQL at Shopify. And that proved valuable for, you know, things like all the usual benefits that GraphQL provides, right? Because GraphQL kind of came out in 2015 from Facebook. But you know, ensuring that there's no over fetching, ensuring better client experience.

[00:07:42] And so then there was this decision that they should migrate to their admin API, which is like the commerce API onto GraphQL. And the reasoning at a very high level is look, commerce is a graph. We had a very similar thesis when we started OpsLevel. We have a GraphQL API internally, because software development is a graph.

[00:07:59] There's teams, there's microservices, there's applications, there's this tapestry of stuff that's kind of all connected, right? So GraphQL kind of makes sense there. Back to whether or not developers were surprised, I mean I don't think anyone was surprised. 'cause you know, there's kind of enough lead up to the fact like, look, there was already this one API that was, you know, sort of using GraphQL.

[00:08:17] There was a lot of support. Shopify maintained backwards compatibility with their existing REST APIs for, you know, some period of time. So there was an overlap period to allow for that transition. Yeah, so, you know, I think overall it was like for Shopify and net positive, but it wasn't without a lot of the usual hiccups that people kind of encounter when they're dealing with GraphQL, right? Both as a client and as a company that provides it.

## GraphQL Implementation Challenges

[00:08:30] On our side, 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 plus one queries, ensuring, you know, 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, you know, challenges you have to end up having to solve. Versioning is another big one. You know, we are far enough along in our journey. We haven't done a major version bump yet.

[00:08:58] I know a few years ago, this was after I left Shopify based switched their GraphQL schema to be versioned and now they have much more kind of program management around like every, I think it's 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.

[00:09:15] **Sagar Batchu**: Yeah, that makes sense. I think that's really where the argument kind of goes astray. A lot of the times I think is people you know, compare GraphQL to REST and then immediately look at how they're used externally, but they don't realize the kind of practices that go behind running these two different kinds of APIs is vastly different.

[00:09:33] And I think you raised a really good point, like commerce is a graph and that shows like kind of your choice on GraphQL was rooted in a use case that made sense. And I think it always reminds us as developers like not to debate these things in the abstract. That is kind of a key use case behind why you might choose GraphQL, and I think Shopify just happened to be one of the first ones at scale with a very, very clear use case for it.

[00:09:57] **Ken Rose**: Yeah, it's funny. I agree with everything you just said and nevertheless, we have, you know, some customers, we deal with developers, right? And sometimes developers are prickly is, is maybe a way I would say describe it. So I know there's one customer I think about in particular, I love them. They're, a fantastic customer.

[00:10:12] They've been a customer of us for years, but our champion there is he 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, like he, you know, 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 for, you know, 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 the complexity of GraphQL can really be overwhelming.

## Measuring API Success

[00:11:05] **Sagar Batchu**: Totally. Yeah. There's like an enhanced simplicity in just exposing your API one resource per, you know, business object or business use case that you want your customers to take advantage of. Yeah I totally resonate with that. You know, just on that API point again, what were some of the metrics you all looked at when you were running these APIs at scale, at Shopify, or even now at OpsLevel?

[00:11:27] What metrics to you, do you think that an API team should measure?

[00:11:32] **Ken Rose**: Yeah. I mean, I probably would be more apt to talk about what we do at OpsLevel. 'cause that's just a lot more recent. I don't know what Shopify looks at, there's two classes, right? There's kinda just the operational metrics, like things like the RED metrics, right?

[00:11:44] Request errors, duration just understand like how is your API performing? For us it's looking at specific, you know, queries that are coming in and just understand like which ones are, you know, potentially non-performing or what are some areas we have to fix. We have things like, you know, N plus one detection to make sure that like we don't, you know, explode.

[00:12:00] The other kind of like qualitative one has been feature requests that we get around missing capability in our API. Like I did just finish saying earlier, you know, part of our platform strategy is this sort of Pareto principle. Like we wanna make sure that for problems that are, you know, in the box, like something that 80% of our customer base wants, that's something we should solve as a first class thing.

[00:12:20] We obviously will have API for it. But we always wanna make sure those APIs exist. 'cause if we don't solve for something, you know, there's an API to do it. That said, sometimes there are things that we will intentionally not have an API for. There's sometimes that's due to performance or sometimes it's, that's due to the UX is really meant to be more human centered.

[00:12:35] It's not really meant for like the machine to wanna ingest data or push data to do something with, but we do look at if we're getting requests for that, how does that translate to the fidelity then of what we're wanting to do with the API? It becomes sort of that backstop to justify yes, this decision we made to not put this in API maybe that was wrong.

[00:12:50] Or maybe our assumptions about like why we did that were actually correct. Because now we're getting some input that like, oh, here's some new use case where they do wanna use API for this particular thing.

[00:12:57] **Sagar Batchu**: I love that framing because I see a lot of times with companies, they kind of expose a very large API, but then most of the traffic will be on like two endpoints, so one endpoint, and so they don't really have an understanding of which parts of the API actually getting used. And so they've actually exposed a huge part of the API and created a massive dependency for their customers.

[00:13:18] And they move a lot slower as result because they have to update, you know, a hundred endpoints instead of just two, which is like where all the value is. So I love the kind of framing on metrics that you guys have. If, you know, I'm curious if someone is launching an API today and you had to give them like one or two top things to look for.

[00:13:36] What would you advise them on? This is something I see. It's so funny, I see this on LinkedIn all the time where there's like API product managers talking about this. They'll be like the top two or three metrics that an API team should look at. I don't know if you have a point of view on that.

## Key Advice for API Launches

[00:13:48] **Ken Rose**: Oh man. I mean, I think it depends a lot on the business and like the scale that API is gonna be hitting. Like I could talk about things in general. Like again, think about like your RED metrics, think about versioning of your API and how you're gonna manage deprecations. It's almost I like the term API product manager.

[00:14:02] It's put on your product management hat. What is the value of this API's providing? Why are your users using it? What are they trying to do? What problem are they trying to solve and how's your API help 'em accomplish that? Then just focus on that repeatedly and make it, you know, refine it until it's as simple as it could possibly be.

[00:14:15] I think that would be like the ultimate lesson. Everything else after that is just details in the pursuit of that goal.

[00:14:20] **Sagar Batchu**: Yeah, that makes a lot of sense. I think in some ways API platform teams sometimes have to wear that product manager hat for the API. Especially at at larger companies, you have each team ships a part of the API and gets packaged up as like a single library or a single documentation site.

[00:14:37] Unless you have that API platform team owning those metrics and wearing the product manager hat, you often don't get that thinking. So, yeah, that makes a lot of sense.

## API Consistency Across Organizations

[00:14:44] **Ken Rose**: There is actually one now that you mentioned the API platform team. I do think consistency is an important thing, especially when you are dealing, if you have a large company, you have disparate parts of the company working on different parts of the API. You don't want to have, is it Conway's Law that you can kind of, you know, you see the shipping of the, you don't want Conway's Law to appear in your API.

[00:15:01] So making sure that API platform team or someone is providing guidance on like here's how our organization thinks about the shape of APIs. Here's how you should think about structuring requests. Here's how you should name parameters. Here's what response format should look like. Here's consistent context of return and responses.

[00:15:14] Here's how to do a pagination. But it just ensuring that consistency because the most frustrating thing as a an API client is okay, I hit this REST, hit this one end point. It works this way. Hit this other point. Why is this structured differently? Like, why does this feel different? Yeah, that can be tremendously difficult.

[00:15:27] So just, you know, having some guardrails or mechanisms to ensure consistency across an API surface area. Also really valuable.

[00:15:34] **Sagar Batchu**: Yeah, absolutely. I think I'm so glad you brought up, it's like the number one thing that I see when I look at like an API, that's old, like a legacy spec, and since we deal with specs I look to the specs and I see I think I can literally draw the org structure by looking at that schema document and being like, "Hey these two are designed by one team, these two are designed by another team. And then this one was tacked on later, right?" Like this such a clear history evolution built into it. No I love that analogy.

## Frequently Asked Questions

### What is OpsLevel?

OpsLevel is an internal developer portal that helps engineering teams manage the complexity of large software environments.