integrallis / stripe_event

Stripe webhook integration for Rails applications.
https://rubygems.org/gems/stripe_event
MIT License
844 stars 104 forks source link

Question about config/initializers/stripe.rb #29

Closed jonathansimmons closed 10 years ago

jonathansimmons commented 10 years ago

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?

invisiblefunnel commented 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.

jonathansimmons commented 10 years ago

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.

jonathansimmons commented 10 years ago

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.

invisiblefunnel commented 10 years ago

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
invisiblefunnel commented 10 years ago

BTW I'll clean up the readme examples when I get a chance. Thanks for posting.