Adopting Grails - GR8Conf Europe


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Adopting Grails - GR8Conf Europe

  1. 1. Adopting GrailsKlaus Baumecker Hewlett-Packard
  2. 2. About meKlaus BaumeckerSoftware Architect & Technologist @ Hewlett-Packard, Böblingen, GermanyProfessional Software Developer since 1992Java Programmer since 12+ yearsUsing Groovy & Grails since 3+ years2
  3. 3. IntroductionWe 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. 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. 5. Episode 1 – GORM ConstraintsThe Grails web-app uses GORM constraints to enforce rules on thedomain classesThere was and (and still is) a general attempt to reduce footprint bymoving 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 JBoss5
  6. 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 space6
  7. 7. Episode 2 – Flex UIDemand 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 fastercommunication 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. 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 (
  9. 9. Grails with BlazeDS or not?Motivation: Optimization (High performance data transfer)!...Butsometimes 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 expected9
  10. 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. 11. Episode 3 – Design your web servicesWe’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 myrendering 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. 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. 13. Episode 4 – Meta ProgrammingDue to a change of the architecture some domain classes are no longerstored in our DB. They stored with a different technique (out of ourcontrol).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. 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. 15. Episode 5 – Developer SupportProgrammers with strong Java background often feel lost with reducedIDE 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. 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. 17. Episode 6 – Modularization with PluginsEach web-app developed services which became useful in the otherweb-app.Inter-web-app communication is easy to set-up but not really a solution – Architecture, security, etc. – E.g. RMIReusing 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. 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. 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 scripting19
  20. 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.groovybeans = { src/java/beans2.groovy loadBeans(‘/beans1.groovy’)} src/java/beans1.groovybeans { <your beans here> plugin} plugin plugin plugin (shared20 services)
  21. 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 model21
  22. 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 tools22
  23. 23. Thank You! Questions? 23