Closed jonathansimmons closed 10 years ago
Setting up subscribers in an initializer is recommended because it needs to be done before the app starts handling requests and it doesn't make sense (to me) to put it in app/
. There are other ways to do this, but using an initializer file seems to be the easiest. The subscribers are really just registered for event types in the initializer; they are executed from the stripe_event/webhook_controller. You're definitely correct that crud operations should be handled by controllers. Also, I'm totally open to ideas about changing the recommended setup process. Just let me know or send a pull request and we can discuss it.
Ok, that makes sense. The requests need to be registered as the app starts, hence the use of the initializer.
To clarify for myself, the StripeEvent.configure
is the only thing really needs to happen in the stripe initializer though, correct?
I could create one or more arbitrary classes and methods in the /lib
directory or even my own responder class (/app/models/stripe_responder.rb
) to handle the actual e-mails, logic and crud actions... right?
I think I was more or less confused by the example in the readme which made it appear that thinks like:
class BillingEventLogger
def initialize(logger = nil)
@logger = logger || begin
require 'logger'
Logger.new($stdout)
end
end
def call(event)
@logger.info "STRIPE-EVENT: #{event.type} #{event.id}"
end
end
needed to be created in the initializer. Being newer to rails I wanted to ensure I do my best to follow best practices.
I went ahead and moved all my processing classes out of the initializer as I thought it better suited in a module I created in /lib
directory. Thanks so much for your quick reply and clarification about the initializer.
Was about to post this before you closed the issue. I'll leave it here in case it helps someone else:
Ah I see, yes you can put the subscriber objects anywhere you like as long as you make it available in the initializer. For example:
# config/initializers/stripe.rb
Stripe.api_key = ENV['STRIPE_API_KEY']
require Rails.root.join('lib/customer_created')
StripeEvent.configure do |events|
events.subscribe 'customer.created', CustomerCreated.new
end
BTW I'll clean up the readme examples when I get a chance. Thanks for posting.
I'm a fairly new rails dev so maybe the answer to question is obvious to some so please bear with me.
I love the idea of how stripe_event works. Having a lot (practically all) of the legwork done for stripe events will sure save me a lot of time. Can someone help me understand though the decision to put the subscribe calls inside of an initializer?
I personally intend to send e-mails and update records based on stripe callbacks. Creating, updating, and destroying models seems like something better suited for a controller.
It works don't get me wrong. I guess I'm just wondering if performing these kind of actions in a initializer would fall into rails best practices?