A separate admin app, aka sharing a database between rails and camping 1

Posted by Tim Connor Thu, 28 Jun 2007 19:03:00 GMT

I realized that pretty much all of my controllers for a certain rails app were the basic rest actions + public_show and public_index. I thought about it and realized it would be easier all around if those couple actions were just spun out into a different app. Then the admin app could be pure rest, with no extra actions and the various settings that differ between the two (ssl or not, sessions on or not, login required or not, read-write or read-only database access) could be set at the app level, instead of per action. All at once my app would be much simplified, and as a bonus, more secure. And there are obvious scaling/performance benefits to splitting them up.

After getting most of the way through this, I have to say I really like camping, and doing things this way has definitely simplified both codebases. I didn’t realize how little was actually shared between the two aspects. At first I was going to try and share the model code between the two apps, and deal with the hassle of merging back and forth, or having a symlink to shared folder (I have been playing around with svk again, for my disconnected/laptop development, and that means no svn:externals – I’ll write later how I’ve decided that is mostly a useful constraint), but then I realized even my models files could be partitioned better. Some models weren’t even needed on the front-end, on the ones that were most of the relationships/associations weren’t, and on the rest most of the methods were either/or public/admin.

So all of a sudden all models (not to mention the controllers) on the front-end became, much, much slimmer, to the point of just usually just being “class ModelName < Base; end” or maybe one association or a finder or two. Obviously this is easier to test, secure, and maintain. The only hiccup was that camping assumes the possibility of multiple apps per site, and thus prefixes the app name to the table. While you could make database views named app_model, for camping to access, it was simpler to just overload and cancel out the prefixing:

module MyApp::Models
  def Base.table_name_prefix; end

As, I’ve discovered, one of the benefits of going camping is it encourages you to simplify the code – to the point of making things short one-liners. I also think that it’s helping my ruby skills to do more development outside of rails, even if it is still in a similar venue. For example, since I couldn’t figure out how to do the rails style content_for/capture and multi-yield, I had to be more creative with blocks in my partials (which, just being methods like any other view, can be called with a block – I’ll write about that later, too). Also for smaller apps, or parts of them, I really like the simplified routing/controller/link-generation trifecta. Oh, R(), how I love thee. I think Rails could actually learn a thing or two about the possible simplifications, but then again you can just use camping when rails is overkill.

Comments

Leave a comment

  1. Avatar
    JCooper about 1 year later:

    I think this is a great idea for performance, functionality, security and implementation to other apps you build… but! how should this be done? would you create an rails App then cd into it and then creat the rails AdminApp?? i have read a little about using SVN but am unformiliar with it and am a bit scared lol

    what are your suggestions i notice the links to camping… how have you found this? easy to implement easy to use?

Comments