Is the sync workflow execution a bad practice?

Community Support
1

Hi, I haave a question about use case for this sync workflow execution.

My scenario is: I have some activities already used in another flow, but I would like to re-use couple of them to get some data during user flow at our website. So when user opens some page I would like to start a very small workflow - wait for result and return a result for user.

I am afraid that such usage is a bad practice. Should I instead create a new web service with the same logic (double the code / move this code to the library)?

2

You can get results of already completed executions. In the linked code
await handle.result()
should unblock immediately if the execution with the configured workflow id has already completed. So I don’t think
you need to start another execution for this.

You can also query completed executions just fyi (from time they completed up to time of the namespace retention period you set, at which time their info is removed from persistence store).

3

I mean that I want to reuse the code itself, under the hood it has some simple logic and remote API call.

This code with such parameyers was not executed yet.

4

Got it. Execution latency which seems you are worried about for use case will depend on what your workflow code does (how many services it invokes, how long those calls take, can they fail and be retried, …), your temporal service and persistence latencies, your worker process setup, current system load, etc.
All this can be measured using sdk and service metrics that can help optimize your setup.

If execution latencies fit within your requirements on user response time for this api then great, if they don’t one idea could be to start the workflow execution
on api request async, respond with “ack” back to user right away, and then have your workflow via activity invoke an api that pushes result to user, just idea.

5

It is certainly not the intended use of Temporal as you don’t need a guarantee of execution in this case. Synchronous use is OK, and it is frequent, but it is usually used when there is a need to ensure that no two duplicated transactions are executed for the same request or there is need to run some compensations in case of some business level failures (aka Saga).

6

Thank you for the responses!
Let me provide a little bit more datail.

  1. We have a form with some inputs. After the form was commited to the baackend we create a database entry.
  2. Using the ID of thet entry we have made a request to the remote API.
  3. And after that we would like to return some results to our user. After that our user can leave the site, he will be notified later then step 4 will be completed (up to the several days)
  4. Depend on the further actions of the user we can do some other actions with our database entry cretaed earlier. A lot of activities actually starts here.
  5. If there is not any actions was made - we also do some actions.

In me opinion the whole story is a SAGA. Is not it? The best option is to have it the siingle workflow but in that case we are not able to retrieve the results in step 3. Thats why I would like to split it into 2 workflows 1-3 and child workflow with step 4-5.

So here is the 2 options:

  • Reuse the code at maximum & keep the whole saga in the workflows.
  • Create web service for the steps 1-3. And start workflow after ster 4 only. Split the saga between web-service and my workflow. It will be much harder to maintain I suppose and I will also need to share an access to the database across multiple solutions.
7

I see. Then breaking into two workflows makes sense. In the future, we are going to extend synchronous update to allow blocking workflow start until a workflow decides to unblock it.

1 Like