# request-response-robert-ross
Source: https://speakeasy.com/blog/request-response-robert-ross


import { NewsletterSignUp, PodcastPlayer, YouTube } from "@/lib/mdx/components";

<YouTube videoId="8KbrFvxFqf8" />

On the second episode of Request // Response, I speak with [Robert Ross](https://www.linkedin.com/in/bobby-tables/), CEO of [FireHydrant](https://firehydrant.com/).

We discussed his journey building FireHydrant, the evolution of API design, and the impact of gRPC and REST on developer experience. We also talked about the role of LLMs in API design, the shift towards data consumption trends in enterprises, and how great developer experience is measured by a simple litmus test.

### Listen on

[Apple Podcasts](https://podcasts.apple.com/us/podcast/request-response/id1801805306?i=1000698928724) | [Spotify](https://open.spotify.com/episode/0OZRnw1dUfFydxQt9tnTqg?si=llkwy5XBRMWkPtidMOfVJQ)

<PodcastPlayer
  title="Request // Response Episode 2: coding on airplanes, and the true signal of good DevEx"
  id="5c578535"
/>

<NewsletterSignUp />

## **Show Notes:**

[00:00:00] **Introduction**

- Overview of discussion topics: building FireHydrant, gRPC, API design trends, and LLMs in APIs

[00:00:42] **The Story Behind FireHydrant**

- Robert's background in on-call engineering and why he built FireHydrant
- The problem of incidents and automation gaps in on-call engineering

[00:02:16] **APIs at FireHydrant**

- FireHydrant's API-first architecture from day one
- Moving away from Rails controllers to a JavaScript frontend with API calls
- Today, over 350 public API endpoints power FireHydrant's frontend and customer integrations

[00:03:50] **Why gRPC?**

- Initial adoption of gRPC for contract-based APIs
- Evolution to a REST-based JSON API but with lessons from protocol buffers
- Would Robert choose gRPC today? His thoughts on API design best practices

[00:06:40] **Design-First API Development**

- The advantages of Protocol Buffers over OpenAPI for API design
- How API-first development improves collaboration and review
- Challenges with OpenAPI's verbosity vs. Protobuf's simplicity

[00:08:23] **Enterprise API Consumption Trends**

- Shift from data-push models to API-first data pulls
- Companies scraping API every 5 minutes vs. traditional data lake ingestion
- FireHydrant's most popular API endpoint: Get Incidents API

[00:10:11] **Evolving Data Exposure in APIs**

- Considering webhooks and real-time data streams for API consumers
- Internal FireHydrant Pub/Sub architecture
- Future vision: "Firehose for FireHydrant" (real-time streaming API)

[00:12:02] **Measuring API Success (KPIs & Metrics)**

- Time to first byte (TTFB) as a key metric
- API reliability: retry rates, latency tracking, and avoiding thundering herd issues
- The challenge of maintaining six years of stable API structure

[00:17:12] **API Ergonomics & Developer Experience**

- Why Jira's API is one of the worst to integrate with
- The importance of API usability for long-term adoption
- Companies with great API design (e.g., Linear)

[00:18:14] **LLMs and API Design**

- How LLMs help in API design validation
- Are LLMs changing API consumption patterns?
- Rethinking API naming conventions for AI agents

[00:22:02] **Future of API Ergonomics for AI & Agents**

- Will there be separate APIs for humans vs. AI agents?
- How agentic systems influence API structures
- The need for context-rich naming conventions in APIs

[00:24:02] **What Defines Great Developer Experience?**

- The true test of developer experience: Can you be productive on an airplane?
- Importance of great error messages and intuitive API design
- The shift towards zero-docs, self-explanatory APIs

### More Robert Ross Quotes From The Discussion

1. **Enterprise Data Teams are Now More Receptive to APIs**

"I think more and more people are willing to pull data from your API. There used to be kind of a requirement many years ago of like, you need to push data to me, into my data lake. And the problem with that is, sure, we can push data all day long, but it may not be in the format you want. It may not be frequent enough. Like, you might have stale data if we're doing, a nightly push to our customers' data lakes."

2. **On LLMs and API Design**

"I don't think that LLMs are going to fundamentally change how we interact with APIs. At least not in the short term. I think that they'll help us build better clients and I think they'll help us build better APIs, but the moment we start using them, I mean, that's just going to be code calling code."

3. **The Airplane Test for Developer Experience**

"When it comes to developer experience, I think that my guiding principle is like, is it easy? Like, how far can I get before I have to read documentation? And I think that includes like great error messages, like, if I can do something on an airplane with really crappy wifi and like be productive, that's great developer experience."

### Referenced

- [FireHydrant | The end-to-end incident management platform](https://firehydrant.com/)
- [Linear API docs](https://linear.app/docs/api-and-webhooks)
- [Offset's Materialize RBAC system](https://materialize.com/docs/manage/access-control/rbac/)
- [Speakeasy's Terraform generator](https://www.speakeasy.com/docs/create-terraform)

Production by [Shapeshift](https://shapeshift.so).

For inquiries about guesting on Request // Response, email [samantha.wen@speakeasy.com](mailto:samantha.wen@speakeasy.com).