Ezra, I love merb, especially because it''s keeping the things that Rails does well and improves on things that Rails hasn''t done so well. One of my biggest pain points with Rails has become multi-app integration. A lot of web sites consist of multiple apps (e.g. a core site, a forum, a blog/cms, etc.). Doing this sort of thing is very ugly and inefficient with the current Rails structure, and I would love for merb to make multi-app integration and deployments less painful. For example, integrating a rails app with beast (another rails app) is just as cumbersome as integrating a rails app with a random php forum engine. Try to add mephisto to the mix and you''re in integrated hell - (css, js, model) duplication and (routing, SCM, environment) hacks galore. I wrote a post about what sucks about multi-app, what it might look like, and some potential pitfalls here: http://ducktyped.com/2008/1/4/the-great-ruby-web-framework-multi-app-challenge I also started a discussion on ruby-talk: http://www.ruby-forum.com/topic/137539 I just thought I''d put this out for consideration. Ben
I''ve love to see this as well. Something like http://rails-engines.org/that''s native to merb would be very helpful. -ben On Jan 5, 2008 4:54 AM, Ben <ben at ducktyped.com> wrote:> Ezra, > > I love merb, especially because it''s keeping the things that Rails does > well and improves on things that Rails hasn''t done so well. > > One of my biggest pain points with Rails has become multi-app > integration. A lot of web sites consist of multiple apps (e.g. a core > site, a forum, a blog/cms, etc.). Doing this sort of thing is very ugly > and inefficient with the current Rails structure, and I would love for > merb to make multi-app integration and deployments less painful. > > For example, integrating a rails app with beast (another rails app) is > just as cumbersome as integrating a rails app with a random php forum > engine. Try to add mephisto to the mix and you''re in integrated hell - > (css, js, model) duplication and (routing, SCM, environment) hacks galore. > > I wrote a post about what sucks about multi-app, what it might look > like, and some potential pitfalls here: > > http://ducktyped.com/2008/1/4/the-great-ruby-web-framework-multi-app-challenge > > I also started a discussion on ruby-talk: > http://www.ruby-forum.com/topic/137539 > > I just thought I''d put this out for consideration. > > Ben > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20080105/1cdd368a/attachment.html
On Sat, Jan 05, 2008 at 01:54:35PM +0100, Ben wrote:> One of my biggest pain points with Rails has become multi-app > integration. A lot of web sites consist of multiple apps (e.g. a core > site, a forum, a blog/cms, etc.). Doing this sort of thing is very ugly > and inefficient with the current Rails structure, and I would love for > merb to make multi-app integration and deployments less painful.Have you had a look at how Camping handles this? You can just do camping blog.rb foo.rb bar.rb and the three separate apps are mounted under /blog, /foo and /bar (but equally they can be run separately if you wish). Is that the sort of thing you are looking for? It uses the same DB table name convention you mention, e.g. blog_posts, foo_users. And by default, they share the same ActiveRecord DB connection.> I wrote a post about what sucks about multi-app, what it might look > like, and some potential pitfalls here: > http://ducktyped.com/2008/1/4/the-great-ruby-web-framework-multi-app-challenge"What I want is: /app1 /model /view /controller /app2 /model /view /controller" That sounds fairly like the Camping approach, as long as you don''t mind URLs of the form /app1/user/login or whatever. Actually, it''s pretty easy to configure Rails to have a path prefix like that; in that case, all you need is to run your separate apps as separate pools of mongrel processes, and configure your front-end proxy correctly, e.g /app1 -> ports 1000,1001,1002 /app2 -> ports 2000,2001,2002 /app3 -> ports 3000,3001,3002 But it sounds like you want something more tightly integrated than that - e.g. each mongrel instance able to serve all three apps, and/or all three apps sharing the same connection to the backend database. You mention "memory overhead" as a problem, and also your desire to share javascript, CSS and other resources between the apps. Personally I would argue against sharing such resources between multiple apps: it removes the flexibility to upgrade one app at a different time to another, and it introduces possibilities of apps stamping on each other (e.g. when one app decides to add its own instance methods to NilClass, all other apps will get them whether it likes them or not) But there does seem to be a case for some sort of ''middle ground'' where you have a collection of cooperating applications. However if you really want them to share things such as their authentication and authorisation (for single sign-in) then they would have to adhere to a strict interface for this shared service. Such shared services would end up, I think, being top-level plugins of some sort. Just my $0.02. Brian.
> One of my biggest pain points with Rails has become multi-app > integration.Bit off-topic, but Kirk Haines says Iowa handles multi-app integration without breaking a sweat: http://twitter.com/wyhaines/statuses/560976242 -- Giles Bowkett Podcast: http://hollywoodgrit.blogspot.com Blog: http://gilesbowkett.blogspot.com Portfolio: http://www.gilesgoatboy.org Tumblelog: http://giles.tumblr.com
Brian Candler wrote:> > But it sounds like you want something more tightly integrated than that - > e.g. each mongrel instance able to serve all three apps, and/or all three > apps sharing the same connection to the backend database. You mention > "memory overhead" as a problem, and also your desire to share javascript, > CSS and other resources between the apps. > > Personally I would argue against sharing such resources between multiple > apps: it removes the flexibility to upgrade one app at a different time to > another, and it introduces possibilities of apps stamping on each other > (e.g. when one app decides to add its own instance methods to NilClass, all > other apps will get them whether it likes them or not) > > But there does seem to be a case for some sort of ''middle ground'' where you > have a collection of cooperating applications. However if you really want > them to share things such as their authentication and authorisation (for > single sign-in) then they would have to adhere to a strict interface for > this shared service. Such shared services would end up, I think, being > top-level plugins of some sort. >The two main fixes I''d like to see compared to doing multi-app rails are: 1. Routing should be "moved up a level" so that I can address several apps from the router, rather than using the web server and static url generation hacks to interact across apps. 2. Also, I should be able to access resources across apps, e.g. I should be able to call Blog::Post.all from any other app to use those blog posts in that context without having to duplicate the model file. I think it''s fine (and perhaps advantageous) to keep most other things very loosely coupled, e.g., run separate apps in separate processes. I would still make the case that having a shared css and js infrastructure (with app specific overrides if necessary) would be helpful. JS libs and images are pretty big, and it sucks to reload them just because I''m switching apps within a site. Maybe this could be solved with a flexible asset host plugin of sorts (I haven''t thought it through). Ben
Im confused why you are asking for things that are similar to rails engines? The gem plugin architecture is more than powerfull enough to do this kind of thing is it not? Cheers Tim On 5 Jan 2008, at 16:50, ben wiseley wrote:> I''ve love to see this as well. Something like http://rails- > engines.org/ that''s native to merb would be very helpful.