Lessons Learned From Maintaining SDK in Python for Three Years
summary
Three-year experience of a production SDK shows what actually works: initial per-language SDKs (pip/npm libraries) are easy to install but explode maintenance across stacks; a DB-log approach captures plans but forces DB config per environment; moving to an OpenTelemetry agent that pulls standardized traces plus a side collector reduces language surface area and maintenance. Concrete rules: prefer existing protocols (gRPC), isolate and run cross-language tests in containers, bump and test versions per-language, assign language champions, and automate CI to catch regressions early.
AI-written summary · about
chapters (9)
- 0:00Introduction to SDK journey
- 3:54First SDK approach pitfalls
- 11:52Minimizing maintenance burden
- 14:42Third approach with OpenTelemetry
- 17:15Lessons on uniform functionality
- 21:49Standards vs proprietary solutions
- 22:53Versioning across languages
- 25:43Managing diverse languages
- 27:30Key takeaways and Q&A
related talks
26mLessons Learned Maintaining the oVirt Python SDK
25mPolyglot Library Development
41mEcosystem for Reliable Python Programming
33mLessons learned building Python microservices
43mPython 3: ten years later
33mBuilding with Multiple Languages: A Python-First Approach
41mHow to Grow an Open Source Project: A Case Study of Python
24m"Introduction to OpenTelemetry with Python"