Grails - Gral eller dodo?

jeg prøvede Grails for et stykke tid siden, til et projekt jeg skulle lave.
Systemet køre på Google app engine, men fandt hurtig ud af at Grails er ret lang tid om at starte op. Så hvis man var den første bruger der kom ind på siden, og den skulle starte en ny instans, tog det et minuts tid før der kom svare fra serveren.

Idéen bag Grails kan jeg nu godt li, så håber at de engang i fremtiden får det til at blive lidt hurtigere.

På det sidste har jeg haft kik på Jersey som også virker meget lovene (slev om det ikke er et fuldblods web framework som Grails er det).

Jeg har forladt javaverdenen for mange år siden, så Grails kan jeg ikke tale med om, men jeg ved at dodoen hedder dronte på dansk.

Et andet godt bud: http://www.playframework.org/

Det rammer efter min mening en god balance imellem kompleksitet og "goodness".

Jeg er meget glad for Grails. I vores firma har vi brugt Grails til en del
projekter efterhånden, både interne og hos kunder.

Den helt store fordel er at man er langt mere produktiv med Grails/Groovy
end med f.eks. Struts eller SEAM.

Den største ulempe er efter min mening at IDE support for Groovy stadig
ikke er på højde med Java. Springsource Tool Suite bliver bedre hver
måned og er efterhånden temmelig godt, men der er et stykke vej endnu.

Nu er det jo VMWare der er bag Grails og det lader til at det har rimelig
høj prioritet. Grails 2 kommer snart med mange forbedringer, STS bliver
hele tiden forbedret og Cloud Foundry gør det meget nemt at drifte
Grails applikationer.

Når man først har lavet et par projekter i Grails bliver man meget træt
når man skal arbejde i ren Java. :-)

