Temporal Adoption for Polyglot Teams

Community Support
1

Background
I have an organization that is developing services in Java, Golang, and Python. Some services are existing and some are not even developed yet. We would like to adopt and use Temporal for its many benefits within the broader system. We know about the polyglot demos and sample code and have reviewed them.

Question
What is the best practice for communication between services written in many different languages?

The options appear to be:

  1. Develop traditional microservices and expose service APIs via gRPC/OpenAPI and wrap them in Activites/Workflows as an SDK or at the consumer.
  2. Utilize the DSL samples in some way.
  3. Create a client that defines all Workflows/Activites in all 3 languages and has the correct worker queue routing built into it to abstract which services expose which Workflow/Activities.
  4. ???

Which is typically recommended and are there any known organizations I can reach out to actively using Temporal for polyglot development?

Thanks!

2

In the long term, the Nexus project is going to provide gRPC (and possibly other types of IDL) generation for async APIs and workflow and activity interfaces to implement them.

In the short term, I would recommend using protobufs as inputs and outputs of workflows and activities. If you standardized the naming convention it should be straightforward to determine the input and output types of any function.

3

@maxim Are there any organizations you know using the polyglot support? I’ve been unable to find any in the open source doing it.

4

Yes, this is pretty common. A lot of large organizations would not adapt Temporal if it was a single language solution.

5

Can you provide example orgs?

Edit: That are doing polyglot workflow and activity interaction and not wrapping it in a gRPC/REST API.

6

You can ask around in Slack. We’ll think about a public case study that involves polyglot workflows.

7

Thank you. I’m trying to enable polyglot support but running into refactor requirements of Java devs using the SDK to declare workflows internally and then those not being easily shared or documented with the Golang devs.

Nexus appears to be an answer but is also just exposing a standard interface that is starting to look like others googleapis/operations.proto at master · googleapis/googleapis · GitHub that exist. You’d still likely bake that into a REST/gRPC type document to allow easy sharing of the domain contracts.

I fully understand if this is outside the scope of Temporal for cross domain boundary interactions and might settle on internal teams doing polyglot activities and workflows under their specific domain while maintaining a standard contract via REST/gRPC.

8

I fully understand if this is outside the scope of Temporal for cross domain boundary interactions and might settle on internal teams doing polyglot activities and workflows under their specific domain while maintaining a standard contract via REST/gRPC.

Nexus aims to make Temporal the best platform for cross-domain boundary interactions. I agree that without Nexus, I would keep interactions within a single domain.