github.com/hugopl/sidekiq.cr

Simple, efficient job processing for Crystal

779 stars
0 dependents
License: LGPL-3.0

Nothing has been indexed for 0.5.0 yet. The tag is recorded, its shard.yml has not been read, so the manifest and dependency list below are empty because they are unknown rather than because they are absent.

Installation

# Add this to your shard.yml
dependencies:
  sidekiq:
    github: hugopl/sidekiq.cr
    version: ~> 0.5.0

Then run:

shards install

shard.yml

No shard.yml has been indexed for 0.5.0. You can read it on the repository.

Dependencies

Unknown: the shard.yml for this version has not been read yet.

README

This README is the one indexed from the repository at its latest ref, not from the tag for this version.

# Sidekiq.cr

[![Build Status](https://github.com/hugopl/sidekiq.cr/actions/workflows/build.yml/badge.svg?branch=main)](https://github.com/hugopl/sidekiq.cr/actions/workflows/build.yml)

Sidekiq is a well-regarded background job framework for Ruby.  Now we're
bringing the awesomeness to Crystal, a Ruby-like language.  Why?  To
give you options.  Ruby is friendly and flexible but not terribly fast.
Crystal is statically-typed, compiled and **very fast** but retains a similar syntax to
Ruby.

Rough, initial benchmarks on macOS 10.14.5, ruby 2.7.2:

Runtime | RSS | Time | Throughput
--------|-----|------|-------------
Sidekiq 6.2.0 | 55MB | 16.4 | 6,100 jobs/sec
Sidekiq 6.2.0/hiredis | 49MB | 13.0 | 7,900 jobs/sec
Crystal 0.35.1 | 15MB | 3.8 | 26,000 jobs/sec

If you have jobs which are CPU-intensive or require very high throughput,
Crystal is an excellent alternative to native Ruby extensions.  It
compiles to a single executable so deployment is much easier than Ruby.

## Getting Started

Please see the [wiki](https://github.com/hugopl/sidekiq.cr/wiki) for in-depth documentation and how to get
started using Sidekiq.cr in your own app.

## Testing

`require "sidekiq/testing"` in your spec helper to enable `Sidekiq.testing`, which
lets you control how jobs behave when pushed from specs instead of always hitting Redis.

```crystal
require "sidekiq/testing"

Sidekiq.testing(Sidekiq::TestMode::Inline)

HardWorker.async.perform(1_i64)
```

`Sidekiq::TestMode` has two values:

* `Disable` - the default, Sidekiq behaves normally and jobs are pushed to Redis.
* `Inline` - jobs are executed synchronously, in-process, the moment they are
  pushed instead of being enqueued in Redis. It doesn't make sense to use
  `perform_at`/`perform_in` while `Inline` is active, doing so raises an exception.

`Sidekiq.testing` also accepts a block, in which case the mode is only active for the
duration of the block and whatever mode was active before is restored afterwards:

```crystal
Sidekiq.testing(Sidekiq::TestMode::Inline) do
  HardWorker.async.perform(1_i64)
end
```

> [!WARNING]
> `Sidekiq.test_mode` is a single, process-wide flag and mutating it isn't thread-safe.
> Don't run specs that rely on it concurrently across fibers/threads (e.g. with `-Dpreview_mt`
> or a parallel spec runner), or one spec's mode can leak into another's.

## Support

Sidekiq.cr is community-supported and **not** commercially supported by @mperham and Contributed Systems.
General maintenance and bug fixes are always welcomed.

## Help wanted

See [the issues](https://github.com/hugopl/sidekiq.cr/issues) for chores and other ideas to help.

Things that do not exist and probably won't ever:

* Support for daemonization, pidfiles, log rotation - use Upstart/Systemd
* Delayed extensions - too dynamic for Crystal

The Ruby and Crystal versions of Sidekiq **must** remain data compatible in Redis.
Both versions should be able to create and process jobs from each other.
Their APIs **are not** and should not be identical but rather idiomatic to
their respective languages.

## Naming

Sidekiq is a registered trademark of [Contributed Systems](https://sidekiq.org) who has granted use of the name to this project.

## Thanks

Originally developed by Mike Perham, http://www.mikeperham.com. Maintained by Hugo Parente Lima.