Det er svært at sige, hvor mange der er i Danmark.. På linkedin kan man se at Groovy/Grails skills vokser rigtig meget og konferencen Gr8conf (http://www.gr8conf.org/) er også godt besøgt.

Det er en kæmpe fordel at kende Hibernate da Grails ORM (GORM) er baseret på Hibernate. Når man konfigurerer den eller får sære exceptions er det noget nemmere at forstå når man kender Hibernate.

I GORM er verden bare lidt simplere:

class User {
String name
}

new User(name: 'test').save()

assert User.findByName('test').name == 'test'

Ting går lidt hurtigere end i Java.

De mange plugins er også en kæmpe fordel. Skal man bruge authentication, jquery, sende mails eller andet er det bare at installere et plugin.

Jeg synes den officielle userguide er rigtig god: http://grails.org/doc/latest/

Vi bruger Grails og Groovy som hjørnestenen i vores virksomhed - og har gjort det gennem de sidste tre år. Udover egne projekter, er vi bekendt med specifikke projekter hos to store spillere på det finansielle marked.
Der er desuden gode undervisningsmuligheder hos et par af de større virksomheder i den boldgade - ligesom vi tilbyder undervisning og “assistance” selv (shameless plug - sorry!)

Der hvor Grails virkeligt skinner ift. andre frameworks er, at det bygger på en gennemprøvet teknologistak; herunder Spring, Hibernate og Sitemesh. Man tilbydes i princippet blot en nemmere måde at bruge kendt teknologi på. Man har derudover også adgang til de underliggende teknologier, hvis man ikke er helt tilfreds med det tilbudte.

“Convention over configuration” ideen gør at ting går ikke bare lidt hurtigere, men de går MEGET hurtigere!
Hvis man kender Java i forvejen, har læringskurven nærmest ingen hældning. Vores seneste ansatte, havde ikke hørt om hverken Groovy eller Grails da vi kontaktede ham, og han comittede kode, der gik i produktion på fjerde dagen... Nuff said?!

Jeg er i øvrigt enig med @Michael i, at dokumentationen er formidabel. Miljøet (mailinglister og fora) omkring både Groovy og Grails er desuden meget venligt - også overfor begyndere.

Indlægget blev lidt længere end planlagt og jeg har ikke fortalt en brøkdel... well, hvis nogen vil høre mere, er I altid velkomne til at smide mig en mail.

Brian Johnsen
Gennemtænkt IT

Helt enig - hos Tradeshift bruger vi også Grails til vores UI (GORM bruger vi ikke pga en REST-drevet backend), og selvom det ikke er specielt let at finde folk med specifik Grails-erfaring, så er skiftet fra et nærmest vilkårligt Java-framework meget lille.

En af de helt store fordele ved Grails er efter min mening at det er så simpelt - det er (for det meste) let at gennemskue hvad der ender hvor, og hvordan man får rettet i en bestemt side, og det tillader også at html/css-folk retter direkte i templates uden særlig meget introduktion til resten af systemet. Derudover er det jo Groovy, hvilket er et meget fint sprog til frontendudvikling (og hvis man har noget der ikke er gennemskueligt i sit Grails-baserede system, så er det formentligt på grund af Groovy-magi rundt omkring). På trods af at det er Groovy er Grails overraskende hurtigt, og når man udvikler reloades det meste automatisk på ca 1 sekund, hvilket er ganske forfriskende i forhold til andre Java-baserede frameworks.

Kombiner det i øvrigt med Spock/Geb og få et test-setup der tager lang tid at slå.

Vi benytter og har benyttet Grails i lang tid, både til produkter og for kunder (også offentlige).
Det har en temmelig flad indlæringskurve og tilgangen er nem.
Grails 2 kommer med både db-migrations og multi datasource support.
Det er virkeligt afprøvede teknologier der ligger under (Spring, Hibernate, Sitemesh osv.)

Jeg ved ikke hvor mange udviklere der er, men der kommer hele tiden flere og flere. At man kan bygge WAR's af sit projekt og deployere til en standard App Server, er ydermere en fordel.

JEE standarderne er sådan set fine nok, men de er for kluntede at arbejde med, så der introduceres en masse fejl undervejs. Ikke mindst er man meget lidt produktiv på en ren JEE stak set i forhold til Grails.

Groovy som sprog er super stærkt, derfor er det også benyttet i en del andre produkter som JBoss SOA Platform (JBoss ESB, jBPM osv.).
At komme til et Java projekt er idag en ørkenvandring, og så vidt muligt får jeg proppet Groovy ind i projektet hvor jeg kan.

Det jeg har svært ved at forstå, er hvorfor en masse kunder holder fast i at man ved nyudvikling SKAL benytte nogle rammeværker som er 5 år gamle, for det var dem man engang satte sig fast på. Hvorfor ikke høste fugterne af innovationen på markedet, og gøre det hele billigere for sig selv (jeg ved godt at variation skaber øgede omkostninger - men det gør stagnation også, og er langt farligere på lang sigt).
At kunne benytte sig af ny (og velafprøvet) teknologi, er et signal om at det er ok at blive klogere. At holde folk fast i Java 1.4 eller Java 5, er et signal om at man ikke ønsker udvikling på dette område, implicit af disse folk.
Det er jeg meget imod.

I min konsulent virksomhed er vi desværre kun et par stykker(ca. 5%) der har direkte erfaring med Groovy/Grails projekter i produktion. Når jeg skriver desværre er det fordi vi møder denne teknologi mere og mere hos vor kunder. Og tak for det.

Jeg er meget glad for de projekter vi har gennemført med Grails. Hvis jeg skulle pege på en enkelt ting til forskel fra et “normalt” Java enterprise projekt er det nok er der er en masse ting man ikke behøver at tage stilling til. Hvilket er meget befriende.

Jeg vil også gerne lufte den påstand at Grails er langt billigere i drift end et traditionelt Java projekt. fx er cross cutting concerns som bruger rettigheder og rollestyring, progressiv support meget nemmere og skrevet i deklarativ groovy kode. LOC er ca. en 1/4 del. :-)

