11 - Advanced API Paradigms
This track is about everything past "just build a REST API." By the end of track 02 you could design a clean, validated, versioned, OpenAPI-documented REST API — and for most systems that is exactly the right tool. This track makes you fluent in the handful of cases where REST's defaults fight you, and in the alternatives that fit those cases: gRPC for fast, typed, internal service-to-service calls; GraphQL for rich frontends that need to pick their own data shape; the event/real-time options (webhooks, WebSockets, SSE) for server-initiated updates; and the edge components — API gateways and Backend-for-Frontend layers — that sit in front of it all. The recurring thesis: paradigms coexist, the consumer decides which one belongs at each edge, and every paradigm past REST must earn its complexity against a concrete pain.
How this track works
- It assumes you've finished track 02 (API Layer and Request Handling) — you're comfortable with FastAPI, request handlers, middleware, validation, versioning, and OpenAPI. Everything here is framed as "here's where REST strains and what to reach for instead," so that REST fluency is the baseline.
- Every module builds on the ones before it. The judgment established early — let the consumer decide the paradigm, don't add complexity before the pain exists, keep one domain behind many adapters — recurs in every later module and converges in the capstone. Go in order.
- Each standard module README has the same shape: why it matters, concepts, a
command reference with real Python (
.protofiles and gRPC stubs, Strawberry resolvers and DataLoaders, FastAPI edge code), progressive hands-on exercises (do them — including a "diagnose and fix" scenario each), an independent challenge with no code, common mistakes, and a checkpoint quiz. Modules 03 and 07 also carry a closed-book cumulative review. - Exercises build in Python with
grpcio/grpcio-tools(gRPC) and Strawberry on FastAPI (GraphQL), runnable locally. The real-time mechanics (webhooks, WebSockets, SSE, pub/sub) are cross-referenced to track 06, which owns them in depth — this track focuses on which mechanism to expose to which consumer, not on re-teaching them.
Modules
| # | Module | What you'll be able to do | Time |
|---|---|---|---|
| 00 | Beyond REST — when and why | Look at a requirement and name the paradigm — REST, gRPC, GraphQL, or events — using a consumer-first decision framework | 60-90 min |
| 01 | gRPC fundamentals | Define a service in a .proto, generate Python stubs, and make typed unary RPC calls with Protocol Buffers |
75-100 min |
| 02 | gRPC streaming and advanced patterns | Use server/client/bidi streaming, status codes, deadlines, and interceptors — and avoid the leaked stream | 75-100 min |
| 03 | GraphQL fundamentals | Build a schema/resolver GraphQL API on Strawberry, and kill the N+1 problem with DataLoaders | 90-120 min |
| 04 | GraphQL advanced patterns | Add subscriptions, cursor-based pagination, per-field authorization, query-cost limits, and know federation | 90-120 min |
| 05 | GraphQL schema evolution and deprecation | Evolve a schema with no version numbers: @deprecated, additive-only change rules, field lifecycle, and schema checks in CI |
75-100 min |
| 06 | GraphQL errors, nullability and partial results | Use the errors[] array and null-propagation deliberately, and model expected failures as schema types rather than exceptions |
75-100 min |
| 07 | GraphQL security, caching and observability | Defend against alias and batching attacks that complexity limits miss, cache a POST-based API with APQ and cache hints, and trace per-resolver | 90-120 min |
| 08 | Webhooks vs polling vs websockets tradeoffs | Choose the right update mechanism for a given consumer — poll, webhook, SSE, or WebSocket — and know its cost | 45-60 min |
| 09 | API gateways and BFF | Place an API gateway (auth, rate limit, routing) and a Backend-for-Frontend layer at the edge — and know when each is premature | 75-100 min |
| 10 | API design tradeoffs in practice | Mix REST + gRPC + a GraphQL BFF in one system, version across paradigms, and document a multi-paradigm surface | 75-100 min |
| 11 | Edge computing and WebAssembly | Run request-shaping logic at the edge in a Wasm sandbox, and know what belongs there vs. at origin | 60-90 min |
| 12 | Capstone project | Build one small service exposed via an internal gRPC API and a GraphQL BFF in front of it for a web client | 3-5 hrs |
Start here → 00-beyond-rest-when-and-why/README.md
Back to the master index: ../README.md
Once you've completed this track, the next one is 12-testing-and-code-quality — a shift from designing and exposing APIs to proving they work: unit/integration/e2e tests with real TDD discipline, CI automation, and objective code-quality measurement.