REST API for Scheduling Jobs and HTTP Request Jobs

[octalpixel]

Hey!
Just a curious guy coming across the repo. Something that cross my mind, I see similarity to https://quirrel.dev/ , https://www.inngest.com/

Having the River support REST API would really help non-Go developers to use the service as well. Meaning I could simple self host this on railway and build use this as a queue system. Just a thought that probably a basic support to add jobs that trigger HTTP endpoints would kinda kick start things as well.

Eg:

[brandur]

Interesting. My intent had been to provide language-friendly insert-only SDKs for a few popular languages (probably Ruby to start, then maybe JS), but an HTTP API might be somewhat useful in that it'd provide a fallback for any other languages we didn't get to.

One significant downside though is that with HTTP you lose the transactional benefits offered by using a database driver and transaction directly. This might be okay for some use cases though.

@octalpixel OOC, were you thinking that you'd send from Node and still have jobs worked in Go? Or does the "send request to endpoint" part of your chart suggest that there'd be a way to configure a job to send through to another HTTP API?

[octalpixel]

hey @brandur , thanks for your thoughts on this! Good to see that there was direction for being language agnostic.

"Or does the "send request to endpoint" part of your chart suggest that there'd be a way to configure a job to send through to another HTTP API" - Yes, mostly, lets assume it be router. You schedule using River, River forward the request to an endpont specified

Assuming the payload sent to River is
{ "event": "order.placed", "data": { "orderId": "1", "customerId": 2 }, "endpoint": "http://example.com/webhook/erp" }
This data get directly forward to the specified endpoint and the endpoint handles the processing. This would make sense in one way for the developer doesnt have to learn Go, but uses River, as queuing system

[brandur]

Thanks for the clarification @oktapixel. I think right now I'd be tempted to make users write their own HTTP forwarding job if they wanted one (rather than have one be built in), just because (1) it feels a little beyond the scope of a queuing system, and (2) there are a lot of specific semantics around how the HTTP forwarding is done that people might want configurable (i.e. which endpoints, how many retries, filtering, custom routing of events to specific endpoints, etc.) that's way better expressed in code than an elaborate configuration system.