#"Roaster Agent"
wide bough
🧵
@tiny hill I'm particulary interested in the async / frontend part of your project
Because we're getting a lot of questions on how Dagger would integrate in the frontend & "workflow scheduler" stack
tiny hill
Well, there are two implementations I was toying with. One was building a traditional Go API that exec's into a module upon receiving a new activity from Strava. The one that was more interesting, even though we don't have great support for it yet, is putting everything inside the module, exposing it as a Service and connecting that directly to the webhooks. I think its a more interesting avenue to explore. This idea that all you need is an engine, from there you can orchestrate everything you need
I don't have a repo or code to share, but I can have one for tomorrow
The reason why I liked the second one is That it ties togrther with the dagger event system we've briefly iterated on in the context of cloud modules
livid echo
I'm also eager to do this webhook approach! Thanks to @gentle barn this might be supported soon #1339366755134472282 message
tiny hill
If I can easily do LLM stuff based on an event (which can be a webhook) all without exiting dagger's API, its quite interesting
livid echo
and Vikram pointed out that Andrea solved this problem with non-modules dagger here https://github.com/aluzzardi/langdag/blob/main/examples/agent/main.go#L27
wide bough
I wonder if down the road, it would make sense to add a first-class webhook server feature in the dagger CLI? Kind of like a variation of dagger serve but it listens specifically for webhooks, and passes them to the specified function/interface?
Or I guess you're saying - go even further and just run the webhook server in the module (but then everyone has to bundle their own webhook server)
anyway, makes sense to me
@tiny hill big question if you want to go the direct-to-webhook route: how do you persist the state?
livid echo
Or I guess you're saying - go even further and just run the webhook server in th...
I want 2 things
- run a webhook server in a module and get a dagger.Service. Once this is done I can build lots of cool demos
- pass a function as an argument 😄 Then I can write a function that has a dependency on foo-webhook-server, and pass it the functions I want it to call based on it's rules
tiny hill
<@628392087880073217> big question if you want to go the direct-to-webhook route...
I was storing files in object storage. The only state I care about is the history of roasts. The idea was to load them when the Service first starts. It would be great if I could specify that as a directory input though 😅
This thing of object storage backed state is classic data pipeline stuff and this app felt a bit like that. Its a simple low througput low stakes thing so more than one instance wouldnt be necessary