jbgo / chasqui Goto Github PK

• write integration test for sidekiq worker similar to https://github.com/jbgo/chasqui/blob/master/spec/integration/resque_spec.rb
• get the sidekiq worker working
• do a thread safety check for the sidekiq worker

• edit/revise the README to reflect the actual public interface
• be sure to document all configuration options (create a wiki page if needed)
• Write doc comments for all public classes, methods, constants, etc.
• Add chasqui to rubydoc.info
• update the examples to reflect the actual public interface https://github.com/jbgo/chasqui/tree/master/examples

Include rubycop and rcov tasks in the build

TODO: need to enable test coverage for forked processes in integration test

In order for sidekiq to recognize that a queue exists, it must be part of the queues set.

[12] pry(main)> Sidekiq.redis { |r| r.smembers 'queues' }
=> ["default"]

We need to ensure this set exists when creating subscribers, or events will never get processed.

• provide an easy way for chasqui subscribers to use resque/sidekiq plugins (e.g. https://github.com/lantins/resque-retry)

Add metrics and monitoring for the chasqui broker.
TODO - more specific requirements

• create a PHP client that implements Chasqui::publish()
• all other functionality is optional
• must be a composer package available on packagist
• could be a separate repository

Sidekiq is multi-threaded, so be sure to include a thread safety check.

(This may be more of a 'pro tip' than something that needs to be baked into Chasqui, FYI)

At RFX, we've moved to versioning our event names. So, for example, you want to run some handler code whenever an asset data object is created. We would route/subscribe/publish an event as 'assets:created_v1' - where 'assets' is the channel and 'created_v1' is the event name. All this does is further decouple code. If we want to change the payload or handler code for that event, we just start publishing a '_v2' version of the event as needed. Sometimes the publisher may publish both the v1 and v2 events at the same time. The goal is allowing a way to safely upgrade all (or just some) of the event subscribers to the new version without breaking the old subscribers (even temporarily).

Anyway, this could be baked formally into Chasqui's event API or it could just be a 'protip' on naming events. Just wanted to throw it out there and see what you think. Let me know if you have any questions. Thanks!

• support for REE has been requested
• Chasqui.publish and Chasqui.subscribe must be compatible with REE
• The resque worker (but not the sidekiq worker) must be compatible with REE
• The Chasqui broker should be compatible with REE if it is not too much additional effort

for example:

• https://github.com/jbgo/chasqui/blob/master/examples/full.rb#L31
• https://github.com/jbgo/chasqui/blob/master/examples/full.rb#L44

I don't see those settings referenced anywhere else in the API. Is that just so Chasqui knows where to get the event details in redis? Or is it so that when chasqui gets one of those events he knows what queue (worker?) to dispatch the event to?

Anyway, not sure anything needs to be done about this - just curious. Thanks!

I want to see when a client subscribes/unsubscribes in the chasqui broker logs.

Currently, we're queueing jobs using the chasqui redis namespace. I don't think this should be the default so that the default configuration will work with resque/sidekiq without any changes. It definitely should be configurable.

For example, all of the following should work for handling event.

Chasqui.subscribe 'channel.name', 'queue-name', MySubscriber
Chasqui.subscribe('channel.name', 'queue-name') { |a, b| logger.info("sum: #{a + b}") }
Chasqui.subscribe 'channel.name', 'queue-name', ->(payload) { logger.info payload }

• sysvinit
• upstart
• systemd

Port the chasqui client and broker to the Go programming language.
http://golang.org/

Implement a version of the broker that runs as a Lua script on the redis server.
http://redis.io/commands/eval

I would like for Chasqui to generate a unique event_id for every published event.

Ideally, this should be part of the build process.

After looking through the code I'm not sure how unsubscribing queues from a channel will work. I'm guessing at the moment if you removed a given subscription from the code the Chasqui worker would continue pushing work into that Redis list until you manually removed it from the set of subscribers.

Add support for popular error notification services like Honeybadger, NewRelic, Airbrake, Errbit, etc.

The resque/sidekiq workers can be configured just like any other resque/sidekiq worker.

Update contribution guidelines to include the following:

1. For new functionality, please open an issue before creating a PR
2. For bug fixes, you can open a PR first
3. Tell people to be polite when communicating with contributors, maybe even link to some blog posts on how to give constructive feedback and without being a jerk
4. Tests are required with ALL contributions

See inline comment on this commit: c6f39c3#diff-5fbc42bf6d8d1a87dd728eabebdc7a53R25