should I use waves?

[Mathijs]

Hi all,

This is probably a hard and opinionated subject, I don't want to start
a flamewar of any kind.
I've a rails user for about 2.5 years now.
I'm quite comfortable with it, and will keep on using it for many
things (especially when 3.0 comes out), but for some smaller projects,
I'm looking for something different.

I'm evaluating 3 options. Please comment on those if you have any
information about them.
- waves
- sinatra
- ramaze

I don't have a specific use-case in mind, but since I'm moving more &
more towards rich client(ajax, comet) applications, and different
storage solutions( like couchdb ), I want a more lean-and-mean
solution which acts mostly as a authentication / validation layer,

In my experience, I found that rails is too monolitic (for now, 3.0
will change that). Not using activerecord (I like sequel for
relational stuff, couchdb for more document-like data) is a bit of a
pain for rails, as stuff like automatic routing, forms, validations
and other things won't work. Many people have done excellent work on
providing interoperability layers to ease this, but still I get the
feeling the system is working against it.
So I would like my next framework of choice to be a whole lot less
monolithic and domain-model agnostic.
I think this applies to all 3 frameworks but correct me if I'm wrong.

On the performance part:
I'm switching to ruby1.9 for newly started apps.
I think at least waves & ramaze support 1.9 at the moment (not sure
about sinatra?), but I would like to use 1.9's native threads as well.
So my choice needs to have full concurrency support.
In other words, I would like requests to be handled in threads so I
don't need to run many instances.

And architecturally:
I'm a big fan of REST. Not so much of MVC. Basically I think REST made
controllers almost obsolete. In some projects, I switched to MVP where
P stands for presenter/conductor, which basically handles the mapping
between view data/forms and Models. Stuff like multi-model forms were
handled here, among other things, as were permission-rules (which
fields are viewable/editable by current_user).
While my client-applications (javascript) became more & more powerful
and intelligent, mapping models became less needed. Also I'm mostly
just passing json back & forth, so I'm basically looking for a thin
layer between my models and client apps that handles permissions, thus
validating client requests to the model and controlling what can flow
back. Also, since the javascript application handles most view
building, I don't really need much of a view layer with lots of
helpers and templating options.

I know that ramaze wants to enforce MVC, which I don't really like.
What's waves' vision on overall architecture?

Like I said,
I'm very interested in the differences between the 3 frameworks on the
points I mentioned above.
Also overall vision of the projects is important to me (I like how
rails 2 took a firm stand on becoming restful all the way). Any
comment on overall design/architecture are very welcome.

Thanks for any information
Mathijs

[Eero Saynatkari]

Hey--

Hopefully someone will be able to address your main questions
before I find the time, but I do have a quick note:

Excerpts from bluescreen303's message of Sat Jul 18 03:11:11 +0300 2009:

> On the performance part:
> I'm switching to ruby1.9 for newly started apps.
> I think at least waves & ramaze support 1.9 at the moment (not sure
> about sinatra?), but I would like to use 1.9's native threads as well.
> So my choice needs to have full concurrency support.
> In other words, I would like requests to be handled in threads so I
> don't need to run many instances.

1.9 MRI uses a global interpreter lock, GIL. You will not be
getting full parallelism. JRuby's threading maps to JVM threads,
so theoretically you will be seeing actual parallel execution.

(Strictly speaking, all implementations including 1.8 have full
concurrency support -- but not parallelism. Yes, whoever thought
those two terms were different enough to use for the two related
components was an idiot.)

That said, 1.9 is a fine target.

Eero
--
Magic is insufficiently advanced technology.

[Daniel Yoder]

Hi Mathijs,

First, thank you for your interest in Waves. Let me try to address your questions.

This is probably a hard and opinionated subject, I don't want to start
a flamewar of any kind.

I don't think you'll find one here. I"ve never been interested in trashing the hard work of others. All the frameworks you mention are excellent. You can't go wrong. I do think Waves has some advantages, which I hope I can explain.

I don't have a specific use-case in mind, but since I'm moving more &
more towards rich client(ajax, comet) applications, and different
storage solutions( like couchdb ), I want a more lean-and-mean
solution which acts mostly as a authentication / validation layer,

