For a developer advocate, an SDK (client library that wraps an API) and the sample apps built on top of it are the actual product a developer touches first, long before they read a word of prose documentation. This work sits in software engineering, developer relations, and technical writing all at once: it means designing libraries developers trust, writing code they can copy-paste with confidence, and keeping demo and reference apps alive as the underlying API evolves. Practitioners care because a broken quickstart or a stale sample app is often a developer's only impression of a product, and no amount of blog-post polish repairs that first bad experience. The non-obvious insight: demo code is not throwaway code — it gets forked, copy-pasted into production, and screenshotted for years, so treating it with production-grade rigor (tests, versioning, security review) is what separates advocacy that builds trust from advocacy that just performs it.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 114 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: SDK Design Fundamentals
Before writing a single wrapper method, a good SDK has to earn a developer's trust by feeling native to their language and forgiving of their mistakes — these are the qualities developers consistently ask for, in order of how often they show up in feedback.
| Quality | Example | Description |
|---|---|---|
const product: Product = ProductSchema.parse(response.data) | Explicit input/output types let an IDE catch integration mistakes before a request is ever sent. | |
client.invoices.create({amount: 500}) hides HTTP, headers, and JSON parsing | • Networking, request/response formatting, and error interpretation are handled for the caller. • The developer focuses on domain logic, not HTTP plumbing. | |
Go uses pointers for optional fields; JS uses Promises/async-await | Non-idiomatic APIs raise cognitive load because they don't "speak the language" the developer already knows. | |
Clear method names like client.customers.retrieve(id) over c.gO(1,2) | A person, not just a compiler, is going to read this code to understand or debug it. | |
A Go SDK relying mostly on the standard library | Fewer dependencies means fewer version conflicts when the SDK is dropped into an existing project. |