Lessons Learned From Maintaining SDK in Python for Three Years
summary
Three years of iteration yields three concrete approaches and one clear lesson: the first SDK-per-stack solution works but multiplies maintenance across frameworks and ORMs, the second stamps queries and reads DB logs (requires DB reconfiguration and costly logging), and the final approach uses OpenTelemetry auto-instrumentation plus a small Matis collector Docker component, which mostly avoids code or DB changes and drastically reduces per-language upkeep while still collecting SQL + explain plans.
AI-written summary · about
chapters (19)
- 0:00intro
- 0:20preamble
- 1:24what do we do?
- 9:35how it works
- 13:48three different approaches
- 15:08sdk per tech stack
- 17:13first approach
- 22:09reading from the database
- 24:39second approach
- 29:00moving the ownership
- 33:40third approach
- 37:33what we learned
- 38:01uniform functionality
- 43:10json vs grpc
- 45:03proprietary vs well-known protocol
- 46:40versions management
- 48:16rigorous testing
- 50:51diversity
- 53:07q&a
related talks
27mSDK or Not
09mDeveloping and supporting 12 SDKs with a team of three
38mData Secrets from a Platform Engineer
32mBest Practices in SDK Development
34mWhy SDK Docs Matter — And What I’m Doing About It!
27mLessons from a Year with Backstage: What Worked, What Didn’t...
32mHow to successfully shift from app development to SDK development
53mHow not to fuckup with building SDK and make clients happy