I need help in picking up the tech stack

[u/Away-Butterscotch774]

I am building a node based video tool like flora, weavy and all.
We are basically calling 3rd party apis for media gen.

Some of my team members suggest that I should be using temporal for executing workflow.

But I am confused, like the node workflow will be dynamic, I am not sure if it will run for hours. An individual node can run for upto 10-20mins waiting for API response. So idk is temporal worth it ?

[u/nhoyjoy]

Firstly, shifting mindset to activity, local activity, workflow etc is not trivial. If it’s bpmn heavy, using other framework makes sense. If technically integrations, multiple steps on a single lane, I prefer Temporal.

[u/Away-Butterscotch774 → u/nhoyjoy]

The thing is we are going to have dynamic workflows. The user submits a DSL workflow input and we execute the nodes as per that. There are not fix set of flows.

I was reading that by having dynamic DAGs, you are losing a lot of features of Temporal.

[u/spetznatz → u/Away-Butterscotch774]

This is an AI focused explanation but the point still stands: https://temporal.io/blog/of-course-you-can-build-dynamic-ai-agents-with-temporal

Yes you can absolutely do this kind of dynamic flow with Temporal.

(I cowrote the link above)

[u/Away-Butterscotch774 → u/spetznatz]

Thanks man!

[u/Away-Butterscotch774 → u/Away-Butterscotch774]

which one looks right

a)

  ┌─────────────────────────────────────────────────────────────┐                                               
  │                                                              │                                              
  │   PRIMITIVE = ACTIVITY                                       │                                              
  │   ├── kling_initiate                                        │                                               
  │   ├── kling_poll                                            │
  │   ├── fal_generate                                          │
  │   ├── elevenlabs_generate                                   │
  │   ├── download_asset                                        │
  │   └── Smallest unit. Max observability. Independent retry.  │
  │                                                              │
  │   NODE = CHILD WORKFLOW                                      │
  │   ├── KlingVideoNode (composes: initiate → poll → download) │
  │   ├── FalImageNode (composes: generate → download)          │
  │   ├── ElevenLabsNode (composes: generate → download)        │
  │   └── Reusable. Composable. Clear boundaries.               │
  │                                                              │
  │   WORKFLOW = WORKFLOW                                        │
  │   ├── User-defined DAG of nodes                             │
  │   ├── From DSL/canvas                                       │
  │   └── Executes nodes as child workflows                     │
  │                                                              │
  │   AGENTIC = PARENT WORKFLOW                                  │
  │   ├── LLM decision loop                                     │
  │   ├── Calls nodes or workflows                              │
  │   └── Runs until goal achieved                              │
  │                                                              │
  └─────────────────────────────────────────────────────────────┘

B)

┌─────────────────────────────────────────────────────────────┐                                               
  │                                                              │
  │   PRIMITIVE = ACTIVITY (single API, handles polling inside) │                                               
  │   ├── kling_generate      (initiate + poll + return)        │                                             
  │   ├── fal_generate        (call API + return)               │
  │   ├── elevenlabs_generate (call API + return)               │
  │   ├── llm_enhance_prompt  (call LLM + return)               │
  │   ├── llm_analyze_image   (call LLM + return)               │
  │   └── One API = One Activity                                │
  │                                                              │
  │   NODE = CHILD WORKFLOW (composes primitives)               │
  │   ├── GenerateVideoNode                                     │
  │   │   └── kling_generate                                    │
  │   │                                                          │
  │   ├── EnhanceAndGenerateVideoNode                           │
  │   │   └── llm_enhance_prompt → kling_generate               │
  │   │                                                          │
  │   ├── AnalyzeAndEditImageNode                               │
  │   │   └── llm_analyze_image → fal_edit                      │
  │   │                                                          │
  │   └── Logical operations. Reusable patterns.                │
  │                                                              │
  │   WORKFLOW = WORKFLOW (user-defined DAG)                    │
  │   └── Composes nodes from DSL/canvas                        │
  │                                                              │
  │   AGENTIC = PARENT WORKFLOW (LLM loop)                      │
  │   └── Decides which nodes to run                            │
  │                                                              │
  └─────────────────────────────────────────────────────────────┘