Sidste ting er at vi har en forrygende Grovvy/Grails konference i København hvor næste alle der committer til teknoligen kan findes.: http://www.gr8conf.org

Samme artikel og samme spørgsmål kan vel stilles om Scala?

Der hedder det bare Lift (hvis man vil sammenligne med Grails) og det er næppe særlig modent. Desuden benytter det vist ikke de teknologier (hibernate & spring) som Grails gør, og som allerede er vidt accepteret.
Med Lift tror jeg man skal gøre et større stykke arbejde for at få det ind? Dog er jeg slet ikke imod det, og tror også på det i længeden. Men der er stor forskel. Groovy er et dynamisk sprog. Scala er et strengt typet sprog.

Jeg synes personligt at type systemet i Scala er meget ufleksibelt at arbejde med.

ngående fejlfinding er jeg nok mere over i den stærkt typede grøft - det må da være sværere at fejlfinde i et dynamisk sprog end et stærk typet sprog, ikke?

Nej det er det faktisk ikke.
Fordelene er en super hurtig platform (sammenlignet med diverse JEE løsninger - JBoss AS, WebLogic, WebSphere osv.)
Derudover kommer at JEE i høj grad også er dynamisk på runtime.
Grails bygger på best practices, dvs. unit tests skal der til. Men et JEE eventyr uden unit tests er også en noget tåget affære.
Grails har tilmed integration tests, som bootstrapper container (på sekunder), så du virkelig kan sørge for at vedligeholdelse på lang sigt er "a bliss".
Skulle der være noget skidt at sige om Grails/Rails/Lift, er det at der ikke er alternativer på henholdvis Groovy/Ruby/Scala (PHP, Python, Perl osv. har deres egne ligende frameworks), fronterne, så der er ikke nogen egentlig konkurrence.
Grails 2.0 er et stort skridt fremad for Grails, men ikke sammenlignet med Rails f.eks. Ligeså sidder Lift lidt tilbage.
Fælles for alle frameworks er dog at de kan afvikles på JVM i en container som f.eks. Glassfish.
Man kan også kigge på Sinatra/Grafitti hvis man synes den stil er super.
Ligesom Haml/Sass er værd at samle op.

Men hvad med et gæt på levetid - hvor lang fremtid har Grails foran sig 2, 5 eller (uha) 10 år?

Det er ikke til at sige, men det er klart (for mig) at alting har en begrænset levetid. Hvor lang tid ved jeg ikke, men jeg vil mene den i hvert fald er over 2 år. Om den er 10 år tja. Struts 1 er jo ikek død endnu :) Der er stadigt folk her hvor jeg pt. arbejder der laver Struts 1.2 udvikling med Apache Beehive 1.0 (WebLogic Portal 9.2)

Og der er som kunde nogle aspekter, som man skal være ekstra opmærksom på at få dokumenteret ved et Grails-projekt?

Man skal sørge for at der ikke bliver kodet Java, men Groovy i et Grails projekt. Ligesom der ikke skal kodes C i Java. Det er en hurdle for mange.
Ja man skal dokumentere hvad der er af config settings. Specielt når man laver externalized config, som bruges når man let vil flytte mellem miljøer, og have den del adskilt i versionsstyring.
Ligesom man skal sørge for at have styr på dependencies (det skal man altid, og god CM practice). Det betyder noget hvilken WS stak man f.eks. benytter osv. Altså plugin der er benyttet, og hvorledes man har valgt at designe omkring dem.

Jeg har også lavet Groovy services deployeret til service bus, og det er lige før dette giver endnu mere mening. Grails har suveræn indbygget support for XML (Scala har også XML support, men jeg bryder mig ikke om tags i source code - det er en super grim syntax). Opslag i DB er nemt og virkelig læsbart og vedligeholdelsesvenligt.

