ePo Builder, built with GWT
We've got another guest blog post, this time from Russell Ivanovic, Software Developer at Groundhog Software. He's here to talk about his experience building a new product using GWT.
In 2006 Groundhog Software partnered with education specialists to deliver an electronic portfolio solution. As fate would have it, GWT was released by Google during the R&D phase of this project. Groundhog recognised that, even in its infancy (version 1.0), this was a product that could deliver the usability, scalability and ease of development that we needed. A proof of concept prototype was built successfully, and after funding was secured, full scale production began.
Read MoreWe've got another guest blog post, this time from Russell Ivanovic, Software Developer at Groundhog Software. He's here to talk about his experience building a new product using GWT.
In 2006 Groundhog Software partnered with education specialists to deliver an electronic portfolio solution. As fate would have it, GWT was released by Google during the R&D phase of this project. Groundhog recognised that, even in its infancy (version 1.0), this was a product that could deliver the usability, scalability and ease of development that we needed. A proof of concept prototype was built successfully, and after funding was secured, full scale production began.
Today, Groundhog Software's solution ePo Builder is successfully deployed in a pilot of over 80 schools, catering for over 16,000+ users.
So what benefits did GWT bring to the table? Let's look at a few:
-
Scalability & Bandwidth
With over 16,000 users in the pilot phase alone, it rapidly became obvious that ePo had to be scalable. The beauty of GWT is that the client loads all of the presentation code in one hit (about 380kb) when the user first logs in. Once loaded (and cached by the browser) only very small packets of data need to go back and forth. Compare this to the traditional model of sending all your display code as well as data every time the user clicks on something, and you can quickly see how GWT saves us bandwidth, and makes it much easier to scale. This has the added advantage of making ePo 'dialup speed friendly' with none of the long page load times associated with sending your HTML code to the browser every time. This might seem trivial, until you consider that some of the most active schools on ePo share their bandwidth across many users, and are located in remote areas of Australia.
-
Focus on Usability, not Browsers and Syntax Errors
Because GWT is coded in Java and compiled to cross browser JavaScript, the ePo dev team was able to use industry leading IDEs like NetBeans and Eclipse. With compile time checking, many levels of automation, and easy re-factoring, we were able to focus on design and usability and let GWT worry about the low level details. Working in Java has one other side benefit. While ePo was initially built in GWT 1.0, it transitioned to GWT 1.1, 1.2, 1.3 and finally 1.4 without any hiccups. The compiler flagged any errors immediately at compile time, and made fixing any small API changes a breeze. Also, the compiler has been improving over time, meaning that the final ePo code shipped on 1.4 ran faster, with smaller RPC packets than the original one, without our team needing to lift a finger!
-
Easy, Light AJAX
GWT also makes AJAX easier than any other library, which makes building reusable, functional widgets a lot easier than ever before. Consider one quick example: when building ePo we wanted to create a stack panel, where many panels are in the stack, and you display one at a time. The first iteration was just a panel that hides and shows its contents, but we found the instant transitions confusing -- you click and your data disappears and is replaced by something else. So the logical choice was a 'slide' style transition. In traditional JavaScript development this would mean using a library like Dojo or Scriptaculous, each of which are extra downloads for the end user. Using GWT, Groundhog Software created an Effects framework that, once compiled, adds only 2kb to the size of the code - this is because the GWT compiler only compiles the code that you actually use. This allowed us to create a large, reusable framework for slides, fades and movements that we use across multiple projects without worrying about the overall size of the library, knowing the compiler would only take the bits we use.
-
GWT Magic - RPC and ImageBundle
This last section I've title GWT Magic, and here's why. The back end of our project uses J2EE for all of our business logic and persistence. Traditionally to hook JavaScript or Flash into this framework, you have to get fancy with either XML or JSON. With GWT, you just use the built in RPC mechanism. The beauty of this is that you can pass your value objects directly from the back end, and use them on the front end without any need for modification or serialization; GWT does all this for you. The ImageBundle is an even more impressive bit of magic. It allows you to work with all your individual images as you normally would (for buttons, logos, status indicators, etc). When you compile your code, GWT combines all of these individual images into one big image, and adds all the smarts to your code for cutting the image up on the client side (using offsets). This has one massive benefit: instead of your browser making lots of little requests for each and every image (each with their own latency) only 1 request is made. This also has the added benefit of removing the 'jumpy' effect you get in browsers when you load in lots of little images at once.
Our website has more information about ePo Builder and Groundhog Software.
