It is something that I have been wondering. When working with other application servers there is often/most of the time a 3 tiers/layers architecture: - Presentation layer/Web services - Application layer - Database layer They often resides on separate machines, 3 different sets. So the application code is logically AND physically separated from the presentation layer. Is this possible with rails? I want all my views on a set of Web servers. Then, all my controllers/models on a different set of servers, and of course the database on a 3rd layer. Anyone has done this or is it just not possible? Stephane.
on 2006-05-12 19:17
on 2006-05-12 19:33
use mongrel and apache 2.2 with mod_proxy_balancer. On 5/12/06, Stephane Fourdrinier - Fusemail <email@example.com>
on 2006-05-12 21:54
Actually, that solution really isn't any different from a distributed FastCGI deployment model. It's just based off mongrel and not FastCGI. So, that doesn't address Stephane's question. Unfortunately, I'm not sure that Stephane has asked a question that has a good answer. It might be just me, but I don't see what that kind of presentation layer separation would give you. There's also the fact that it's not possible within Rails, since the application layer (i.e. Controllers) drives the presentation layer (i.e. Views). So placing them in physically separate machines really doesn't make any sense. You'd have to have a whole separate set of code running on your presentation layer machines to handle rendering requests produced on the application layer machines. I don't see how that disconnect would provide anything worthwhile, such that it would be worth the time to try and build... -Brian
on 2006-05-12 22:27
Hi ! On May 12, 2006, at 10:53 AM, Brian H. wrote: > Views). So placing them in physically separate machines really > >> - Application layer >> >> Anyone has done this or is it just not possible? >> Stephane. > Actually rails works very well with the three tiered approach. Capistrano has the concept of web, app and db servers. THe way this breaks down if you wanted to seperate the three tiers on three machines is thus: web: this is a static asset server, like lighty or apache it serves only the static content. app: this is your rails app itself, running in fcgi's or mongrels proxied behind the web server on web db: well this one is easy, its just a separate server with a database server running on it. Now that way to ty all of these together and still be able to use page caching within rails is to share the public directory via NFS or some similar network file system. This way the web front server serves all static requests, including rails page caches. And the rails app server has access to the public dir to write out the cached html pages or image uploads. This gives you the separation of all three tiers like you wanted. ANd capistrano makes it easy to adhere to a division of labor like this. The weakest point in the whole thing is the NFS. But you can get around this with nice SAN solutions or things like mogilefs. Cheers- -Ezra
on 2006-05-12 22:47
On May 12, 2006, at 02:25 PM, Ezra Z. wrote: > > This gives you the separation of all three tiers like you wanted. > ANd capistrano makes it easy to adhere to a division of labor like > this. The weakest point in the whole thing is the NFS. But you can > get around this with nice SAN solutions or things like mogilefs. Really quickly... I agree with everything Ezra said here, but the 3- tiered approach that Rails uses doesn't map to the 3 tiers that the OP originally outlined. That's what I was trying to address in my email. The Views are still part of the application layer... -Brian
on 2006-05-12 22:59
OP should look into web services. The kind of separation she is asking about isn't usually necessary to scale. Stephanie, what is the driver for logical and physical separation of your Rails application? Just because?
on 2006-05-12 23:26
What exactly is your intention here? If your intention is to have a server running only business logic that can be shared across applications, then you shouldnt be trying to separate controllers and views, but instead separate them both from models. for example, server 1: views, controllers. server 2: models. server 3: db. Here's how you can do it: You create two applications, one that have your existing views/controllers, and another with your model. To get them to talk to each other, you have two choices: - Add a webservice layer in between, using actionwebservice or a custom REST service. Your model app could be rails-based too, here. - Use Drb (http://ruby-doc.org/stdlib/libdoc/drb/rdoc/index.html). I'd prefer the first, as you aren't limited to using Ruby clients, but it may be fun to try #2. Maurice