Best practice for organizing third-party integration code in ruby

code-organizationorganizationruby

I have a rails app. I'm writing code to integrate it with a third-party service, "Foo Bar". The integration affects many parts of the system — models, controllers, and an API wrapper.

Thus far I've been putting the integration stuff into the modules of each model and controller. So inside app/models/user/foo_bar.rb is User::FooBar, which I then include into my user model.

I have the API wrapper inside lib/foo_bar_api.rb.

It occurred to me today that perhaps I should have all my integration code in lib. So lib/foo_bar/user.rb would contain FooBar::User, which I then include in my user model.

Is there a particularly standard way of doing this, or is it 6 of one, half-dozen of another?

(p.s., this is my first programmers.stackexchange.com question — it's appropriate for here, right?)

Best Answer

I think it's a matter of preference.

I would suggest going with a FooBar::User (foo_bar/user.rb) approach. It will keep your FooBar related code closer together, and naming of the files will be more to the point. Everything user rlated will be user.rb in sperate folders. While if you'd do it the other way you'd have a lot of foo_bar.rb files.