3 ms·
you could use postgres with postgREST. push your JSONs via HTTP into a queue. a LISTEN/NOTIFY would trigger queue workers server-side.
by omani 4y ago
you could use postgres with postgREST. push your JSONs via HTTP into a queue. a LISTEN/NOTIFY would trigger queue workers server-side.
- rich_sasha 4y agoThat sounds nicely low-tech! Does the queue itself keep track of messages consumed, or is that up to the user?
- omani 4y agoit is up to you and how you implement it. eg. a trigger notifies the backend that a new job is in the queue (push) or the backend can regularly check for new jobs (pull). once the backend finishes the job, the row in the queue table can be updated with a flag "DONE" or something like that. you can use any language you want in the backend for notifications, or use even ZMQ (for example https://github.com/SpiderOak/skeeter https://github.com/SpiderOak/skeeter) with a DEALER pattern to have more than one worker. or other implementations or postgres extensions (like pg_cron). very flexible and is set up in less than an hour.
- rich_sasha 4y agoHmm so it's still a DIY job, just with better components, right? I'm not averse to that, but right now hoping that there's an out-of-the box solution.
- omani 4y agohmm...another option would be n8n (https://n8n.io/ https://n8n.io/). comes as a docker container. there you can build your customized pipelines. check out the available integrations (https://n8n.io/integrations/ https://n8n.io/integrations/). basically, what you want is a webhook, post your JSON to that webhook, and a second node that does the work with that JSON as an input. very flexible and is set up in less than an hour.