We are in the process of re-engineering our software product to reflect current standards and to provide a better user experience in the frontend. Furthermore we are implementing a complete json REST api for all CRUD operations on nearly all of your objects. But this REST api is not only for 3rd party developers. We use this very REST api ourselves to program the GUI. This means that this webservice layer is the core of our own operations.
So what do we use:
1) Spring and Spring MVC for all REST and standard web calls
2) JPA for persistence
3) HTML5 and JQuery + our own JQuery Plugins
4) JSR 303 for validation
Issue 1:
Spring MVC helps us a lot with regards to JSON webservices. Not only its is quite simple to implements REST style services but it also does all the nasty json serialisation/deserialisation work in the background. We try to avoid DTOs and create our main entities straight from JSON. This is sometimes a bit tricky when you have web forms where you cant expose a full object with html fields but if something is missing, we do the rest in the backend. This creates a really light backend because in a best case scenario you have just a Spring-MVC Controller which reacts on some REST Url and then it passes the already deserialized entitiy to the DAO layer which in turn is only a thin wrapper around JPA.
Issue 2:
JPA for persistence is not really spectacular these days. In fact we do ORM since the beginning of JDO (god bless it). Our JPA entities are little beasts with a lot of annotations. We do have all the JPA annotations together with JSR 303 annotations and JSON annotations where you can control the serialisation process. Sometimes we even have XML annotations for our SOAP services. These classes are really feature monsters even though they are just entities.
Issue 3:
Now this is the part where we did the most of the work so far. We are on the way to fully use HTML5 features. This means that we do of course use HTML5 for frontend validation. We use HTML5 data attributes for controling our jQuery Plugins. The jQuery plugins we wrote are mainly in two areas. First we wrote a plugin to submit a form with JSON content in contrast to standard form-encoded beause as i said earlier, we use the same REST api as other 3rd party systems. We faced some problems with Spring when it comes to JSON data, especially the usage of BindingResult but they fixed this with upcoming 3.2. Then we write plugins which do things like confirmation boxes, info popups and more. When you first start using 3rd party plugins, you think "wow - thats great" but soon you realize that most of them are not the way you want to do things. Then you start writing your first one yourself and then you become addicted. If you wanna know why jQuery is so big, write a plugin. You will instantly know why this is a life saver. Nearly all of our plugins we write have some sort of AJAX feature built in. We tend to use data-* attributes in HTML5 to configure our plugins instead of big json objects for configuration. Very handy for web developers.
Issue 4:
JSR 303 validation is something you get for free when using Spring MVC. What you dont get for free is the interaction with backend and frontend for displaying errors. We created our own JSON structure to return errors to the frontend and render these structure always in the same way in the HTML5 frontend. This means that the backend developers have nothing more to do than annotating the entities with JSR 303 annotations. The frontend developers just need to use our own form-plugin and the result of the AJAX request will be rendered nicely in the frontend.
What does this mean?
We are of course developing a complete application framework for CRUD operations. Now people might say that its a lot easier to use a ready built app framework like play, roo, vaadin, you name it. But i tested some of them and i like freedom. They do some things quite nice but in others they fail. And if you want to start changing things in a ready-to-use framework, it can become complicated quite fast. And one thing is really important to us. We want to create a really good user experience and this means you need to use jQuery plugins (ready or custom built ones) or javascript in general. No java app framework i am aware of is using a balanced set of good frontend JS controls.
The idea to use the REST api ourselves when submitting forms or deleting entities in our GUI is not something i invented. I am sure a lot of people do this. For DELETE this is obvious, for INSERT its not that common. Most people still use form-encoded and this leads to at least more than one implementation of a SAVE method in the backend. We try to avoid that. As a result we instantly can offer a full-fledged REST api for all of our objects which makes our system very open. Our customers could built their own GUIs if they dont like ours (not very likely) but more important they could easily built other inhouse systems that interact with our logisitcs system without much problems. Here we learned our lessons from bigger companies like Twitter or the likes with big REST api's.
Previous Topic
