Create web application using ruby not with frameworks

ruby-talk
1

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.

If you were thinking of something which would run erb directly, so your
pages are HTML with ruby embedded (like PHP), then don't. Nobody does
this any more, and the options for doing it are unmaintained and likely
to make you hate yourself and/or ruby if you try them.

Regards,

Brian.

···

--
Posted via http://www.ruby-forum.com/\.

2

Nice answer, Brian.

I would also recommend giving rack a go!

···

On 01/04/12 at 04:46am, Brian Candler 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.

If you were thinking of something which would run erb directly, so your
pages are HTML with ruby embedded (like PHP), then don't. Nobody does
this any more, and the options for doing it are unmaintained and likely
to make you hate yourself and/or ruby if you try them.

Regards,

Brian.

--
Posted via http://www.ruby-forum.com/\.

3

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

···

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.

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

4

Peter Vandenabeele wrote in post #1039306:

"how well does the framework (or no framework) help in mitigation the
risks outlined in: Securing Rails Applications — Ruby on Rails Guides "

There is a Rack plugin which implements a bunch of protections:

If you go in below this level, then you're on your own.

···

--
Posted via http://www.ruby-forum.com/\.