We are using temporal for Microservices orchestration and we have two different cluster environments
- Hashi based cluster (latest micro services)
- Legacy cluster (few legacy micro services)
Temporal server is deployed in Hashi based environment, the front door is http based and not exposed grpc
Micro services (temporal worker) deployed in same Hasi cluster able to access Temporal , but services deployed in Legacy cluster not able to access Temporal deployed in other Hashi cluster which is http based front door.
Our workflow needs to have activities from both legacy cluster & hashi cluster .
Does temporal support worker to have http based communication with Temporal server ? What is the purpose of grpc gateway repo in temporal ? will that help to solve this issue ?
Does temporal support worker to have http based communication with Temporal server ?
Don’t think thats currently possible. Could you maybe use a proxy like for example Envoy that would be able to be configured to handle both http and grpc requests?
Using Envoy approach is transparent to application ? No additional changes required right ?
Just need to point Envoy url in Temporal worker ?
Is this understanding correct ?
Also we have several layers webserver → f5 → ngnix really not sure all these allow grpc calls or not.
Other approach may be using grpc gateway to expose grpc as http.
This apprach need conversion both at temporal server cluster and temporal worker(client) right ?
At Temporal server need to use grpc-gateway to expose grpc service as http .
At Temporal worker (client) need proxy layer to convert grpc call of temporal sdk to http call ?
Is this solution really feasible ?
What changes on high level we need at Server (grpc-> http) and client (http → grpc) .
Do you have any sample application for this approach?
Any drawbacks using this approach
Honestly I am not expert in this area, will ask internally and get back with more info.
One thing that might be useful is this sample nginx, envoy, and haproxy configs I use locally
to load-balance frontends, workers and clients then go through the proxy (grpc):
nginx
envoy
haproxy (not well tested have to admit)
maybe its a good starting point for your research.
Thanks will refer these , one other clarification is how authentication is supported with Envoy approach since this is frontdoor we have to have authentication.
Please get any additional information from your experts to solve this.
We are at stage where complete development is done and we overlooked few legacy microservices which has to communicate with http based front door .complete blocker.
Just highlighting urgency…
Sure will do and get back to you. From what I have seen you can set up your own http endpoints that your legacy services can communicate with, these endpoints would use temporal api (your temporal sdk code) to communicate with Temporal service.
Still I am looking for any solution to make current approach using Envoy work , please let me know if you have more info on this …
Just looking any other approach we can solve this, using separate Temporal instances in hashi & Legacy , both combined participate in single workflow like main work flow and child workflow.
Currently Legacy services won’t create workflow , it will have few activities that needs to be performed as part of workflow triggered by microservice deployed in Hashi cluster .
Can we have two Temporal deployment , one in Hashi cluster and other Legacy cluster .
Is it possible to split the workflow in to two workflow … main workflow will run activities of hashi services and at end activity it trigger child workflow for legacy microservice . Workflow trigger can be done using http call right for temporal ?
Please provide some suggestions on this approach ? Or any other approach can think of.
Pleae provide any pointers for above queries?
For Envoy siggestions , Envoy proxy at server(hashi) side which creates proxy as http , then at other side we need http client right ?
We need http wrapper for sdk client which has to call/poll envoy http end points.
Do we have sdk client wrapper which convert grpc client calls to http call ?
If this is not available what are the changes we have to do at client ( temporal worker deployed in legacy )for client sdk ?
Is this approach feasible?
any further suggestions on this …