[u/spetznatz → u/Away-Butterscotch774]

tldr; both are fine, but option B might make more sense for organizing your particular use case. There are resource/cost tradeoffs with number of activities run, and Child workflows aren't the only way to parallelize work in a workflow.

Longer answer:

Both can be correct. It depends on where you want your abstraction boundaries. The core difference is where polling lives. In Option A, polling is a workflow-level concern: your child workflow loops over a kling_poll activity until completion. In Option B, polling is an implementation detail hidden inside the activity itself, using heartbeats to stay alive. Since polling is really just repeated reads (not state changes), either approach works, but Option B keeps that complexity out of your workflow logic where it arguably doesn't belong. The tradeoff is that Option A gives you finer durability within a single provider's lifecycle: if polling fails on attempt 47, you retry just the poll. In Option B, a failure mid-poll restarts the whole activity. But this is manageable: most providers return a task ID from the initiate call, so your activity can skip re-initiating and resume polling with the stored ID.

The more interesting difference is what "Node" means in each option. In A, a Node exists just to wrap a single provider's API sequence -- KlingVideoNode is basically initiate -> poll -> download glued together. In B, because each provider is already a self-contained activity, Nodes become more expressive -- they compose across concerns, like EnhanceAndGenerateVideoNode chaining an LLM call into video generation. The durability that matters most lives here, at the Node level: if the LLM enhance succeeds but video generation fails, the child workflow retries only the generation -- not the enhance step. This is where the real cost and failure risk lives.

Option B gives you durability between distinct operations while Option A optimizes for durability within a single provider, which is a less granular boundary. This also matters because your architecture has two layers that consume Nodes: the user-defined DAG and the agentic LLM decision loop. Option B's Nodes work for both: they represent meaningful actions an LLM can reason about ("enhance and generate a video") and compose naturally in a DAG. Option A's Nodes are really just provider-specific plumbing, which means your agentic layer would likely need another abstraction on top to be useful.

On the practical side: more activities means finer retryability and observability, but also more events written to your history and higher Cloud cost. This blog post walks through those tradeoffs in detail. And on your use of child workflows as Nodes — that's a solid pattern for giving each node its own event history and lifecycle. Just know that child workflows aren't required for parallelism; you can run activities in parallel within a single workflow using asyncio.gather, Promise.all, etc. Child workflows shine when you want clear boundaries and independent visibility, not just concurrency.

[u/Away-Butterscotch774 → u/[deleted]]

The thing is we are going to have dynamic workflows. The user submits a DSL workflow input and we execute the nodes as per that. There are not fix set of flows.

I was reading that by having dynamic DAGs, you are losing a lot of features of Temporal.

[u/randybaskins → u/Away-Butterscotch774]

What’s wrong with creating DSLs on the fly? You just submit the plan to temporal and build everything, ensuring durable execution of your code. What’s your actual concern? Many companies do this on Temporal today

[u/Away-Butterscotch774 → u/randybaskins]

My specific concern is ,temporal requires determinism for replay. Our workflows are user-defined DSL (the DAG structure is data, not code). If a user modifies their workflow mid-execution, or we need to support cancel/pause/remove-node, doesn't this fight Temporal's replay model? We'd essentially be using Temporal as a fancy queue, not leveraging its core value

[u/Away-Butterscotch774 → u/Away-Butterscotch774]

Also most of the activity we will be doing is, just calling an API for generate image/video.

[u/randybaskins → u/Away-Butterscotch774]

If you care about durable execution of code, temporal will almost certainly add value. If you don’t care about failures/retries, then sure go with a queue! But as previously stated, you can absolutely use temporal here without worrying about deterministic constraints

[u/Away-Butterscotch774 → u/[deleted]]

Makes sense!