[HN Gopher] Show HN: Sidequest.js - Background jobs for Node.js ...
___________________________________________________________________
Show HN: Sidequest.js - Background jobs for Node.js using your
database
Hey HN, I'm the maintainer of node-cron (5M+ downloads/month), and
I recently built Sidequest.js, a background job runner for Node.js
inspired by Oban (Elixir) and Sidekiq (Rails). It solves some
common problems I saw with libraries like node-cron: - Jobs don't
block your API: they run in isolated worker threads - No Redis or
vendor lock-in: use Postgres, MySQL, SQLite, or MongoDB - Supports
retries, uniqueness, concurrency, snoozing, prioritization - Comes
with a CLI and a simple dashboard - Works great in monoliths and
doesn't require extra infra Quick start (no signup needed):
https://docs.sidequestjs.com/quick-start GitHub:
https://github.com/sidequestjs/sidequest Would love feedback or
feature suggestions. Happy to answer any questions here!
Author : merencia
Score : 40 points
Date : 2025-08-04 15:39 UTC (7 hours ago)
(HTM) web link (docs.sidequestjs.com)
(TXT) w3m dump (docs.sidequestjs.com)
| MutedEstate45 wrote:
| Really like your approach of using existing Postgres/MySQL
| instead of dragging in Redis. It feels genuinely drop-in, but
| still Sidekiq-class. I know it's a bit early to ask about
| production patterns, but I was curious: if the worker thread
| flood hits the same Postgres that serves the web API, how do the
| job-fetch queries avoid contending with OLTP traffic? Does
| Sidequest follow Oban's advisory-lock approach or use a different
| throttling strategy?
| giovaniguizzo wrote:
| Hello! One of the creators of Sidequest here.
|
| Great question!
|
| Sidequest uses transaction-level row locks (`SELECT ... FOR
| UPDATE SKIP LOCKED`) when fetching jobs. This means each worker
| thread only locks the specific job rows it's about to process,
| minimizing lock contention and avoiding blocking other queries.
| This pattern is inspired by Oban's advisory-lock approach, but
| instead of using explicit advisory locks, Sidequest relies on
| the database's built-in row locking mechanism.
|
| The only drawback is that Sidequest will require one or two
| connections to your DB. If you enqueue jobs from within other
| jobs, then each job that requests an enqueue will also connect
| to your DB (lazily connected upon request - if your job does
| not enqueue, no connection is created). However, you can
| configure the number of concurrent workers per queue and
| globally, so you control how much load Sidequest puts on your
| database.
|
| I hope that answers your question :)
| MutedEstate45 wrote:
| Thanks for the clarification. That's a clean approach. I just
| stared your repo. Looking forward to seeing where
| sidequest.js goes :)
| mousetree wrote:
| I'm a big fan of ActiveJob in Rails. I was considering building a
| version inspired by it in Node but now it looks like I don't have
| to. Thank you for building this.
| hersko wrote:
| This looks really cool.
| nip wrote:
| Looks really neat! Starred on GitHub!
|
| If you have heard of pg-boss [1], how does sidequest compare to
| it? I'm about to embark on some << jobification >> on some flows
| and I'd love to have your opinion (possibly biased, but still)!
|
| [1] https://github.com/timgit/pg-boss
| merencia wrote:
| Thanks for the question! I just checked out pg-boss. Solid
| library if you're fully on Postgres. Sidequest.js takes a
| broader and more flexible approach. Key differences:
|
| Database agnostic: Sidequest isn't tied to Postgres. It also
| works with MySQL, MongoDB, and SQLite, which helps if your
| stack isn't Postgres-based.
|
| Job isolation: Jobs run in worker threads, so heavy tasks won't
| block your main Node.js process. Express APIs stay responsive.
|
| Distributed coordination: Designed to run across multiple
| instances. One node picks up the job, and if it fails, another
| can retry. This is built-in.
|
| Built-in dashboard: Includes a web UI to inspect, retry, or
| cancel jobs.
|
| More than queues: Supports cron jobs, uniqueness constraints,
| per-queue concurrency, and configuration. Some of this overlaps
| with pg-boss, but the intent behind Sidequest is to provide a
| complete solution for job processing.
|
| If you just need simple queues in a Postgres-only setup, pg-
| boss is great. If you want more flexibility, tooling, and
| backend options, Sidequest may be a better fit.
| drewbitt wrote:
| https://github.com/timgit/pg-boss https://github.com/hatchet-
| dev/hatchet are both on top of Postgres, but I like the SQLite
| here for a project I have in mind.
| kristianc wrote:
| I'm not sure I follow with the LGPL requirement.. how do you
| envision downstream users complying with the relinking
| requirement, particularly in cases where Sidequest is
| orchestrating jobs across tightly-coupled backend infrastructure?
___________________________________________________________________
(page generated 2025-08-04 23:00 UTC)