JavaScript client

[htunnicliff]

This library looks fantastic! I'd love to have the concepts enabled by River ported to a JS environment (in my case, Deno). Is a port similar to the ruby gem something this team would ever consider building?

I would be glad to build something like this as well.

[bgentry]

@htunnicliff thanks for the kind words! I’d love to hear more about how you’re looking to use a JS River client. Would this be only for job insertions? Or are you looking to actually execute jobs with JS logic?

[htunnicliff]

Thank you for your reply! I'll try to add some more context!

In my background, the only queueing solution I've enjoyed working with was the Laravel queue driver. It's been several years of writing TypeScript since then, and I've been on the hunt for a queue system that has great ergonomics and simplicity while supporting jobs that execute in JavaScript.

Coming across River—with only a handful of Go knowledge—I find myself drawn to the API you've built in conjunction with the first-class Postgres backing.

In short: I'm wondering if porting the River concepts to TypeScript to enable defining and executing jobs (along with the many other features) using Postgres as the queue driver is feasible.

If there is a way to define jobs and execute them in TS, while backing everything with River, that could also work too.

[noorvir]

@bgentry I second @htunnicliff's request. I would love a typescript client. I'm currently using pg-boss which is fine but river looks a lot more promising (and especially with workflow support).

I also think there would generally be pretty high usage in the typescript community which is already seeing tools like Inngest and Trigger.dev.

I'm a big fan of Go but unfortunately need to use typescript for my current project. River support for typescript would be amazing.

[brandur]

@noorvir Out of curiosity, what TS ORM are you using for database persistence?

The biggest hiccup for me on a TS client right now is I don't know the ecosystem that well, and I'm not sure what we'd need to be compatible with in order to be useful. There seems to be dozens of competing ORMs that seem plausible, but no clear winners.

[noorvir]

I'm big on staying close to sql (coming from sqlc in Go) so I use Kysely, although I have to admit it's not nearly as popular as Prisma, Knex and Drizzle.

The ecosystem is pretty fragmented but I imagine River's target group (Postgres maximalists) has a large overlap with something like Supabase.

It might be a great combo for River since background jobs/queues is the last piece missing from the Supabase stack. They also have a substantial user base of developers who:

1. Use Postgres, and
2. Don't want to worry about infra.

So potentially a good place to start.

[deedubs]

Agree that the ecosystem is a little bit of the wild west but I did some spelunking and behind the covers of both Prisma¹ and Drizzle]² is the pg package.

I suspect we could get access to the pg connection/object from both libraries allowing us to simply target pg itself to cover a decent subset of the node community.

Footnotes

1. https://www.prisma.io/docs/orm/overview/databases/postgresql#using-the-node-postgres-driver ↩

2. https://orm.drizzle.team/docs/connect-overview ↩