Name: artsy-eventservice
Owner: Artsy
Description: Ruby Gem for producing events in Artsy's event stream.
Created: 2016-12-29 13:25:10.0
Updated: 2018-05-24 14:25:02.0
Pushed: 2018-05-24 14:25:01.0
Homepage: null
Size: 58
Language: Ruby
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Ruby Gem for producing events in Artsy's event stream.
Add following line to your Gemfile
'artsy-eventservice'
Add artsy_eventservice.rb under config/initializers.Artsy::EventService` uses Bunny to connect to RabbitMQ. Here is a sample of configuration:
nfig/initializers/artsy_eventservice.rb
y::EventService.configure do |config|
nfig.app_name = 'my-app' # Used for RabbitMQ queue name
nfig.event_stream_enabled = true # Boolean used to enable/disable posting events
nfig.rabbitmq_url = 'amqp(s)://<user>:<pass>@<host>:<port>/<vhost>' # required
nfig.tls = true # following configs are only used if tls is true
nfig.tls_ca_certificate = <string content>
nfig.tls_cert = <string content>
nfig.tls_key = <string content>
nfig.verify_peer = true # Boolean used to decide in case we are using tls, we should verify peer or not
Create events by inheriting from Events::BaseEvent. Override the properties that are different than BaseEvent and set extra properties.
le Events
ass ConversationEvent < Events::BaseEvent
def subject
{
id: @object.to_id,
display: @object.to_name
}
end
def properties
{
test_prop: 'testing'
}
end
d
We have a feature flag setup for enabling/disabling EventService. Setting EVENT_STREAM_ENABLED env variable will enable posting events. Not having this env means event service is disabled and no events will actually be sent.
Call post_event with proper topic and event:
y::EventService.post_event(topic: 'testing', event: event_model)
Think of topic as high level business area. From consumer perspective there will be one connection per topic, consumer can decide to filter events they want to receive in that topic based on routing_key they listening on. For topic use plural names.
We recommend to use following routing_key strategy:
<model_name>.<verb>.
Few examples:
conversations, routing key: message.sentconversations, routing key: conversation.createdconversations, routing key: conversation.dismissedinvoices, routing key: invoice.paidinvoices, routing key: merchant_account.createdBaseEvent provides routing_key method by default which follows the same pattern mention above, you can override routing_key when calling post_event.
In previous versions this gem was using Environment variables for configuration. On version 1.0, configuration step is now mandatory and it will no longer read environment variables directly. Make sure to go to configuration step.
Since this version we've updated routing_key to default to <event object class name>.<event.verb>. This means if your consumers were listening on verb routing key, now they need to update to include object's class name.
You can always override this feature by passing in routing_key to post_event.