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.
use mongrel and apache 2.2 with mod_proxy_balancer.
On 5/12/06, Stephane Fourdrinier - Fusemail [email protected]
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
Hi !
On May 12, 2006, at 10:53 AM, Brian H. wrote:
Views). So placing them in physically separate machines really
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 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
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?
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:
I’d prefer the first, as you aren’t limited to using Ruby clients, but
it
may be fun to try #2.
Maurice