My choice for this exploration was Grails. I’ve been using Java for almost ten years and it’s simply not the best choice if you want to quickly knock-up something to serve JSON. I’ve been using Groovy to suplement Java with some dynamic scripting, so Grails was an obvious choice.
I’m an Eclipse user, but for most of my Groovy work I’ve just used the plain text editing features of Eclipse. For my experiment I decided to use the Groovy and Grails features of STS (Spring Tool Suite) for Eclipse. This gives Groovy syntax highlighting, code auto-completion and understands Grails projects.
Installing the Tools
STS for Grails is available from Eclipse’s Marketplace, so installation is simple. STS doesn’t include Grails, so you need to download it seperately and point the STS configuration to it.
The test application will capture trade information for funds. The heart of this is modelling the trade. The actual fields aren’t terribly important at this stage.
I created a Grails project with STS and used Grail’s scaffolding features to auto-generate the model, views and controllers. If you have experience with Rails then this will be familiar. Coming from a Java background this can be compared with the code generation templates available in IDEs such as Eclipse and Intellij.
Previously I compared Spring Security and Apache Shiro for integration with Windows Active Directory. In that case I chose Shiro and decided to go with that again. Adding Shiro to Grails is as simple as installing the Grails plug-in and generating the default scaffolding. All that I did was hardcode an initial user name and password so we could still get into the system.
I’m interested in doing multi-tenancy where we have multiple clients hosted in the same instance. Hey, there’s a plug-in for that! Easy-peasy.
Converting to a Single Page Application
Grails is setup out-of-the-box to offer GSP (think Groovy’s answer to JSP) server-side templates for the UI rendering. Since we’re doing client-side templating with AngularJS, I added AngularJS and Twitter Bootstrap (I’m no UI guy, so some default look-n-feel is nice) to the static resources in the Grails application.
I decided to leave the existing generated JSP pages in the application and see if I could use content negotiation to logically seperate the JSP response from returning JSON for the AngularJS front-end.
Grails has a simple solution for content negotiation which I’ll show with the two responses for the sign-in controller for security:
1 2 3 4 5 6 7 8 9 10
Here we state the behaviour for the different content types:
- HTML will do the redirect to originally requested page
- JSON will send a HTTP 200 response to say the login was succesfull (calling the sendError() method feels wrong for this, I couldn’t find another way)
This requires some extra work on the client-side to get AngularJS to handle the 302, which I detailed in my last blog post.
I found Grails to be easy to setup and get a basic web application with CRUD working really quickly. Changing Grails to work in a SPA approach wasn’t much more work, though it is not the primary way of working with Grails (for now). I have seen information from grails roadmap that indicates that SPA is a style of application development that will be explicitly supported, so I look forward to what the Grails guys can do.