On Tue, Jan 3, 2012 at 8:46 PM, Brian Candler <b.candler / pobox.com> wrote:

> Nike Mike wrote in post #1039276:
> > How to create web application only with ruby language and not with the
> > frameworks
>
> It depends what you mean 'not with the frameworks', because I think
> you're bound to use some sort of framework at some level.
>
> (1) You could write your own web server from scratch in pure Ruby. But
> then you'd be better off using webrick which is already supplied as part
> of the Ruby standard library. Google for examples of how to write a web
> app directly with webrick.
>
> (2) You could write your app using the FastCGI protocol and run it under
> mod_fcgi. But then your code needs to talk the FastCGI protocol, so
> you'll probably end up using the fcgi library to handle this for you.
>
> The trouble with (1) and (2) are that your app is hard-coupled to
> webrick or fcgi, and it can't use any of the other fine and efficient
> ruby webservers out there (e.g. mongrel, thin, unicorn, rainbows etc),
> unless you change your app to work with the specific webserver.
>
> (3) So, to solve this problem, you will probably want to use Rack. Rack
> is an adapter which maps HTTP requests to simple Ruby call(). If you
> write your app to the Rack API then it will work with any of the
> webservers listed above, and also Phusion Passenger (a.k.a. mod_rails,
> but it's really mod_rack)
>
>    # config.ru
>    MyApp = lambda { |req|
>        return [200, {"Content-Type"=>"text/html"}, "Hello world!"]
>    }
>    run MyApp
>
>    # To start, type 'rackup'. Then point web browser
>    # at http://127.0.0.1:9292/
>
> (4) That's still a pretty low-level way of writing web applications, so
> you could then look at a lightweight framework like Sinatra which sits
> on top of rack.
>
>    # hello.rb
>    require 'sinatra'
>    get '/' do
>        'Hello, world!'
>    end
>
> Very nice: map verb (get) and path (/) to ruby code to execute. Sinatra
> can also expand erb and haml templates and is easy to extend.
>
> (5) And of course there are the big frameworks like Rails, which you
> said you don't want to use, but they also just sit on top of Rack these
> days.
>
> So even if you "don't want to use a framework", I'd certainly recommend
> going for at least option (4). It gives you maximum flexibility in terms
> of options for deploying your code.
>

Very interesting.

Is there a sensible way to compare those 5 options with regard to the
criterion of "framework support for application level security". I know this
is an arbitrary measure, so in trying to make it somewhat more objective:

"how well does the framework (or no framework) help in mitigation the
risks outlined in: http://guides.rubyonrails.org/security.html "

For myself, a fundamental reason for choosing a framework (and
currently that is Rails) is the hope that it will have the main security
issues covered by default, framework security is actively monitored
and it will have a guide with best practices on how to write safe
applications on top of this framework.

Obviously simple applications will have a reduced attack surface
area, so the "lighter" frameworks may offer better security for simple
applications (lower complexity, less options for misconfiguration,
less code that can have bugs ...).

Any views on this?

Thanks,

Peter

-- 
Peter Vandenabeele
http://twitter.com/peter_v
http://rails.vandenabeele.com