Saturday, September 20, 2008

Return of the WaveMaker

I had reason to pick up WaveMaker again recently for a customer project. I knew that a version 4 had been released and had been meaning to check it out for a while, but I had a lot of other things calling my attention all the time.

As you might remember WaveMaker is a web-based IDE which let you drag and drop a nice UI and connect tables, trees and other things to backend services, like databases, web services and even POJO Java classes. And this in itself is nice, but the big deal is that everything is done with very few clicks in the IDE, it's all running from your own local machine (if you want, you might have a separate development machine for this, but it's in your control, is what I mean) and it produces a stand-alone WAR file that you can drop into JBoss or Tomcat or whatever to get your stuff up and running.

I really like RAD, when it works. WaveMaker had some problems in the 3.x release in making connections between UI components and backend services easy to understand, and this has thankfully become much better in the 4.x release.

Still, WaveMaker has two major drabacks, for me;

1) It has no cloud. OK, this is wildly unfair, I know. But I'm comparing against GAE, and possible Jaxer all the time. What hapens if I manage to build something that has to support millions of request? Do I have to wrestle AWS again? Argh!

2) It requires Java to runt the backend. Custom logic can thankfully be done in any language, as long as it exposed as any (almost) kind of web service, WSDL, RESTish, et.c, but the server is done in Java, and require a container. What would be very nice is if you could separate the excellent front-end IDE from the services it depends on from the backend, and build alternate backends. Maybe a python backend? ?? ?? :)

I've been looking at ways to use WaveMaker with SSJS (Server-Side JavaScript) the last days, on my off time, and it is definitely doable. I donwloaded the Rhino jar from Mozilla, which is the standard Java-based JavaScript engine (http://www.mozilla.org/rhino/download.html), and put it in the lib directory in my WaveMaker project folder. Then I copied and pasted one of the examples which comes along with Rhino that shows how to evaluate a Java String as JavaScript, into the WaveMaker Wizard which help you create new services from a simple POJO. And it compiled and smiled, just like that :)

The next step is to make it do something useful, and to tie the output of the service to an UI component, maybe a textfield, to see that it works. And what we have then is a DIY SSJS in conjunction with WaveMaker's excellent frontend. Since WM has a well defined server-side Java ASPI as well, exposing those objects to JavaScript should be fairly easy, since you'd probably want to interact with it at some point.

Then I got thinking about possible backend alternatives again, and noticed that Kris Zyp's SSJS persevere framework has been accepted into the Dojo foundation. Persevere is really cool, but has no IDE as such, and depend on the developer knowing well how to consume RESTish webs ervices from a JavaScript(Ajax client, very close to TSA/SOFEA ideals :)

What it has in spades is database rubberification and exposal through REST services. It can connect to a number of different databases, and present all actions (even schema modifications and table management) in the same kind of REST metaphor as you would present adding a new row or modfying a column.

Persevere has a lot of feature overlap with WaveMakers backend, but that's really very positive, since there's not so much more to add (I hope :). Unfortunately, Persevere also require a Java backend, running on Rhino itself, but it could still be a nice addition.

Possibly, WaveMaker could also add a SMD (Simple Method Descripton) web service generation to the list of existing services it can consume, which would make Persevere melt right in.

What I would really want is a SSJS cloud which is toolkit agnostic, with the WaveMaker IDE as ... well, IDE and management console. The current contenders for the SSJS cloud throne are mostly (10gen, for example) forcing their own platform, and making it impossible to import JavaScript from other sources (Say, Dojo). Or if not, they force you to whip out your credit-card before getting any access (Jaxer).

I think it's really sad that Jaxer does not provide a free entry-level poking-around alternative for their cloud. Google App Engine (OK, quite some more resources) and others can do it, and it really feels like a bad slice of an otherwise gorgeous apple pie.

I began with praising WaveMaker, then being unreasonable with them, then yammered at the state of SSJS in general. Coherent? Certainly not! :) Also, I really like Jaxer as well, but I think that they really should not push away customers like that. Everything else point in the other direction(I.e. really cool and very interesting), so not giving people the opportunity to check out the wares before ponying up (The amount is insignificant, actually, from this point of view) feels wrong.

Cheers,
PS

4 comments:

eh said...

(Note: I'm the CTO of 10gen)

The 10gen ssjs platform is completely toolkit agnostic.
in our admin apps and apps we've written we use yui, dojo and prototype, among others.

Do you mean server side framework? We do have our own, but are also working on making it easy for making any other application framework work on top of our application server/database platform.

Peter Svensson said...

Hi eh!
That's great news! I did a lot of digging around the APIs a month or so ago and could find no way at all that I could load Dojo, for example. This is very good news :-)= . I'll go dig some more.

Cheers,
PS

Christopher Keene said...

Peter - thanks for your posting and also for digging into supporting SSJS in WaveMaker. For us, the ideal would be to keep our Java services (Spring/Hibernate/Dojo) and wrapper them so they could be consumed by Rhino functions. Would that work for you? A big part of our value prop for corporate users is that they trust tested server side components like Spring et al. If we could make these services available to server-side javascript, that seems like the best of both worlds

Peter Svensson said...

@christopher keene:

Absolutely. The more I think about it, this makes better sense. The JVM is very well supported, and if it would be possible to find a simple App Engine-level simple cloud for it, then that would be great.

Also, using the Java scripting standard, you could add in additional languages after JavaScript, like Ruby and Python. Once the first scripting interface to WaveMaker backend services is done, it will be much simpler to do the same thing for the next language.

Cheers,
PS