The Blazing Grail – Part 1
I’m not a server guy. I know just enough Java to get into trouble. I’ve paid bills writing PHP but I’ve never really felt “comfortable” with how things turned out; they worked and the client was happy so I got paid. But I often have to have things happen “back there”. I think rich clients are great; it makes sense to me (as a Rich Client Developer) to keep the logic where it happens. But sometimes that means that that happens up there on the server and I don’t always have a JavaMan handy to take care of it for me.
A short time ago a friend of mine (Ron Haberle) introduced me to Grails. And for me it sure is the holy grail. ”Convention over Configuration” makes sense to me (when, that is, I don’t have to BEAT the convention configuration into submission like using Maven with Flex projects). But for writing the simple server side logic that I’ve got to write, Grails is awesome.
Since what I do is Flash it made sense to me to get Grails setup with some kind of AMF transport. XML worked for me out of the box but what I really wanted was AMF and some of the other niceties that those technologies offer. The options I found readily available were the flex plugin (originally introduced to me when I was introduced to Grails) the GraniteDS plugin and Grails Flex Scaffold plugin.
The GraniteDS plugin seemed really great. It’s just that . . . I don’t use GraniteDS. I’m sure it’s great technology, it’s just that I have gotten familiar with BlazeDS and until there is something that I can’t do with BlazeDS that I can do with another technology I’m just not eager to spend time learning it. It seems solid and I tried very hard to get it to work but it just didn’t work out.
And the flex plugin was more of a “look what I can do!” than an actual plugin. It was also missing an important piece: Spring-Blaze integration. Since Grails is so Spring-driven it really makes sense to get the Blaze install as “springy” as possible.
The Grails Flex Scaffold plugin was definitely interesting. But I didn’t like that it (like the others actually) expected that the Flex bits were going to live in the Groovy project.
Eventually I discovered a series of great posts by Sébastien Arbogast that culminated in the creation of his own plugin for BlazeDS4. That helped me to understand what had to happen to get everything to work together. It had a fresh (perhaps a bit too fresh?) version of Blaze, Spring-Flex and it was just a step away from nicely integrating Spring Security. Another thing I liked about his approach was that his Flex project would NOT be a part of the Grails project. That’s just not how I roll. My Flex project is my Flex project. My Server project is my server project. They get together for drinks but they’re just friends; they don’t sleep together.
I actually ended up not using any plugins. Nightly builds are great to play with but I actually need to build a server that’s a LITTLE more stable. I decided to use the latest version of Blaze and Spring-Blaze library. With a little tiny bit of customization and configuration (you can’t avoid it completely) I was also able to get Spring Security to work with my services.
In the next few posts I’ll let you know how I did that! I’ve got some other things I hope to try as well as I journey through this server setup and I might get a chance to talk about those too! There are a lot of info about these topics out there but I had to bounce all over the interwebs to get all of the information I needed. So maybe this will help somebody else out there save an evening or two and jump right into their own projects.
Part 2 – Setting up Grails, installing Blaze/Spring-Blaze & creating a Flex Project to talk to it.
Part 3 – Installing the Spring Security Plugin and locking down the services.
Parts 4 through n – Facebook?, Google App Engine?
