// Topics / API
API
Definition
API coverage in this archive spans 12 posts from May 2016 to Jun 2022 and deals with structural tradeoffs: coupling, failure boundaries, and long-term change cost. The strongest adjacent threads are architecture, rest, and backend. Recurring title motifs include api, graphql, versioning, and rate.
What the archive argues
- Most pieces recommend choosing the simplest architecture that can be operated confidently.
- Early posts lean on api and graphql, while newer posts lean on api and versioning as constraints shifted.
- This topic repeatedly intersects with architecture, rest, and backend, so design choices here rarely stand alone.
Execution checklist
- Define failure domains and data boundaries before introducing additional services or protocols.
- Start with the newest post to calibrate current constraints, then backtrack to older entries for first principles.
- When boundary questions appear, cross-read architecture and rest before committing implementation details.
Common failure modes
- Breaking systems into many parts without clear ownership of cross-service behavior.
- Choosing architecture for trend alignment rather than workload constraints.
- Applying guidance from 2016 to 2022 without revisiting assumptions as context changed.
Suggested reading path
- Start here (current state): Rate Limiting: The Boring Feature That Saves You at 3 AM
- Then read (operating middle): API Rate Limiting: What Actually Works
- Finish with (foundational context): API Design Principles That Stand the Test of Time
Related posts
- Rate Limiting: The Boring Feature That Saves You at 3 AM
- API Versioning: Pick One and Stop Overthinking It
- GraphQL Federation: I’m Still Skeptical
- GraphQL Federation Is Probably Not For You
- I Tried Every API Versioning Strategy. Here’s the One I Actually Use.
- Your API Is a Contract You Can’t Take Back
- API Rate Limiting: What Actually Works
- GraphQL in Production Is Harder Than They Tell You
References
12 entries tagged “API”