GR8Conf 2011: Adopting Grails
1 like662 views
The document discusses adopting Grails for web application development. It summarizes several episodes or lessons learned: 1. GORM constraints were ignored when domain classes were loaded by a shared classloader rather than the Grails classloader. The constraints had to be extracted to a shared library. 2. Using BlazeDS for Flex communication caused data objects to lose field values after round trips. DTOs and mapping tools like Dozer were needed. 3. Web services should treat the UI as another automation client to avoid duplicating XML flows. Domain data can be mapped to XML in GSPs without DTOs. 4. When domain classes were no longer stored in the database, meta-
GR8Conf 2011: Adopting Grails
- 1. Adopting Grails Klaus Baumecker Hewlett-Packard
- 2. About me Klaus Baumecker Software Architect & Technologist @ Hewlett-Packard, Böblingen, Germany Professional Software Developer since 1992 Java Programmer since 12+ years Using Groovy & Grails since 3+ years 2
- 3. Introduction We started using Grails in production 2 years ago. We used Grails already for in-house projects (version 1.0.x) The following episodes show … what we’ve learned and … a few best practices derived from it. 3
- 4. Context • Large product suite for IT-Management in HP Software • Two teams developing the next release of a product – One using classic JEE approach – Other using Grails • Both web-apps share a common data model based on POJOs and Hibernate mapping files • All web-apps run inside a JBoss application server • Continuous integration builds based on maven • Time-boxed development cycles • Agile approach with features and stories (SCRUM like) 4
- 5. Episode 1 – GORM Constraints The Grails web-app uses GORM constraints to enforce rules on the domain classes There was and (and still is) a general attempt to reduce footprint by moving common web-app libraries into shared lib space therefore the shared domain model (incl. hibernate mapping) became a shared library (among others like apache-commons-*, etc) GORM constraints work fine in development (run-app), but are ignored while running production code inside JBoss 5
- 6. Episode 1 GORM constraints were part of the Grails source code (src/groovy/…) They were loaded by the web-app class loader Domain classes and mapping file have been loaded by the shared class loader (and loaded before the constraints) The shared class loader cannot access classes within the web-app (only the other way around) GORM constraints are ignored! Extract constraints and move to shared lib space 6
- 7. Episode 2 – Flex UI Demand for graphical editor has led to Flex based UIs. Communication was XML based. Then we’ve seen too many Flex timeouts. So we moved to faster communication with Blaze-DS using the BlazeDS grails-plugin. We mapped domain classes to Flex classes (Blaze feature). Better performance now, but… After a round-trip of a data object (grails - flex - grails) we got empty fields in the received object. Although there were properly set before and not modified in the UI. 7
- 8. Episode 2 Our POJO based domain classes have some protected fields (public getter, private setter). No problem for hibernate. Blaze-DS uses commons-bean utilities for mapping from/to POJOs and ignores asymmetric fields. Need DTO and some tool to define mapping. We use Dozer (dozer.org) 8
- 9. Grails with BlazeDS or not? Motivation: Optimization (High performance data transfer)!...But sometimes you really need –a different rendering strategy (partial vs. all at once) –a fix for your slow performing back end (Flex timeouts) Use cases – Event Browser for IT-Mgmt: • Large list of IT events to be viewed by an operator (> 20000 events) • Interactive operations on events (e.g. filtering, dynamic updates from the server) – More advanced client/server communication (pub/sub, push) Main issues – Another layer in your communication – No controller level (Blaze works on services directly) breaks Grails paradigm • Same with other communication extensions directly working on services (remoting plugin). • Some security plugins do not work as expected 9
- 10. Generalizing the Controller layer • Grails services w/ controller semantics Controller Other Layer HTTP BlazeDS Remoting • Avoiding redundant (transport spec.) Access authorization Services Business Layer (atomic ops, Service caller neutral) Grails Grails Transaction Controller Service Business Logic Business Business Layer (optional) Logic Services Logic Service 10
- 11. Episode 3 – Design your web services We’re using XML for most of our UI/backend communication. Our backend provides web services for UI and automation tools. The Flex guy says: Add a special attribute to the XML to make my rendering easier. Architect says: Don’t fiddle with the automation interface! How to setup my web services to fit the needs for UI and automation? 11
- 12. Episode 3 Flex = Rich UI Treat your UI as another automation client. Don’t allow UI specifics to show up in the XML. If you don’t, you’ll end up in maintaining parallel XML flows. My recommendation for XML generation • gsp.xml • Plain XML code is easy to read and maintain • No DTO required (as in BlazeDS or JAXB). Map domain data to XML inside the gsp. 12
- 13. Episode 4 – Meta Programming Due to a change of the architecture some domain classes are no longer stored in our DB. They stored with a different technique (out of our control). GORM methods are no longer available. Store and retrieval is replaced by new a persistence API incl. new DAOs We still have many consumers of the (original) classes all over the place. How to minimize refactoring? 13
- 14. Episode 4 Enhance the meta-class of the old classes by the missing GORM functions (get(..), simple finders). Meta-class methods map to the new API. Existing code remains unchanged. But do this with care! Comment your code and explain it in your tech meeting. 14
- 15. Episode 5 – Developer Support Programmers with strong Java background often feel lost with reduced IDE support. They miss(ed) code completion, static analysis, compile errors, etc. How can we reduce the whining and complaining, while moving them into the Groovy/Grails world? 15
- 16. Episode 5 Get a good IDE. Spent effort in installing analysis tools into your build. E.g. run CodeNarc analysis. Write your own CodeNarc rules according to your internal regulations and needs Own rule brought some safety back: “Finding dynamic variable”. 16
- 17. Episode 6 – Modularization with Plugins Each web-app developed services which became useful in the other web-app. Inter-web-app communication is easy to set-up but not really a solution – Architecture, security, etc. – E.g. RMI Reusing a Grails service inside a Java web-app is not straight-forward. How can we leverage functionality across multiple web-apps, keep good architecture and independent web-app development in two teams? 17
- 18. Episode 6 Grails-ify the Java web-app. Now you have two Grails apps. Extract shared services into additional Grails plugin(s). Create a new umbrella Grails app that loads the two main web-apps as plugins. The two Grails apps consume the extracted services plugins. Each of the main web-apps run independently (run- app) to keep lightweight development for each team. 18
- 19. From applications to plugins • Refactor your beans from resources.groovy to a resource location, e.g. src/java/myBeans.groovy – Watch out: • Before: “beans = {“ • After: “beans {” • For each web-app : – Refer to the new beans file within resources.groovy • Merging beans in the umbrella app – Refer to the new beans files from the underlying web-apps – Wire beans between web-apps (optional) • Add plugin descriptor • Adjust URL mapping • Merge other resources (e.g. files under web-app/) – Requires extra scripting 19
- 20. From applications to plugins (con’t) beans = { resource.groovy umbrella loadBeans(‘/beans2.groovy’) web-app loadBeans(‘/beans1.groovy’) (grails) } web-app 1 web-app 2 (java, spring, (pure grails) grailsified) resource.groovy resource.groovy beans = { src/java/beans2.groovy loadBeans(‘/beans1.groovy’) } src/java/beans1.groovy beans { <your beans here> plugin } plugin plugin plugin (shared 20 services)
- 21. Summary & Best Practices • Clearly articulate the benefits of the framework – Not just cool stuff • Reduce emotion (they know what you think anyway) • Create a local community – find the people that think like you • Use the external community and help others using it – Mailing-lists, IRC, etc. • Provide tools – IDE, static analysis, plugins • Find situations/cases in which Groovy/Grails really makes a difference – E.g grails run-app vs. classical web-app redeploy cycle with heavy app servers is a huge time saver • Stay close to the Grails sweet-spot as long as possible – E.g. Groovy domain model vs. Java domain model 21
- 22. Summary & Best Practices (cont’d) • Be available – Provide help when necessary – Don’t let the team swim alone • Offer/Initiate code reviews/pair-programming • Maintain a catalog of design principles and guidelines – HowTo(s) – Coding guidelines (e.g. use of types, inheritance vs. composition, controller and services responsibilities, XML generation strategies, Java vs. Groovy coding etc.) • Ideas: – Use the create-* scripts to introduce own templates for controllers and services – Provide own scripts for lab-specific tools 22
- 23. Thank You! Questions? 23