Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dbos: Durable Workflow Orchestration with Go and PostgreSQL

github.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#11

Post by KraftyOne »

saintarian wrote: post #7
hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

Great project! Love the library+db approach. Some questions: 1. How much work is it to add bindings for new languages? 2. I know you provide conductor as a service. What are my options for workflow recovery if I don't have outbound network access? 3. Considering this came out of https://dbos-project.github.io/ , do you guys have plans beyond durable workflows?

1. We also have support for Python and TypeScript with Java coming soon: https://github.com/dbos-inc

2. There are built-in APIs for managing workflow recovery, documented here: https://docs.dbos.dev/production/self-hosting/workflow-recov...

3. We'll see! :)

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#12

Post by KraftyOne »

jiggunjer wrote: post #10
hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

Does it natively support job priorities? E.g. if there's 10 workflows submitted and I start up a worker, how does it pick the first job.

Yeah, queue priority is natively supported: https://docs.dbos.dev/golang/tutorials/queue-tutorial#priori...

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#13

Post by KraftyOne »

jiggunjer wrote: post #6

Sounds exactly like how Temporal markets itself. I find that the burden of creating idempotent sub-steps in the workflow falls on the developer, regardless of checkpoints and state management at the workflow level.

Yes, in any durability framework there's still the possibility that a process crashes mid-step, in which case you have no choice but to restart the step.

Where DBOS really shines (vs. Temporal and other workflow systems) is a radically simpler operational model--it's just a library you can install in your app instead of a big heavyweight cluster you have to rearchitect your app to work with. This blog post goes into more detail: https://www.dbos.dev/blog/durable-execution-coding-compariso...

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#14

Post by Jtsummers »

odie5533 wrote: post #9

For a project with minimal users, we get a lot of DBOS posts.

Not really.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... - Not even 3 full pages worth over the past 5 years, though the first page is entirely from this year. It's maybe 2-3 a month on average this year, and a lot are dupes.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... - Nim, for comparison, which doesn't really make a dent in the programming world but shows up a lot. The first 15 pages covers the same time period.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#15

Post by KraftyOne »

drakenot wrote: post #5
hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

I read the Dbos vs Temporal thing, but can you speak more about if there is a different in durability guarantees?

The durability guarantees are similar--each workflow step is checkpointed, so if a workflow fails, it can recover from the last completed step.

The big difference, like that blog post (https://www.dbos.dev/blog/durable-execution-coding-compariso...) describes, is the operational model. DBOS is a library you can install into your app, whereas Temporal et al. require you to rearchitect your app to run on their workers and external orchestrator.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#17

Post by travisgriggs »

KraftyOne wrote: post #11
saintarian wrote: post #7

Earlier quoted context omitted.

Great project! Love the library+db approach. Some questions: 1. How much work is it to add bindings for new languages? 2. I know you provide conductor as a service. What are my options for workflow recovery if I don't have outbound network access? 3. Considering this came out of https://dbos-project.github.io/ , do you guys have plans beyond durable workflows?

1. We also have support for Python and TypeScript with Java coming soon: https://github.com/dbos-inc 2. There are built-in APIs for managing workflow recovery, documented here: https://docs.dbos.dev/production/self-hosting/workflow-recov... 3. We'll see! :)

Elixir? Or does Oban hew close enough, that it’s not worth it?

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#18

Post by dfee »

KraftyOne wrote: post #15
drakenot wrote: post #5

Earlier quoted context omitted.

I read the Dbos vs Temporal thing, but can you speak more about if there is a different in durability guarantees?

The durability guarantees are similar--each workflow step is checkpointed, so if a workflow fails, it can recover from the last completed step. The big difference, like that blog post ( https://www.dbos.dev/blog/durable-execution-coding-compariso... ) describes, is the operational model. DBOS is a library you can install into your app, whereas Temporal et al. require you to rearchitect your app to run on their worker…

This makes sense, but I wonder if there’s a place for DBOS, then, for each language?

For example, a Rust library. Am I missing how a go library is useful for non-go applications?

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#19

Post by jiggunjer »

KraftyOne wrote: post #13
jiggunjer wrote: post #6

Sounds exactly like how Temporal markets itself. I find that the burden of creating idempotent sub-steps in the workflow falls on the developer, regardless of checkpoints and state management at the workflow level.

Yes, in any durability framework there's still the possibility that a process crashes mid-step, in which case you have no choice but to restart the step. Where DBOS really shines (vs. Temporal and other workflow systems) is a radically simpler operational model--it's just a library you can install in your app instead of a big heavyweight cluster you have to rearchitect your app to work with. This blog post goes into…

Oh I see. Seems Nextflow is a strong contender in the serverless orchestrator market (serverless sounds better than embedded).

From what I can tell though, NF just runs a single workflow at a time, no queue or database. It relies on filesystem caching for "durability". That's changing recently with some optional add-ons.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#20

Post by KraftyOne »

dfee wrote: post #18
KraftyOne wrote: post #15

Earlier quoted context omitted.

The durability guarantees are similar--each workflow step is checkpointed, so if a workflow fails, it can recover from the last completed step. The big difference, like that blog post ( https://www.dbos.dev/blog/durable-execution-coding-compariso... ) describes, is the operational model. DBOS is a library you can install into your app, whereas Temporal et al. require you to rearchitect your app to run on their worker…

This makes sense, but I wonder if there’s a place for DBOS, then, for each language? For example, a Rust library. Am I missing how a go library is useful for non-go applications?

There are DBOS libraries in multiple languages--Python, TS, and Go so far with Java coming soon: https://github.com/dbos-inc

No Rust yet, but we'll see!

Post reply on HN