What's the best way to manage customer extensions for a "stock" rails product.

9 views
Skip to first unread message

bretweinraub

unread,
Nov 19, 2013, 2:21:15 PM11/19/13
to dera...@googlegroups.com

So here's my question.

I have a "stock" Rails app that forms the API backbone of the Bright service.

So one thing I want to be able to do it is let the people who use the software to create their own extensions and run these inside the Bright app.

Sort of like Wordpress hooks; where they can get callbacks from Bright events and add their custom code (for us, they'll need a platinum-encrusted enterprise license for this).

So there are a few architectural options here:

 - you could go completely "multi-app" model, where the extensions live in a completely separate application.  This seems heavyweight and there's all kinds of things that have to happen, like authentication handshaking, each app presents an API to the other.  Since time is limited, I probably want to table this for more profitable times.

 - another option is to use Bundler to allow for a "group" of gems to be included, and then implement hooks straight in Ruby that get build up in maybe a Singleton class.  When the customer gems load, they hang callbacks on these singletons, and in our internal workflow we pull down the callback queue and call the handlers (probably in a batch processing queue like delayed job).

 - a third option is to put hooks in a database, and then you get event dispatch sort of like how delayed job works, where a serialized object is pulled out and a method is called.  One of the advantages is you don't need to bring the server down to change the event handlers.

Reality is, this is the kind of functionality that makes Wordpress so dominant in web app construction.  It's not exactly the Rails use case, but screw it, let's do it anyway.  I'd appreciate any ideas, opinions or anecdotes, including "you idiot; don't do that".

Best,
-bret


Reply all
Reply to author
Forward
0 new messages