Valgene i Grails er færre end i traditionel JEE, da der en masse konventioner man benytter. Derfor mener jeg at dokumentationsbyrden bliver mindre. En del af dokumentationen er allerede skrevet i form af konventionerne.
Traditionelle JEE løsninger mangler i den grad dokumentation, fordi der er lavet så mange valg væk fra standardernes intentioner, enten af uvidenhed, eller simpelthen for at få det til at virke. Og til sidst fordi dokumentation er kedeligt.

Jeg vil også gerne slå et slag for Play! Det er stateless og fuldt MVC, kompilerer on-the-fly og bruger hibernate helt transparent.

Det har virkelig givet mig et nyt syn på Java både som webprogrammeringssprog - men også generelt.

Ift. problemløsning og ting man ellers skal være opmærksomme på, så kommer det nok meget an på projektet. Ting vi har været nødt til at arbejde mere med, end vi lige havde troet, er i18n (vi kører via gettext), herunder korrekt inddatering/visning af datoer og tal, form binding (som især kan være lidt sjovt når man ikke bruger Hibernate), fejlhåndtering, webflow (som er et fantastisk framework, det fungerer bare lidt underligt i Grails og er temmelig udokumenteret), Javascript-integration (vi har en meget kraftig adskillelse mellem html og Javascript, så native Grails-komponenter er ikke gode nok). Generelt er der mange plugins der gør alt muligt godt, men ofte viser det sig, at de gør det på en lidt anden måde end man lige havde forestillet sig (eller der er andre spændende issues - fx at to plugins importerer to forskellige versioner af et library hvor de to versioner er ikke kompatible, eller at de bare ikke er testede ordentligt - i18n-gettext viste sig fx at have et gevaldigt memory leak).

I fejlfindingen er det især fejl i GSP-sider der driller. En NPE ledsages fx af et stacktrace, men det fremgår ikke hvor i GSP-siden problemet eksisterer (og det er i øvrigt heller ikke tydeligt for alle, hvilken template det overhovedet drejer sig om). I forhold til gennemskuelighed, så gælder der samme principper som altid: Lad være med at gøre noget mere kompliceret end nødvendigt, og lad være med at gøgle for meget rundt med metaclasses (selvom det er ualmindeligt rart at man lige kan patche et defekt framework med et par linjer i Bootstrap.groovy).

Som tidligere nævnt så er Tradeshifts frontend bygget på Grails, men vi har en Java-drevet backend, og derfor er vi nok ikke helt så mærkede af Groovys dynamik. Det betyder også at vi tester backend med god gammeldags JUnit-drevet BDD, mens frontenden næsten udelukkende testes via Geb/Spock. Det skal dog siges, at vi også på backenden bruger Groovy som DSL-sprog i forbindelse med konfiguration og valideringsregler, og at vi også bruger Groovys XML-support til XML-transformationer i stedet for XSLT.

> nogle aspekter, som man skal være ekstra opmærksom på ved et Grails-projekt?

Super svar overover.. :-)

Efter min mening er den "mentale model" den største udfordring ved overgang mellem et traditionelt Java Webprojekt og Grails. Lad ikke din Java afdeling starte op på grails uden at sikre en stærk mentor ordning der kan drive mange gamle vaner ud af dagligdagen, fx "typed or not" :-)

Du arbejder stadigt i Rambøll ikke?
Vi har for ca. 1 år siden og frem (ca. 3-4 mdr.) lavet en Grails løsning for en offentlig kunde, som driftes hos Rambøll. Vi kunne mødes og du kunne få lidt mere indsigt i vores samarbejde med Rambøll omkring projektet.
Rambøll har været særdeles glade for løsningen og driftsmæssigt, da den har vist sig at være super nem at drifte.

Derudover har vi pt. et produkt som vi sælger der er lavet i Grails.

Du kan kontakte mig på nbj<kanelbulla>nineconsult.dk