lunes, 3 de mayo de 2010

Front-end stack for the new project: GWT

I'm going to start the project talking about the technologies I want to use. Obviously this technological election isn't the result of a reasoned study to fix the architecture to both client and functional environment. There are no client, there are no functional study, (neither name for the project!).


Today I'm gonna talk about Front End Stack. I would like to implement the UX of the project using Google Web Toolkit, GWT, and GWT are going to comunicate the server side via REST calls to a Grais Backend.


The main difference of this election is that I already know GWT. I worked in a pretty serious GWT project for 9 months, also I'm the responsible of GWT workshops in my company, and, the most important part, I do like GWT!

One reason is that I think I'm the perfect user profile of this technology, I have a knowledge of front end techonologies such a HTML, JavaScript, CSS, but I'm far from be a good front-end programmer. I am not confortable writing jQuery (although I feel is a great technology), and with these capabilities, GWT fixed pretty well as Java tool to build Rich Client Interfaces.

As GWT is a Java tool based on a Java->HTML/Javascript compiler it main benefits are that you write the code in Java, with a strong typing, easy unit testing (i'm talking about UNIT testing), quite productive APIs (from Google, vendors and J2SE) optimization process, and component oriented programming model.

I also think GWT can be a perfect tool to embrace HTML5, using its Java-Component based encapsulation, you can easilly migrate the implementation of a component to a HTML5 one, or add new advanced components to your toolset.

But probably my favorite feature of GWT is not a feature. GWT is a tool, it's not a framework. There are a lot of frameworks in Java. Struts2, Wicket, Spring MVC, JSF,.. but you can view GWT as a tool to translate Java into Javascript. And from this tool you can build your infraestructure (your framework if you want), and this infraestructure can be quite productive.

In my nine months project with GWT, we only reach the surface of this capability using code generations tools and I have the feeling that there are not a lot people talking about building GWT tools. I would like to do some research on this field.

Another feature I wanna test is the REST integration. In our project we use GWT RPC API, with an excellent result. This API seems a bit unfashioned, its name reminds you college times, it's simillar to RMI (at least without RMIException), but it's very productive. With this API you can have tested and compiled calls, it's very simple to integrate the calls with Spring IoC container, and the problems with proxied objets can be avoided. I recommend this sollution:



But this calls are no REST-complain. In other environments you may require to do this REST calls, for example, in my project. I want to use Grails as rapid web development framework, because i also want to test it (I worked with Groovy to do some scripts a time ago), also the dynamic capabilities of the language to build something not far from business oriented language (but this is another post), and is tool and command oriented development style as a via to implement my own code-generation tools.

To do this the best option seems to be GWT Overlay types, and combine it with Model View Presenter (MVP) pattern. This pattern is also a pending task for me, In our project we use a quite rudimentary MVC that got us trouble when the project growed.


To finish the post, a great presentation on GWT, Grails, REST and MVP from Matt Raible.

No hay comentarios: