REST Raiding. OpenRasta

on Sunday, 29 January 2012

I had very high hopes for this one. I was really, really, ready to like it. I had the preconceived idea that this was going to be the one to be chosen. But…

Get It!

I really do not want to be mean or sound (too) rant-y. But I need to tell the whole story.

Let’s face it, looks matter. Compare these two sites. If they were a web-shop, from which you would buy from? If they were a web framework, which one projects quality and care? I do not intend to be cheap, but… seriously?

 OpenRasta_Home_2 nancy_home


Ok, dodgy as it looks I bit the bullet and tried my luck finding a NuGet package. None. Nil. Zero. If you want a package, go install OpenWrap and let it take over the soul and guts from your .csproj. Not an option. Not for me, at least.
Ok, let’s find a binary download… Hitting the documentation page… Looks promising. Darn! It points to an apparently outdated source code repository. Well, it links to a list of the various repositories (and no links to them?). Fine, I know how the Web works Sad smile and how to navigate GitHub, so stop complaining already! What? No binaries? I already broke my rules with this project, that is how ready to like it I was…
Cloning a couple of repositories and for once in my life I will read the doc first, as I know these guys can get funky with the build process. Oh dear, the instructions are outdated, there is no make.bat anywhere the new source tree. Some investigation tells me it is just a shortcut for msbuild. Fire it and… what is the result? An assembly with version WTF?


Being the most mature of the contenders I was expecting documentation to be more comprehensive and a wealth blog posts about how to get started. And I was not disappointed. I have little to none complaints in the documentation are.

The Services

Or handlers as they are called in Open Rasta are the classes that give access to our resources (the snapshots of information). They are truly POCOs, not needing any parent class, interface or attribute. Just name the methods wisely (correlating to HTTP verbs) or drive the default behavior with the configuration:

Speaking of which, one of the things that caught my attention when I first saw the framework was how much it relied in configuration and how “beautiful” was the API to handle it. I still think the effort they put in having an elegant configuration API was worthy, but having seen other frameworks in which configuration is superfluous it now seems almost like a waste. An exercise of waste, nonetheless.

And precisely with configuration came the last sin I committed with the framework. I got overconfident with the usage of the API and I forgot to include the using (OpenRastaConfiguration.Manual) statement. It may not look as much, but was capital in me giving up. Because it makes nothing work with a dreadful ArgumentNullException. Swallowing my pride again I dived in the code but could not make any sense of such a complex framework in such short period of time. So I reverted to community support, which turns out to be just StackOverflow (having read that the Google Groups is dead). I cannot complain, as I got my question answered and my thanks were given in less than a week.
By that time it was too late. I had seen enough, given up and tagged the framework as not viable for this project, thanks for asking.


As one can imagine, I cannot be too happy about my time with the framework. And definitely was not the chosen one.

I tried very hard to like it. And being disappointed is partly my fault (a combination of high expectations and carelessness in reading the walkthrough).
I still believe is one the nicest frameworks to work with (once you get it up and running) with tons of places to hook up your own behavior and probably the most HTTP-friendly of them all (for example, requesting a resource in a format that is not configured, returns a proper 406 Not Acceptable code).
Their support for dependency management is kind of nice, but a bit verbose for my liking, but one can use of of the multiple hooks to have the IOC container of the month working with the framework and using all the coolness of the container for dependency registration.

Final sayings? It will be a killer framework once it settles down from the code/project/repository migrations turmoil, the new version is released and contributors fix the build and the doc. Until that happens, I won’t be getting anywhere close for production purposes.

And for pity’s sake! Include some sort of binary distribution for those that have not drunk from the OpenWrap chalice! I am not even suggesting a lame NuGet package. That would be too low, wouldn’t it? Winking smile


Sebastien Lambla said...

Point taken.

OpenWrap is the main delivery mechanism, but binaries will be provided now that there is a return of an automated build which has been worked on.

As for nuget packages, once builds are done and signed properly, there may be reduced-functionality nuget packages (aka none of the templating / autowiring and other features in the next version). Note that due to limtations in niget, there may be packages that are not available until nuget gets the proper feature set (things like full semantic versioning support, conditional dependencies and a few othrers). On a side-note, nuget takes over your csproj too these days, so that argument is gone way way away.

As for config, yes it is verbose, and it is not expected for people to do all config manually, but to provide their own convention on top of that. This will be baked-in next version as it'll help.

FYI the make.bat is now present in most repositories. As for assembly versioning, that's also being fixed, although I am still allergic to assembly versioning (for reasons explained on my blog).

Daniel González said...

Hi Sebastien,

I am very cool with the fact that OpenWrap is the main delivery mechanism. But, in my opinion, it is too much of a pre-requisite when there are no alternate ways of obtaining binaries. And the fact that a "dumbed-down" NuGet package is going to be available is great news.
I agree that NuGet can be improved a lot but, as it is today, it is perfectly usable for many, many people that do not need those "proper" features. For the record, I am looking at a .csproj of mine and I can see no traces of NuGet, save for the path to an assembly reference. I think that unless you decide to enable the "Package Restore" feature, NuGet won't change a bit of how .csproj are built.

The configuration API screw-up was solely me not paying much attention to the walk-through, being anxious to have something working after some frustration. Glad to hear that conventions are going to be built on top of it as it will make it easier to configure.

In regards of assembly versioning, I agree that it is not the nicest of the solutions. But since there is no baked-in concept of "package version" or explicit dependency management, we are all stuck with recompiling assemblies when versions change and ugly assembly redirects. But I believe not having no assembly versions is not the way to go. For instance, how would one check which version of an assembly a deployed application is using?



Jon Wingfield said...

It's really unfortunate to see a post that basically amounts to "It was too hard to learn" showing up so high on the search results for OpenRasta.

We currently have an implementation of OR in production, and it has been a joy to work with. If you're having issues related to documentation or configuration, welcome to cutting edge, open source projects :) For many, ASP.NET Web API will be the choice because "MS made it", instead of actually evaluating what the framework brings to the table, the problems it solves for you, the guidance it provides and the flexibility it allows.

Unfortunately, this post outlines none of those, and instead resorts to complaining about pain that is almost always there when choosing a new tool.

Jon Wingfield said...

It's really unfortunate to see a post that basically amounts to "It was too hard to learn" showing up so high on the search results for OpenRasta.

We currently have an implementation of OR in production, and it has been a joy to work with. If you're having issues related to documentation or configuration, welcome to cutting edge, open source projects :) For many, ASP.NET Web API will be the choice because "MS made it", instead of actually evaluating what the framework brings to the table, the problems it solves for you, the guidance it provides and the flexibility it allows.

Unfortunately, this post outlines none of those, and instead resorts to complaining about pain that is almost always there when choosing a new tool.

Daniel González said...

Hi Jon,
Thanks for taking the time to comment.

From what I had read and seen of OpenRasta my hopes were pretty high. Unfortunately, at the time of my evaluation, what I found was a pretty messy "cutting edge" OSS project that did not fail gently on me.

Comparing my experience with, for example, ServiceStack... it was night and day. Without going into the internal merits of each framework, SS binaries were easy to install and its error messages were actually useful; not mentioning the more polished website. Those are factors that I consider when evaluating a product to use for a client, OSS or otherwise.

I do appreciate the philosophy of a framework, its way of solving the problem and value its extensibility a great deal. But to get to that point I need a running site first, which I could not get for the reasons I explained: my own stupidity, the meaningless error message and a somewhat late response from the community (for which I am very thankful, mind you).

I do agree with you that majority of people would not perform any evaluation and will go "by default" towards Web API, which may be (or not) the best solution for their problems, but has a MS "seal of approval". We have seen that one before and the only thing we can do is let people know of alternatives.

Would I revisit OR next time I need a framework? Sure I will. And I am pretty confident that, by then, some of the inconveniences I faced will be solved. And I will be writing a very different post about my experience with OR. But, during my evaluation, I was not convinced that OR was the best possible solution to my problem. Is it a rant? Kind of. But it depicts my personal experience with the framework at the time of writing.

As with pain for "new" tools... I would not call OR a new tool, since it has been around for some time. Most importantly, in my opinion, tools are to relieve pains, not to give new ones. And it is definitely possible to feel very little or no pain with new tools. I reviewed Nancy (way younger than OR) and felt no pain. I evaluated Web API and, again, no pain. And neither I felt any pain with ServiceStack. Some "new" tools may result in pain; others, not so much.


