Rails - May 2006 - How to truly separate Logic from view with Rails?

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 <stephane@fourdrinier.com>
wrote:
>
> 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.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060512/28fed491/attachment-0001.html

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 May 12, 2006, at 11:32 AM, Adam Denenberg wrote:
> use mongrel and apache 2.2 with mod_proxy_balancer.
>
> On 5/12/06, Stephane Fourdrinier - Fusemail  
> <stephane@fourdrinier.com > wrote:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060512/c7d6b7e3/attachment.html

Hi !


On May 12, 2006, at 10:53 AM, Brian Hughes wrote:
>
> 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 May 12, 2006, at 11:32 AM, Adam Denenberg wrote:
>> use mongrel and apache 2.2 with mod_proxy_balancer.
>>
>> On 5/12/06, Stephane Fourdrinier - Fusemail  
>> <stephane@fourdrinier.com > wrote:
>> 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.
>

	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













-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060512/e7cd23ba/attachment.html

On May 12, 2006, at 02:25 PM, Ezra Zygmuntowicz wrote:
> 	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.
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?

On 5/12/06, Brian Hughes <brianvh@alum.dartmouth.org>
wrote:
>
> On May 12, 2006, at 02:25 PM, Ezra Zygmuntowicz wrote:
> >       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.
>
> 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
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060512/46d56280/attachment.html

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

On 5/12/06, Brian Hughes <brianvh@alum.dartmouth.org>
wrote:
>
> On May 12, 2006, at 02:25 PM, Ezra Zygmuntowicz wrote:
> >       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.
>
> 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
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


-- 
http://blog.mauricecodik.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060512/48c170bd/attachment-0001.html