Fundamentals

An SDK is not just a client library — it’s the smallest thing a platform can ship that turns ‘read our docs and call our API’ into ‘install this and get to work.’ First in a four-post series on SDK design: this one covers the fundamentals — what SDKs are, where they came from, how they differ from libraries and frameworks and protocols, why they’re becoming the product itself, and a concrete decision framework for when to build one. Companion posts cover the anatomy of an SDK’s surface in Go, the rubric for what makes one good with named exemplars, and the design-process question of routing new capabilities between the SDK and the API.

Not a catalog of the Gang of Four patterns — an argument for why they’re foundational. Design patterns are a shared vocabulary that lets you read a codebase’s architectural intent from the names alone, and the value of that shared language transcends any specific programming language.

A jargon-free introduction to hexagonal architecture — the idea that your business logic should sit in the middle and the outside world (databases, screens, APIs, tests) should plug into it through simple, agreed-upon shapes. Small worked examples in Python, Go, and Rust show what changes when a new requirement arrives.

A working tour of the web-feed ecosystem — the RSS 2.0 lineage, IETF Atom (RFC 4287), JSON Feed 1.1, and OPML for exchanging subscription lists between readers — with practical guidance on which format to publish and current recommendations for desktop, mobile, and self-hosted readers.

A tour of regular expressions shallow enough to onboard a beginner and deep enough to refresh an expert — literals, quantifiers, groups, lookaround, and the engine differences between PCRE-family backtrackers and RE2-family linear-time engines that power grep, Python, Go, and Rust.