Jonny Anderson said...

This is a painful comment to write as I still feel a strong residual loyalty to OpenRasta (OR), however ... The pain noticed by Daniel cannot be dismissed, the problems are not simply due to a lack of familiarity or a sanguine welcome to the razor's edge of opensource development. I know because I have spent time (and money) with Sebastien taking his REST course as well as delivering two successful projects with OR - and I think that's enough experience to get the gist, even if I am not a hard-core contributor.

The final result, in my opinion, is this: OR was almost great, and may yet be great, but it is hamstrung by the side of the tracks that spawned it, not the grotesque, flabby, Microsoft world that pays my bills, but the lean, hyper-cool, command-line world where Linux is something other than a Charlie Brown character and eidetic memories for huge strings of command line linear-B are de-rigueur.

I almost made did it. I almost stopped being a child-coder with Microsoft chocolate smeared around my mouth and became a ethically-focused, Vegan, marathon running command-line coder because OR, for a while, bridged those two worlds. But then Seb took his eye off the ball and the thing that made him great led to his downfall. He fell back into the world of black windows with strange commands, the no-mouse, no GUI world, the Essene asceticism of keyboard short cuts, and instead of continuing with OR, pushing hard to fix its verbosity and difficulties with installing and updating he wandered away. Perhaps this is how open-source is meant to work, perhaps it was now down to the acolytes to push the code forward, and for a long while I hoped so.

But I am not a source-code jockey, I want something I can install and use. And yes, I know, I should be cool with incanting my own assemblies from magical hieroglyphic streams but I am weak and I am not clever enough. I don't even know what a make.bat is - something to do with windows 3.1 if memory serves - which it doesn't usually because I have the internet.

Personally I think Seb got bored and needed a new challenge. OpenWrap was a brilliant idea but MS got there second with the inferior Nuget and, if he had not been so pure, he would have realised that his true calling was to follow through with his beautiful, but flawed, OR and thus raise himself as the RESTful saviour for coders like me- soft-palmed, dull headed coders who just don't get why icons are bad, coders who guiltily stuff their mouths with creamy Nuget packages because its so easy to right-click and 'Manage Nuget Packages' even though they know its bad, bad, bad.

Then came Nancy and once again my flesh was weak. She was just so easy. Everything worked (as it would have just worked in OR if Seb had not wandered back into the desert for more visions). The Nancy site looked great (as the OR site would have if the look of a site had any interest to hard-muscled, flinty-eyed Linux coders). And now I love her, I just can't help it, Nancy is beautiful and Nancy is improving all the time with regular updates and improvements that can be put into your project with a simple click the dirty little mouse.

I know I am wrong, I know that OR and OpenWrap are probably better, but I also think that none of that matters for the majority of middle-of-the-road coders like me, who want to impress the boss with the sites they do, who don't care about the command line, and who are happy to work with impure products as long as it makes their pathetic, grubby little lives just a little bit easier.

I am sorry Seb, I really am. I think you are great but your eye wandered and I felt unloved. I am just a poor coder and I have needs too.

Sebastien Lambla said...

You know, after many, many years working for other people's needs, I just realized that unless I have a need, I have no reason to work to fullfill other's needs. I understand that the other guys on the block do that, and that's great for them. But considering how much I've lost and spent on all this, my only answer is "send a pull request". If no one does, that's fine, the projects will disappear. Either way, I really don't care much anymore, when I need those tools I'll update the code for them, until then they're in the hands of the community.

So there you go. There's probably about 100k worth of code between all those projects, do as you wish with them, and don't feel guilty for going to those projects that have a better start page, it's understandable.

I just hope you'll all understand that I have needs too, and those do not include working for others anymore, or competing with Microsoft, or teaching, as much as I used to.

Lots of love to y'all.

Sebastien Lambla said...

On a side-note, the community has updated the web site so it's not as bad as it used to look. We're still very far off (no nuget packages from the builds), but it's a first step to everyone taking ownership of the projects they use.

Jonny Anderson said...

Hey Seb,

If you are reading this then I hope your previous comment was not influenced by the opinionated blethering of bloggers like me. You know the community holds you in very high regard and I personally think you are one of the most talented programmers around. I feel sure you wouldn't allow a bit of blog-waffle to affect something as important as your involvement in OR. I wish you only the best.