Why typeorm over something like https://mikro-orm.io/?
Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
31–40 of 51 posts
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#32Could you genericise the requirement in postgresql and provide a storage interface we could plug into? I think I have a use for this in Polykey ( https://GitHub.com/MatrixAI/Polykey ) but we use rocksdb (transactional key value embedded db).
That's definitely worth considering! The core algorithms can work with any data store. That said, we're focused on Postgres right now because of its incredible support and popularity.
You could imagine this working well for cloudflare workers - especially with time limits on execution. (Or with even aws compute market)
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#33Earlier quoted context omitted.
How do you persist execution state? Does it hook into the Python interpreter to capture referenced variables/data structures etc, so they are available when the state needs to be restored?
That work is done by the decorators! They wrap around your functions and store the execution state of your workflows in Postgres, specifically: - Which workflows are executing - What their inputs were - Which steps have completed - What their outputs were Here's a reference for the Postgres tables DBOS uses to manage that state: https://docs.dbos.dev/explanations/system-tables
All of this seems it would fit any transactional key value structure.
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#34Earlier quoted context omitted.
Are there any constraints around which functions can be turned into steps? I assume their state (arguments?) need to be serializable? Also, what happens with versioning? What if I want to deploy new code?
Yeah, the arguments and return values of steps have to be serializable to JSON. For versioning, each workflow is tagged with the code version that ran it, and we recommend recovering workflows on an executor running the same code version as what the workflow started on. Docs for self hosting: https://docs.dbos.dev/typescript/tutorials/development/self-... . In our hosted service (DBOS Cloud) this is all done automati…
If you were to use cbor, you could support binary values more easily.
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#35Why typeorm over something like https://mikro-orm.io/ ?
In addition to TypeORM, DBOS supports several popular ORMs:
- Drizzle (we're also a sponsor to Drizzle): https://docs.dbos.dev/typescript/tutorials/orms/using-drizzl...
- Knex: https://docs.dbos.dev/typescript/tutorials/orms/using-knex
- Prisma: https://docs.dbos.dev/typescript/tutorials/orms/using-prisma
More ORM support is on the way.
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#36Why typeorm over something like https://mikro-orm.io/ ?
In addition to TypeORM, DBOS supports several popular ORMs: - Drizzle (we're also a sponsor to Drizzle): https://docs.dbos.dev/typescript/tutorials/orms/using-drizzl... - Knex: https://docs.dbos.dev/typescript/tutorials/orms/using-knex - Prisma: https://docs.dbos.dev/typescript/tutorials/orms/using-prisma More ORM support is on the way.
Why not always default to using transactions?
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#37Earlier quoted context omitted.
In addition to TypeORM, DBOS supports several popular ORMs: - Drizzle (we're also a sponsor to Drizzle): https://docs.dbos.dev/typescript/tutorials/orms/using-drizzl... - Knex: https://docs.dbos.dev/typescript/tutorials/orms/using-knex - Prisma: https://docs.dbos.dev/typescript/tutorials/orms/using-prisma More ORM support is on the way.
Why not always default to using transactions?
DBOS always uses transactions to perform database operations.
If you're writing a function that performs database operations, you can use the @DBOS.transaction() decorator to wrap the function so that DBOS's bookkeeping records commit in the same transaction as your operation.
However, if you're interfacing with a third-party API, then that wouldn't be part of a database transaction (you'll use @DBOS.step instead). The reason is that you don't want to hold database locks when you're not performing database operations.
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#38What is the determinism constraint? I noticed it mentioned several times in blog posts, but one of the use-cases mentioned here is for use with LLMs, which produce non-deterministic outputs.
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#39What is the determinism constraint? I noticed it mentioned several times in blog posts, but one of the use-cases mentioned here is for use with LLMs, which produce non-deterministic outputs.
Great question! A workflow should be deterministic: if called multiple times with the same inputs, it should invoke the same steps with the same inputs in the same order. But steps don't have be deterministic, they can invoke LLMs, third party APIs, or any other operation. Docs page on determinism: https://docs.dbos.dev/typescript/tutorials/workflow-tutorial...
Re: Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres
#40> What’s unique about DBOS’s take on durable execution (compared to, say, Temporal) is that it’s implemented in a lightweight library that’s totally backed by Postgres. All you have to do to use DBOS is “npm install” it and annotate your program with decorators. The decorators store your program’s execution state in Postgres as it runs and recover it if it crashes. There are no other dependencies you have to manage,…
[deleted]