When will Nexus be supported in the Python SDK?

Community Support
1

We’re looking to explore using Temporal Nexus but see that so far, it’s only available in the Go and Java SDKs. Do you know when this will be released for the Python SDK?
Thank you in advance for your help.

1 Like
2

Hi @rhornw yes we’re targeting Pre-release Nexus support in the Python SDK in the very near future and a Public Preview a month or two after that!

Some more Temporal Nexus info below:

  • Tracking issue for all SDKs
  • Go SDK and Java SDK support for Nexus is available today!
  • Python SDK & Typescript SDK are under active development
  • Release targets:
    • Pre-release will be available first - we’d love early feedback!
    • Public Preview - a month or two after – suitable for production use cases
    • GA to follow – once we’ve incorporated any fine tuning feedback from Public Preview
  • Additional SDKs being planned for later this year

As noted in the #nexus in Temporal Slack – drop by and say hi!

Also the Temporal Nexus GA blog post has some good videos from Netflix and Miro along with the Nexus talk from Replay London 2025 – definitely check those out if you haven’t seen them already!

3

Python SDK version 1.14.1 now has experimental Nexus Pre-release support!

1 Like
4

Thanks for adding Nexus to the Python SDK!

Is there a forum for discussing Nexus in general? I work at a polyglot company. Ideally we’d like to use Nexus endpoints to connect workflows managed by different teams in various languages:

  • Python
  • TypeScript
  • .NET
  • Ruby
  • PHP
  • Java

The various examples for Nexus (samples-python, samples-java, etc.) are helpful in showing how to connect a caller and handler, but they assume the caller and handler are written in the same language. The service contract for Python is defined in Python, that for Java in Java, etc. How would one share a service contract between different languages? Could the service contract be defined in JSON or some other language-agnostic format?

If this is the wrong place to raise these questions, please suggest where I should post this.

Thanks again!

5

Could the service contract be defined in JSON or some other language-agnostic format?

Hi @benissimo :waving_hand: yes the Nexus service contract can be defined as JSON today.

Nexus payloads that are native language types are serialized to JSON using the default Data Converter (the same Data Converter used for serializing other Temporal payloads):

If a value isn’t null, binary, or a Protobuf, it is encoded as JSON. Most common input types — including strings, integers, floating point numbers, and booleans — are serializable as JSON. If any part of it is not serializable as JSON, an error is thrown.

Nexus dev guide examples - native types → JSON payloads

Must ensure consistent mapping of native type field names → JSON field names

  • Use JSON decorators, annotations, and struct tags to ensure consistent JSON field names across Nexus callers and handlers in different languages:
    • Java & TypeScript: often camelCase (firstName)
    • Python: often snake_case (first_name)
    • Go: PascalCase by default unless struct tags used (FirstName)
    • This can lead to a firstName vs FirstName vs first_name mismatch.

Nexus JSON schema-first contracts & code gen (experimental prototype)

Nexus gRPC-style protobuf contracts & code gen (experimental prototype)

6

Thanks, I was hoping something like this existed. And good point calling out the differences in how each of these languages serialize field names to JSON. I wish Nexus had chosen to define service contracts in some language agnostic schema directly (JSON, YAML, Protobuf, whatever) and then provided code generators. A service contract is, at the end of the day, a schema, not code. Avro schemas in Kafka, OpenAPI specs, etc. – you can generate code from them, sure, but they are schemas first, not code first. I’m curious why Nexus chooses to treat service contracts as code first, and only implicitly as schemas.

We’ll try out these repos as workarounds. Thanks for sharing!

7

Thanks @benissimo, note the above repos are from folks that work at Temporal. We do plan to incorporate these prototypes into Nexus once they graduate the early prototype stage to support schema-first Nexus contracts and codegen.

You may also want to checkout https://github.com/cludden/protoc-gen-go-temporal which can generate Nexus handlers out of proto annotations if you want more generated code with less flexibility.

I’m curious why Nexus chooses to treat service contracts as code first, and only implicitly as schemas.

We started with an open/flexible “generic pipe” similar to how the rest of Temporal works as the base layer and are adding more opinionated schema-first contracts as a layer on top.

Is there a forum for discussing Nexus in general?

Yes drop by #nexus community channel in Temporal Slack!

1 Like