We don’t need mod_rails - we need mod_rack

April 15th, 2008

Mod rails is certainly a step in the right direction - but I think a much better idea would be to implement support for Rack.

Rack is an abstraction between Webservers and Ruby web frameworks. Thin, for example, uses this to great effect - by using Rack, Thin automatically supports tons of Ruby web frameworks out of the box:

  • Camping
  • Coset
  • Halcyon
  • Maveric
  • Merb
  • Ramaze
  • Sinatra
  • Vintage

There is also a Rails adapter to Rack (in the Thin repo)

So, wouldn’t it make more sense for the mod_rails team to work on mod_rack? Then you could upload a simple Ruby script like this to your webserver, and it would just work:

rack_app = Proc.new do |env|
[200, {”Content-Type”=>”text/html”}, “hello world!”]
end
run rack_app

Ruby, Rails | Comments | Trackback Jump to the top of this page

18 comments on “We don’t need mod_rails - we need mod_rack”

  1. 01

    +1 for mod_rack support!
    Ofcourse you can’t do as much magic for mod_rack as you can do for mod_rails, but I really don’t need the magic.

    Matthijs Langenberg at April 15th, 2008 around 8:05 am
    Jump to the top of this page
  2. 02

    Jack of all, master of none - Thats what we don’t need. 99% people would be happy with mod_rails. I wouldn’t bother about the rest 1%.

    It’s like, you not bothering about people without flash enabled browser ;-)

    Pratik at April 15th, 2008 around 8:35 am
    Jump to the top of this page
  3. 03

    Pratik:
    Well, firstly quite a few people use Merb - more than 1%.
    Don’t you agree it would be nice to have support for single script applications (like PHP) without having to require the whole of Rails. Surely this would lower the barrier to entry for newbies?
    Since Rack already abstracts the web framework I imagine it would be easier to implement Rack support then Rails support.

    maccman at April 15th, 2008 around 9:01 am
    Jump to the top of this page
  4. 04

    You probably wouldn’t wanna hear my thoughts on that. Well, I’m sure the copycat experts will come up with a clone. They’re good at it. Just a matter of time :)

    Anyways, http://izumi.plan99.net/blog/index.php/2008/03/27/passenger-and-other-ruby-frameworks/ is a nice explanation.

    Pratik at April 15th, 2008 around 9:16 am
    Jump to the top of this page
  5. 05

    mod_rails is great and I understand why they did it.

    But python has mod_wsgi not mod_django or so.

    I wish I had the knowledge to build a mod_rack.

    macournoyer at April 15th, 2008 around 9:18 am
    Jump to the top of this page
  6. 06

    yes. mod_flavor_of_the_month would surely be better than mod_worlds_most_popular_server.

    WTF at April 15th, 2008 around 9:22 am
    Jump to the top of this page
  7. 07

    WTF:
    I’m not quite sure I catch your drift.
    First of all, Rails isn’t a server - and it’s certainly not the world’s most popular one. Secondly, and most importantly, implementing support for Rack would *give* you automatic Rails integration (amongst tons of other web frameworks) - Rack isn’t a replacement for Rails.

    maccman at April 15th, 2008 around 9:46 am
    Jump to the top of this page
  8. 08

    So, what’s the next action? I’m willing to spent some hours on it.

    Matthijs Langenberg at April 15th, 2008 around 9:55 am
    Jump to the top of this page
  9. 09

    I agree that a mod_rack is a much more sustainable project. mod_rubinius is completely rack based, beta release expected at railsconf.

    Ezra at April 15th, 2008 around 12:38 pm
    Jump to the top of this page
  10. 10

    You’re right. Let’s ditch mod_rails so that people don’t have a good, easy Rails deployment solution *at all*, and let’s go back waiting for Rubinius and mod_rubinius which will hopefully be finished next (?) year, or some other pie-in-the-sky it-can-do-everything ultimate solution!

    XYZ at April 15th, 2008 around 5:55 pm
    Jump to the top of this page
  11. 11

    XYZ: So glad you agree with me. I imagine you’ve read the comment by Ezra above yours? Might give you a little inclination at when mod_rubinius will be ready.

    maccman at April 15th, 2008 around 6:04 pm
    Jump to the top of this page
  12. 12

    That’s a beta, yes. But it’s that’s still a long way from final. I’ll believe it when I see it, when it’s actually stable and easy to use.

    XYZ at April 15th, 2008 around 6:10 pm
    Jump to the top of this page
  13. 13

    Supporting Rails is far harder than supporting Rack - when they’ve already done the Rails support they’ve done all the hard lifting that’d be required to support Rack.

    I can understand why they’ve aimed for Rails, but frankly supporting Rack gives far more flexibility, ALSO for Rails users, since it’d allow things like combining two Rails apps in the same URL namespace, or layering generic Rack handlers in front of their Rails app.

    Vidar Hokstad at April 16th, 2008 around 5:37 am
    Jump to the top of this page
  14. 14

    mod_rails is the Simplest Thing That Will Work. It is freely available, so take it, fork it and make it so.

    The world will thank you for your efforts.

    Neil Wilson at April 16th, 2008 around 6:03 am
    Jump to the top of this page
  15. 15

    “Supporting Rails is far harder than supporting Rack”

    I think you’re seriously underestimating the amount of work we’ve put into this. I’m pretty sure that properly supporting Rack is harder than supporting just Rails.

    Passenger’s not just a dumb Apache-to-Rails connector. It has Rails-specific framework preloading logic (something that Rack doesn’t provide abstraction for) for improving startup time and for reducing memory usage. It has custom error pages that are tailored for Rails, which is also something that Rack doesn’t provide an abstraction for.

    Hongli Lai at April 16th, 2008 around 9:56 am
    Jump to the top of this page
  16. 16

    I don’t even know what “Rails-specific framework pre-loading logic” is supposed to mean. Startup time isn’t an issue in any proper setup - you have to take the load cost somewhere anyway, and a proper setup would have fail-over if the startup time is an issue.

    As for having custom error pages, that’s not something that’s needed. Rack certainly depends on the application providing the error pages.

    Supporting Rack involves only supporting running a Ruby app persistently and passing it a CGI style environment and taking output back out. How that could possibly be harder than customized support for Rails is beyond me.

    You say it’s not just a dumb Apache-to-Rails connector, and that in itself tells me that supporting Rack would have been easier, as “just a dumb connector” is the base that’s needed to handle Rack.

    Providing additional functionality is great if it benefits Rails and/or others, but it’d have been a far better move if the basic functionality had been more loosely coupled to the framework, as you’d have provided far more benefit to Ruby in general.

    That’s not to say that it isn’t a great project, though the dependency on Rails makes it largely irrelevant for me and any other Rubyists that don’t use Rails, which is why I’m not that excited.

    Vidar Hokstad at May 4th, 2008 around 1:06 pm
    Jump to the top of this page
  17. 17

    Vidar:
    Absolutely, and the argument is further strengthened by the work that Ezra has been doing on getting Rails to work well with Rack.
    http://brainspl.at/articles/2008/04/25/hey-rails-nice-rack

    maccman at May 4th, 2008 around 2:27 pm
    Jump to the top of this page
  18. 18

    Vidar, maccman, “Rails-specific framework pre-loading logic” is clearly explained in our architectural overview: http://www.modrails.com/documentation/Architectural%20overview.html
    It explains what it is, the motivation behind it, and how it works.

    In a nutshell: it can decrease Rails spawn time by as much as 90%. On a busy web host where spawn time is normally 25 seconds, it can be brought down to 2.5 seconds. Preloading also makes memory sharing between processes possible.

    Hongli Lai at May 8th, 2008 around 8:14 pm
    Jump to the top of this page

Leave a Reply

  •  
  •  
  •  

You can keep track of new comments to this post with the comments feed.

19yr old hacking away at Ruby on Rails and Flex

Pages

Meta