dbos-transact-golang

unique about DBOS is that it's just a Go package--all you need to add durable workflows to your app is included in this library (plus Postgres). There's no separate service or orchestrator to run, so you can incrementally add it to an existing Go application without rearchitecting anything. Also, because it’s all Postgres-backed, you get all the tooling you’re familiar with: backups, GUIs, CLI tools–it all just works. You can use Supabase, RDS, Neon, or any other Postgres provider. If you want to try it out, check out the quickstart: https://docs.dbos.dev/quickstart We'd love to hear what you think! We’ll be in the comments for the rest of the day to answer any questions.

ur insights! This was one of the most interesting HN comment I've seen in a while :)

style I mentioned: // code is massively paraphrased for brevity, err checks removed func workflow(dbosCtx dbos.DBOSContext, _ string) (string, error) { _, err := dbos.RunAsStep(dbosCtx, func(ctx) (string, error) { return stepOne(ctx) }) return dbos.RunAsStep(dbosCtx, func(ctx) (string, error) { return stepTwo(ctx) }) } func main() { // Initialize a DBOS context dctx, err := dbos.NewDBOSContext(dbos.Config{ DatabaseURL: "...", AppName: "myapp", }) // Register a workflow dbos.RegisterWorkflow(dctx, workflow) // Launch DBOS err = dctx.Launch() defer dctx.Cancel() // Run a durable workflow and get its result handle, err := dbos.RunWorkflow(dctx, workflow, "") res, err := handle.GetResult() fmt.Println("Workflow result:", res) } I don't think that's a bad thing though, I think that's a good thing. I feel like positioning DBOS as a _library_ is an excellent choice, it's a huge ergonomics improvement. The choices so far seem like you're trying to make DBOS easy to adopt via appropriate amounts of convenience features, but not so much automagic that we-the-devs can't reason about what's going on. With developer reasoning in mind, I have some more questions for you! In the architecture page you linked[2], you talk about versioning. Versioning with durable workflows is one of those super-annoying things which affect the entire paradigm, albiet only once you've already adopted the tech and start having to change/evolve/maintain workflows. In that doc, you say that with DBOS each application will only work on workflows started by application versions which match the current application version. For completing long-running workflows, the page says: > To safely recover workflows started on an older version of your code, you should start a process running that code version. Since one of the killer apps of durable workflows are, as I mentioned, typically long-running jobs, do you have any products/advice/documentation for this pattern of running multiple application versions, and how one might approach implementing this practice? If we're writing code which takes a week to complete and may exit and recover many times before finally completing, do you have advice on how to keep each version deployed till all the work for a version is completed? Looking at Temporal, when using their Worker versioning scheme they offer ways for users to look this information up in Temporal, but not much guidance on actually implementing the pattern. Looking at the DBOS docs about versioning, I see information about getting this information via e.g. Conductor, but I also do not see any info about actually implementing multiple-concurrent-worker-version deployment (which Temporal calls "rainbow deployments"). Is version management something y'all are thinking about improving the ergonomics of, in the same way you improved ergonomics by bringing the executor in-process? Speaking about versioning, how does DBOS handle cases around bugfix versions? Where you deploy a version A, but A has a bug in it. You would like to make the fix and deploy that fix as version B, then ideally, run the remaining workflows for Version A using the code in Version B. It seems like "version forking"[3] is the only way to do this, but it also seems like it's a special operation that cannot be done via a code change; it must be done via the Conductor administration UI. Is there no way to do in-code version patching[4] like is done in Temporal? Finally, what are the limits to usage of DBOS? As in, where does DBOS start to fall down? Are there guidelines on the maximum number of steps in a workflow before things start to get tricky? What about the maximum serialized size of the workflow/step parameters? I've been unable to find any of that information on your website. Thanks for making such an interesting piece of technology, and thanks for answering questions! [1] - https://github.com/dbos-inc/dbos-transact-golang [2] - https://docs.dbos.dev/architecture [3] - https://docs.dbos.dev/production/self-hosting/workflow-manag... [4] - https://docs.temporal.io/develop/go/versioning#patching