I disagree but find the approach very interesting. What CMS are you
going to use? And how closely would you bind them? Would you use rails
for all db transactions, or just for specific business logic?
The reason I say this is that the kind of app I'd like to build
(accountancy app), clients would generally want it to be fully branded
and part of their website. If I used a CMS with a plugin (that's
essentially a RESTful client) they could customise (Google says I
should spell that with a 'z'!) to their heart's content. Move menu's
about, hide menus, completely change everything around. The
accountancy software itself would essentially be a web service, that
many different types of client could use. I suppose one could use
either an iframe (urgh) or some kind of lightweight proxy that just
goes as gets the HTML interface, with client specific stylesheet. But
I'm not sure that's any better. (an added, but not insurmounable,
problem in that case would be ensuring you had a continuations proxy
to support comet requests)
For the CMS (if I go this approach, big 'if') it's a toss-up between
Drupal and Joomla. Drupal, for me, has the edge though - I just find
the way it works more logical. Plus it has a built in http-client
method. Not a biggie - but nice it's there out of the box.
Basically, I just see you get so much for free with a CMS that clients
would love. Want a calender? No problem, install the module, choose a
place for it. Done in literally a few minute. I know Rails is fast,
but not that fast You can add loads of things so easily. Many
potential clients I know still use static web sites that they pay
someone just to add a news item, so they'd probably go with the CMS.
Would you maintain separate databases or adapt Rails to work with the
CMS db (possible, though to me that kind of thing always seems a
little kludgy) or the other way around?
Essentially, the CMS would be a view/controller, and the rails web app
the model. I certainly wouldn't want to keep any state in the local
CMS DB that was required in another client. I also wouldn't want the
Rails web service to work with the CMS DB, chiefly because I don't
necessarily want i on the same box, and would completely spoil the
independence anyway. I'd think of the CMS plugin as purely an client.
I could have other clients like a native app, an iphone app, even a
integrate with an Excel spreadsheet (urghh!!!). Essentially one should
be able to pick up any of those clients, and not see any difference in
the data. A bit like reading your IMAP email both in Thunderbird and
Google Mail. The only things in the CMS DB would effectively be the
the client settings.
As a sort of pros/cons, what do you think of this?:
DIrect Rails app
1) Better performance - you're running one thing. Plus it would be on
one server - I expect HTTP requests would be significantly slower than
straight ActiveRecord/DB requests.
2) Simpler setup (using only one stack, no need for PHP etc)
3) No need to upgrade the 'client'
4) Fair easy stylesheet customization
1) Not as easy to customise menus, forms etc. Could add write this
functionality yourself, but would take time. There' DRY, and then
there's DRO (don't repeat others
2) Harder to properly integrate into a clients website - or
3) Client must direct their users to a separate URL
Drupal + RESTful Rails app
1) Decoupling encourages a design that makes it easier to add other
2) Can easily add CMS plugins to add standard functionality, of which
there are hundreds.
3) Much easier to customise. Say the client doesn't want to see a menu
for x, because it's not relevant. No problem - they could probably
even do it themselves. The accounting plugin would be the client's app
- customised as much as they are willing to pay for.
1) All these client customisations could be nightmare to manage
2) New or changed features could break clients
3) Would be technically slower - they question is would it be slower
on the human scale (ie 100ms might be ten time as slow as 10ms, but
it's still only 100ms)
4) More loads on the server - assuming the CMS is on the same server.
5) More complex setup
I'm just curious. Feel free to tell me to go away if you want.
Quite the contrary - very happy someone's taken an interest! Happy to
hear any opinions.