_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Show HN: Stepped Actions â distributed workflow orchestration for Rails
dzonga wrote 8 hours 49 min ago:
the write up was well done - on why the pivot. & who his actual target
market is
vicentereig wrote 8 hours 50 min ago:
Nice work. Thanks for sharing it! I've been thinking about using
something like this for LLM agent workflows - the outbound action
pattern would work well for tool calls that need to wait on external
APIs.
I'm working on DSPy.rb [1] and this could pair nicely for multi-step
reasoning chains.
Curious - any plans for async gem support?
HTML [1]: https://oss.vicente.services/dspy.rb/
reedlaw wrote 5 hours 34 min ago:
How does DSPy.rb differ from BAML?
vicentereig wrote 3 hours 23 min ago:
Both model prompts as functions. BAML is a DSL - write .baml files,
generate code, get validated structured outputs.
DSPy is a programming paradigm. I like to look at it like the MVC
for the Web. You define Signatures[0]: typed contracts governing
the relationship between your models and your app. Signatures model
prompts as functions too, without leaving Ruby. Then compose them
into modules (Predict, ChainOfThought, ReAct, your own). The
framework can automatically optimize prompts based on your metrics.
DSPy.rb brings the DSPy paradigm's tooling (optimizers, evaluation
loops) to Ruby. Comes with OpenTelemetry OOTB. It also borrows
BAML's schema format for 85% token savings vs JSON Schema in
complex signatures. [1] Everyone is talking about prompt, context,
and harness engineering -and I agree they are good ways to frame
how to build workflows and agents- this is just programming really.
[0] [1]
HTML [1]: https://oss.vicente.services/dspy.rb/core-concepts/signatu...
HTML [2]: https://oss.vicente.services/dspy.rb/articles/baml-schema-...
chao- wrote 8 hours 51 min ago:
I have implemented (or managed a team that implemented) this concept
four separate times as an internal library somewhere. Each one included
slightly different affordances and addressed a few different concerns
that stem from the domain that it was built for.
Props for extracting it and offering it up as a library. I'll be
interested to compare it to the implementations I've seen, and see what
you've added that I've not seen before.
sroussey wrote 9 hours 18 min ago:
Nice. I have a simple system for typescript [1] where you can string
tasks together like:
import { Workflow } from "@workglow/task-graph";
const workflow = new Workflow();
workflow
.DownloadModel({
model: ["onnx:Xenova/LaMini-Flan-T5-783M:q8", "Universal Sentence
Encoder"],
})
.TextEmbedding({
text: "The quick brown fox jumps over the lazy dog.",
});
await workflow.run();
It automatically caches results of steps if you say `new
Workflow({outputCache});`
PS: the example above uses a local onnx model (it switches on model
name) which is a good candidate for caching, but can be anything.
You can play around writing this way if you open the console at the web
example [2] which has fun console formatters not enough people know
about or use in DevTools. You can write code in the console and the
example rewrites it as a json format in the web page (and visa-versa).
Or just use the free web app with local user account and local models
to play around with. [3] [1] [2]
HTML [1]: https://github.com/workglow-dev/workglow
HTML [2]: https://workglow-web.netlify.app/
HTML [3]: https://workglow.dev
silasb wrote 10 hours 33 min ago:
Seems pretty similar to [1] which is what I found when I typed in
"rails durable execution patterns" into Google. Have you seen this and
if so, how do you think it compares?
HTML [1]: https://github.com/radioactive-labs/chrono_forge
deedubaya wrote 10 hours 41 min ago:
Congratulations on shipping this, Iâm sure folks will find it useful!
The rails native way to do this is to track state in a db row and
queuing ânext stepâ jobs as the data changes. This can get verbose
especially for smaller pass/fail workflows. However, I find this works
better (not worse imo) in more complex workflows as the state is
tracked, queryable, can be surfaced in UIs, and resumed âmanuallyâ
in the event of an outage.
moh_quz wrote 5 days ago:
This looks useful. I've been exploring similar durable execution
patterns in Go recently to avoid the complexity of Temporal for smaller
workflows.
How does stepped_actions handle the state between steps? Does it
persist to the DB after every single action to handle crash recovery,
or is it more optimistic?
Good luck with the launch
nzoschke wrote 8 hours 55 min ago:
I recently started using this DBOS in Go and itâs been good. [1] I
have River on my list to try someday too
HTML [1]: https://github.com/dbos-inc/dbos-transact-golang
HTML [2]: https://riverqueue.com/pro
klevo wrote 5 days ago:
Yes, state is persisted to DB upon every change. Action exceptions
are handled gracefully and natural part of the system, they simply
fail the action. Crash recovery is build-in thanks to checksums and
ActiveJob, if you're using the right adapter, like GoodJob or
SolidQueue where crash recovery is guaranteed.
DIR <- back to front page