The easiest way to add recommendations to your Rails app: acts_as_edgy
blog.directededge.com
blog.directededge.com
The Shopify add-on is actually fairly different from the usual webservices product since it's completely usable by non-developery sorts. We handle pulling the shop's data from Shopify and spitting out Javascript that displays the recommendations, have a settings panel that shop owners use and so on.
In comparison, this is basically just glue that get's things one layer abstraction further (relative to our Ruby bindings) from having to think about the web service.
So, they're both moving away from the generality of the bindings, which are a pretty faithful mapping of the capabilities of the API, to make simplifying assumptions to make the API easier to use. But they're so different that it's difficult to compare directly.
The Shopify app is a pretty normal web app. None of its users know that there's anything API-ish about it, nor do they care. You can set weights, but only for pre-specified things:
https://skitch.com/scotchi/rw5a3/directed-edge-expressrex-fo...
There are a bunch of features of the API that aren't exposed via the Rails plugin (even a couple that are used in the Shopify app) and it does, at present, assume that you're just latching onto a preexisting model.
That said, using the Rails plugin is kind of like using a C API from C++ -- you can drop down to the lower level of abstraction if you need to. So while the plugin is, say, a minimum viable plugin at the moment, you can still get the full flexibility of the bindings at will if you're willing to trade some simplicity.
Anyhow, add me to the list of those who would be very interested in a Rail3 version.
Most of the folks I know working on Rails 2 sites have only started taking Rails 3 seriously in the last month or two and don't seem to be in a hurry to upgrade.
It'd be interesting to see a curve of when major rails deployment cut over (if they do). I wonder if there's a tell-tale Rails 3 signature that could be used combined with e.g. an 80legs crawl?
When we go to Rails 3, we'll do it all at once and it won't be in the next 3 or 4 months either ...
Also, Rails 3 - we moved over a while ago.
Shopify add-on, using the same engine (with a different face):
http://apps.shopify.com/directed-edge-expressrex
Write-up by one of our customers:
http://www.jonathanbriggs.com/ecommerce/33-of-revenue-expres...
Quora answer by an API user (at that time had already integrated, wasn't live yet):
The query they describe as 'monstrosity' is actually easy, understandable & typical stuff to do on the relational db. When I was taught CS stuff, you consciously chose relational db just because you could do things like that. If you didn't plan it, you wouldn't use such db in the first place.
My point is, why to popularize the approach that you should run away from SQL as much as possible and not tune it to your needs? Because that's what authors propose. SQL is not XX-century obsolescence and is not hard to learn. I always thought people, as me, are using ORMs to utilize some convenient coding pattern, not to be hopefully in a safe distance from all that SQL thingy. Am I so naive?
It's a business decision. More developers will use their product if it's easier to integrate. ActiveRecord acts_as_blank plugins are fairly simple to write and even easier to use.
Angry VC: Well why aren't more people using Directed Edge?
DE CEO: We could have built this plugin but we want more people to be fluent in raw SQL. It's better for the craft of CS.
I understand where you're coming from, but the benefit of using an ORM should be quite obvious in this case.
Also, I found that the more I understood about SQL, the more pleasant it was to use ActiveRecord. Sometimes its "magic" can be a pain, but when it works, it really works well. I can't help but smile when I think of all the time it's saved me.
Still this is quite sign of the times we live in. If someone's putting most of his service from the pieces hosted elsewhere, what it will be? I can say that it'll be probably sloooow ;)
Anyway I share your sentiment towards ORMs, with a little difference that I prefer data mapper (as a pattern) over active record (as a pattern). Active record locks you in the ghetto where the only primary source of the schema information are your artificially crafted ORM-dependent tables, where in data mapper the database itself can give this information to you via reflection of the "real" tables. This is priceless when dealing not only with legacy databases but also with effects of ad-hoc operational fixes, which in turn can save your production sometimes. Data mapper has got also object identities right.