Skip to main content

Integration Style Clinic

Retrieval Prompts

  1. Name one strength and one weakness of each: REST, gRPC, GraphQL, event-driven.
  2. What is the N+1 problem in GraphQL, and what is the standard mitigation?
  3. What is the canonical envelope for a CloudEvents-style event?
  4. Why does gRPC's binary wire format matter less than its .proto-based contract?
  5. When does a webhook consumer need to dedupe, and how?

Compare and Distinguish

Separate these pairs cleanly:

  • REST vs gRPC for an internal service-to-service integration
  • REST vs GraphQL for a browser dashboard pulling from 5 backends
  • Webhooks vs broker events for third-party integrations
  • JSON-RPC vs REST for a small, focused internal admin API
  • Subscriptions (GraphQL) vs webhooks vs server-sent events vs Kafka topics - what are the consumer profiles?

Common Mistake Check

Identify the error or risk in each:

  1. "We're using GraphQL so clients can request only the fields they need - we don't need rate limits."
  2. "Our internal service has 4 methods; we're using gRPC so we get types."
  3. "Webhooks are fire-and-forget; if the consumer is down that's their problem."
  4. "Event schemas don't need versioning because consumers just ignore unknown fields."
  5. "REST is always the right default for a public API." (Is it? When not?)
  6. "gRPC over the public internet is fine - we'll just add grpc-web at the edge."

Mini Application

You are designing integration for a new feature: a third-party vendor needs to receive order events from your system, and your iOS app needs to render an "order detail" screen that shows order + customer + shipping address + the last three statuses.

Write a 2-page memo covering:

  1. Vendor integration (third-party, push): propose REST polling, webhooks, or event bus. Defend.
  2. iOS detail screen: propose REST with composite endpoint, GraphQL, or multiple REST calls. Defend.
  3. Internal order service + inventory service: REST or gRPC? Defend.
  4. A table listing your three decisions and the one attribute that drove each (latency, typing, ecosystem, operational cost, etc.).

Include at least one trade-off you deliberately accepted in each decision.

Design and Defend Kata

Take any public REST API (Stripe, GitHub, Slack). Pick one endpoint and describe:

  1. how it would look as gRPC (write the method + messages)
  2. how it would look as GraphQL (write the types + query)
  3. how the same operation would look as an event (name and payload)
  4. which style you would actually ship as the primary surface, and why

Practice this until the restatement takes under 30 minutes.

Evidence Check

This page is complete only if, given an integration description, you can:

  • pick a style in under 10 minutes with a defensible justification
  • name what the style is bad at as well as what it is good at
  • write at least one concrete schema in the chosen style
  • identify the operational investment required to actually run it (DataLoader for GraphQL, code generation for gRPC, dedupe infrastructure for webhooks, etc.)