How to create web application only with ruby language and not with the
frameworks
Nike M. 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.
On 01/04/12 at 04:46am, Brian C. wrote:
app directly with webrick.
(3) So, to solve this problem, you will probably want to use Rack. Rack'Hello, world!'going for at least option (4). It gives you maximum flexibility in terms
–
Posted via http://www.ruby-forum.com/.
Nice answer, Brian.
I would also recommend giving rack a go!
On Tue, Jan 3, 2012 at 8:46 PM, Brian C. [email protected]
wrote:
app directly with webrick.
(3) So, to solve this problem, you will probably want to use Rack. Rack'Hello, world!'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
Thanks Brian
I started writing a little microframework built on top of Sinatra for
similar reasons. I got kind of fed up thinking that ruby’s harder to get
simple database-backed web apps up than something like PHP with
mysql.
So I basically built on top of ActiveSupport, ActiveModel, Sinatra and
DBI. So it really is close to the metal, and much harder to get caught
in the sea of abstraction that Rails sometimes presents me with.
The code’s on Github, and although I haven’t added docs yet I plan on
doing that this week. If you’re curious, there’s a simple 'ORM" called
LazyRecord that basically does things like #save, #destroy, #update,
etc…
code is here: https://github.com/luke-gru/studio54
LazyRecord: is in lib/lazy_record.rb
LazyController is in lib/lazy_controller.rb
main file is ‘dance.rb’, where routes are mapped, controllers are called
and responses are sent.
It’s called Studio54 because it’s like Sinatra meets Rails…
oh boy…
-Luke
2012/1/4 luke gruber [email protected]:
doing that this week. If you’re curious, there’s a simple 'ORM" called
LazyRecord that basically does things like #save, #destroy, #update,
etc…code is here: https://github.com/luke-gru/studio54
LazyRecord: is in lib/lazy_record.rb
LazyController is in lib/lazy_controller.rbmain file is ‘dance.rb’, where routes are mapped, controllers are called
and responses are sent.
Have you ever tried Camping? I haven’t had time to dig thru your code,
but I’ve got a feeling you’re reinventing it.
– Matma R.
Have you ever tried Camping? I haven’t had time to dig thru your code,
but I’ve got a feeling you’re reinventing it.– Matma R.
Yeah, the Camping code is really fun to read. Basically, Studio54 tries
to
do even less in certain areas. So, there are no migrations. Set up the
database yourself using phpmyadmin or whatever. This is how most
newcomers coming from PHP work anyway, I find. Even so, it uses DBI to
be database agnostic for queries, so if there’s a DBI driver for that
database then it should work.
Also, since all the rendering is done in a seperate file from the main
controllers, many controllers can be called from one route, which keeps
things DRY. Also, anything available in Sinatra is available in
Studio54, so all the Tilt stuff is available for views.
But yeah, it’s not very ambitious or complete, just a personal project
that I made after getting frustrated with Rails having too much
abstraction.
-Luke
Peter V. wrote in post #1039306:
"how well does the framework (or no framework) help in mitigation the
risks outlined in: http://guides.rubyonrails.org/security.html "
There is a Rack plugin which implements a bunch of protections:
https://github.com/rkh/rack-protection#readme
If you go in below this level, then you’re on your own.