The "lean and mean" solution is most likely Sinatra. I think the advantage Waves has over Sinatra is simply that it provides a lot of niceties that are not MVC specific but that you'll probably need at some point. We have a lot more flexibility, for example, in matching requests.

Put another way, Waves tries to find a balance between flexibility, code size, and power. I think Sinatra is probably more optimized for code size. I've seen Blake present several times on Sinatra and he seems to emphasize this, and, indeed, Sinatra's code base is quite compact.

In my experience, I found that rails is too monolitic (for now, 3.0
will change that). Not using activerecord (I like sequel for
relational stuff, couchdb for more document-like data) is a bit of a
pain for rails, as stuff like automatic routing, forms, validations
and other things won't work. Many people have done excellent work on
providing interoperability layers to ease this, but still I get the
feeling the system is working against it.

I would agree ... in fact, this is a large part of the motivation behind Waves. What I had hoped was going to happen was to see more of what we call Foundations and Layers ... the idea behind Waves is that you can build up an architecture more suited to rich-client, document-oriented, and/or REST-based applications without (a) having to include a lot of MVC baggage or (b) having to work around it.

So I would like my next framework of choice to be a whole lot less
monolithic and domain-model agnostic.
I think this applies to all 3 frameworks but correct me if I'm wrong.

It definitely applies to Waves. I would say it also applies to Sinatra. Ramaze I'm not sure about because I just haven't been following their work very closely lately.

On the performance part:
I'm switching to ruby1.9 for newly started apps.
I think at least waves & ramaze support 1.9 at the moment (not sure
about sinatra?), but I would like to use 1.9's native threads as well.
So my choice needs to have full concurrency support.
In other words, I would like requests to be handled in threads so I
don't need to run many instances.

I think this is a great approach. I've been amazed at some of the misinformation out there about the pros and cons of threading. I think a lot of the trouble is that MRI and YARV lack native threading support (as Eero pointed out) which offsets many of the advantages of threading and all you are left with is the share-everything headaches (synchronization, deadlocks, etc.). From that standpoint, you will definitely want to check out JRuby and follow the Rubinius work (which, oddly, Eero neglected to mention ... ? odd because he is a core developer on that project).

And architecturally:
I'm a big fan of REST. Not so much of MVC. Basically I think REST made
controllers almost obsolete. In some projects, I switched to MVP where
P stands for presenter/conductor, which basically handles the mapping
between view data/forms and Models. Stuff like multi-model forms were
handled here, among other things, as were permission-rules (which
fields are viewable/editable by current_user).

This is exactly the kind of experimentation that Waves is intended to support. If you study the MVC Foundation (start with foundations/classic.rb), you can see how we've carefully decoupled the Web framework part, per se, from any specific application architecture. You can thus roll-your-own application architecture using the same approach we've done with MVC.

We've been experimenting with a couple of REST Foundations and I've recently been working a rich-client Foundation, but these are all still in the very early stages of development. However, you can get lots of help from the folks here in the group if you go forward with Waves and are struggling to get it to do things the way you want. But that's the main point: the way YOU want. =)

While my client-applications (javascript) became more & more powerful
and intelligent, mapping models became less needed. Also I'm mostly
just passing json back & forth, so I'm basically looking for a thin
layer between my models and client apps that handles permissions, thus
validating client requests to the model and controlling what can flow
back. Also, since the javascript application handles most view
building, I don't really need much of a view layer with lots of
helpers and templating options.

At AT&T, we did a services framework (which was supposed to be REST but is only part of the way there) just using Waves as-is, exactly as you describe. That is, it mostly just returned JSON. This was done using the Compact Foundation (sort of the Waves equivalent to Sinatra) with a little bit of sugar sprinkled on top (for example, we auto-loaded resource classes to make it easy to deploy services on-the-fly).

I know that ramaze wants to enforce MVC, which I don't really like.
What's waves' vision on overall architecture?

Waves tries to "think outside the browser." On the one hand, we offer a lot more support than just using Rack directly. You can match HTTP requests with a high-degree of fidelity, manage configurations easily, and so on.  

