Sure! Today, we don’t offer much on top of the SDKs. What we do have are thin shims for mostly common initialization: Configure mTLS, metrics, loggers, OTEL, worker service discovery integration, and the like; plumbing that is common for any given SDK across projects that is high-leverage.
We support Go, Java, and Python, and there’s minimal community support for TypeScript. I’ll onboard TS as an officially-supported language once there’s more than 1 team using it–which there isn’t right now. Any other languages follow the same adoption model: I have a doc that outlines minimal requirements for an SDK and help the team get started if they need it, then if that SDK gets popular I’ll bring the foundations under my wing.
This also goes for the CLI: We configure mTLS to talk to our proxy on behalf of users so they can just call temporal without worrying about wiring that stuff up. We do have one additive command temporal nflx batch-terminate that people use for nuking all workflows of a given type, but now that the UI supports a similar action, it’s likely it’ll get removed as its use is exceedingly rare and an anti-pattern.
Early in our journey, we did build a bunch of abstractions atop the SDKs, but since we don’t have a dedicated team (it’s basically just me), I walked this back as we grew beyond Java. Things we built, like our task queue traffic shaping library for Java wound up only being used by one org, and Temporal built a similar feature for the Go SDK based on this called Worker Sessions, so that library in Java is no longer maintained by me, nor offered in the other internal official SDKs.
So, at this point, everyone gets the OSS SDK and can do whatever they desire with it. There have been common themes of functionality people want, however, like triggering alerts when activities are retrying beyond some threshold, so it’s likely I’ll be building & maintaining such interceptors for all of our SDKs.
Should I get funding for a team, I don’t plan to alter our approach on abstractions, etc. The use cases within our company are so diverse that I’d prefer innovations start locally, then only promote to a central offering based on demand, or if we can see a clear global need for something.
Hope this helps!