Outside of that, Waves strives to have no opinion about application architecture, but tries hard to support whichever approach the application architect favors. Thus, for example, we have both a Compact Foundation (for apps serving rich clients) and a Classic Foundation (for people more accustomed to MVC, and as an example of how to build up a sophisticated foundation). 

Our aim is to provide at least 2-3 more Foundations "out of the box."

That said, we have put a lot of thought into ensuring that proper REST applications are possible, without compromising more conventional browser-based applications. For example, we have the ability to match against the Accept header, like this:

  on( :get, [ 'foobar' ], :accept => :xml ) { ... do something here ... }

but in cases where you need to deal with extensions and possibly browser Accept quirkiness, you can used the requested Matcher:

  on( :get, [ 'foobar' ], :requested => :xml ) { ... do something here ... }

which will match '/foobar.xml' as well as a request with an Accept header of 'application/xml'. In other words, we follow the standard, but also try to recognize that the standards aren't representative of common practice in some cases. This approach allows you to be a purist if you want to (say, if you are building a true REST API) or skirt the line (say, if you are mixing browser clients with REST clients).

Like I said,
I'm very interested in the differences between the 3 frameworks on the
points I mentioned above.

Again, I am only really qualified to talk about Waves approach. From what you are describing, I think our approach fits your requirements well.

Also overall vision of the projects is important to me (I like how
rails 2 took a firm stand on becoming restful all the way). Any
comment on overall design/architecture are very welcome.

Hopefully, I"ve addressed your questions. In addition, the Web site has several articles that might be of interest to you. Also, several of my Waves presentations are on the Confreaks Web site.

These will help give you a flavor of how Waves works:

Compact Tutorial: http://rubywaves.com/tutorial-1

Classic Tutorial: http://rubywaves.com/classic-tutorial-1

(You'll need to run Edge Waves for these to work as Waves 0.8.2 no longer runs properly with the latest version of Rack. You can just install the gem directly from GitHub. Let me know if you need any help with this. We will have an 0.8.3 gem out shortly.)

Some articles diving down on specific features, helpful especially if you want to build your own Foundation:

http://rubywaves.com/resource-oriented/

http://rubywaves.com/foundations-and-layers/

http://rubywaves.com/configurations/

Some thoughts on REST, which will give you some ideas of our architectural direction with respect to REST:

http://rubywaves.com/rest-ftw-part-1/

http://rubywaves.com/rest-ftw-part-2/

http://rubywaves.com/rest-ftw-part-3/

Presentations on Waves:

http://lsrc2008.confreaks.com/11-dan-yoder-resource-driven-web-development-with-waves.html

http://rubyconf2008.confreaks.com/waves-a-resource-oriented-framework.html

http://larubyconf2009.confreaks.com/04-apr-2009-10-10-resource-oriented-architecture-and-why-it-matters-and-how-waves-make-it-easier-dan-yoder.html

http://goruco2009.confreaks.com/30-may-2009-12-50-resource-oriented-architecture-with-waves-dan-yoder.html

Again, I think we have a pretty helpful group here, so if you have questions or run into trouble running Waves, just pop in here (or on the IRC channel #waves at freenode) and we'll do our best to get you up and running.

Thanks again for your interest!

Regards,

Dan

[Mathijs Kwik]

Hi,

I was a bit amazed by this.
I was under the impression that ruby 1.9 got rid of all bad threading
stuff (GIL).
Somehow I was tricked by the 'native threads' argument and didn't do
enough research/benchmarks by myself.
While for many applications this isn't a big issue, and fibers might
come to the rescue in other cases, I'm still disappointed.
I've been working on a message-passing architecture, to -among other
things- have clients and the server work together as equals, both
keeping a bidirectional connection to the messaging server.
Since browsers will have sockets in the near future(html5), I'm trying
this architecture (comet-like) now, using a small flash helper
(borrowed from the juggernaut project) just to handle the socket.
The messaging server itself, I did in haskell, but before going
production with anything, I wanted to move everything to 1
architecture/environment.
For messaging, heavy concurrency is a must-have, so MRI 1.9 is out of
the picture now.

Maybe it's worth looking into jruby or rubinius for me, but I've never
used anything java-ish, and I don't know if rubinius is
production-ready yet.
Also, I like the new 1.9 features (fibers, blocks accepting blocks
themselves), which I don't think are in jruby or rubinius?
Another thing I'm looking into (a bit) is the 1.9 bytecode. Extending
hotruby(proof of concept ruby19 bytecode interpreter for javascript)
is on my (way too long) list, to allow client/server to share code and
even allow passing lambdas around.
I know rubinius has some kind of bytecode. Do you know of any plans to
make those compatible (or an extension of) MRI 1.9 bytecode?

All in all, lots of questions, problems and ambitions.
Maybe it's time for me to accept
one-language/platform-to-rule-them-all is never gonna happen.

Anyway,
thanks for opening my eyes on this :)

Mathijs

[Eero Saynatkari]

Looks like Dan addressed your other questions:

Excerpts from bluescreen303's message of Sun Jul 19 21:12:15 +0300 2009:

>
> Maybe it's worth looking into jruby or rubinius for me, but I've never
> used anything java-ish, and I don't know if rubinius is
> production-ready yet.

Rubinius is not production-ready (although we are getting
*really* close.)

You do not really need to know anything about Java to run
JRuby: it is intended as essentially a drop-in replacement
of MRI. The few things you need to twiddle (CLASSPATH etc.)
are covered in the installation instructions. JRuby's perf
is pretty solidly a bit better than 1.8 and in most cases
1.9. Be aware, though, that JRuby's 1.9 "mode" is not fully
featured yet, but it will get there. The other caveat is
that JRuby does not support the MRI C extension API (but
Rubinius will), so they have ports of the most crucial C
extensions and theirs is currently the de facto reference
implementation for FFI, which may squeak you by.

> I know rubinius has some kind of bytecode. Do you know of any plans to
> make those compatible (or an extension of) MRI 1.9 bytecode?

Absolutely not. I actually expanded on this topic a bit
recently in a ruby-core thread, so peek at the archives
if you are interested!

[Mathijs Kwik]

Hi Daniel,

Thanks for your answers.
It seems to me that waves is the number one choice.
Ramaze is just to rails-like (which is not bad by itself, but when
rails 3 comes out, it will tackle its own issues I think)
Sinatra is indeed lean-and-mean, but so is writing assembly.
What I indeed want is something highly layer-able to be lean-and-mean
for stuff I don't need, but still powerful in areas I need more
powerful constructs for.
Waves' homepage has a very to-the-point line, by saying it's a rich DSL.

Your explanation, and some reading about foundations & layers got me excited.

I'm a big fan of functional languages (haskell in particular) because
they allow you to start thinking about higher-level concepts.
Downside is, that (for me) it takes a lot more time to get something
of the ground.

Layers/foundations/dsl-like way of doing things will allow me to get a
nice hybrid.
The way I want to work is a bit the same.
I try some new pattern/architecture (like MVP) and want to abstract it
away in some DSL-like way, without having to trick the system I'm
still following its chosen path.

Also the "thinking outside the browser" quote sounds cool to me.
HTML5 is gonna change a lot in the way apps _can_ be written
(especially when sockets get added) and I want to be ready to exploit
that.
Also, I've been in a few situations where my rails apps needed to
communicate to more than just browsers, and found that activeresource
(and the way REST is implemented by default) were very limiting.
I ended up with some metal apps in the end, which work ok, but to me
it feels like having 2 applications(with some sharing), while I want
to have 1 app, with different faces, depending on who it's talking to.
I'm confident the waves approach is more geared towards this.

All in all, I'm gonna do some tutorials & try some stuff on waves, and
most importantly - look into the source.

One last thing I didn't fully get:
Is waves by itself fully threadsafe? All parts/modules?
In case I do want to do some threading or even move to jruby/rubinius,
it's nice to know I just need to watch my own code :)

Thanks,
Mathijs

[Jay donnell]

I just wanted to plug jruby. We've done a number of apps in waves with jruby at at&t and it's worked out well. I've also written a few threaded apps in jruby (not web apps) using java's util.concurrent and it worked beautifully. 

Jay