Eignet sich Grails auch für „große“ Projekte?

In dem Blog mit dem Titel „Why use Grails“ [1] sind sehr gut die Gründe aufgeführt, die meines Erachtens für Grails sprechen. Wir setzen seit mehreren  Jahren Grails erfolgreich ein und  sind vor allem von der Schnelligkeit begeistert, mit der es möglich ist – im Vergleich zur herkömmlichen JEE Implementierung – Applikationen zu entwickeln. Dennoch entdecke ich immer wieder Artikel, die die Aussage treffen, dass sich Grails nur für „kleine“  Projekte eignet. Hier meine Meinung zu Punkten, die ich öfters lese:

• Skalierbarkeit:
  Die Skalierbarkeit von Grails-Applikationen wird des Öfteren bemängelt. Natürlich gibt es sehr viele Beispiele von Vorzeigeprojekten [2] bei denen es offensichtlich keine Probleme gab. Grails ist wie jedes andere Web Framework für eine gute Skalierbarkeit entworfen worden. In Grails selbst können natürlich – wie bei jeder anderen Software – auch Bugs enthalten sein. So ist im Zusammenhang mit Performanz ein Tag-Lib-Problem bei Grails bekannt geworden,  dies wurde inzwischen gefixt.
  Es kann nur empfohlen werden, schon während der Entwicklung Lasttests durchzuführen, um die Architektur auf Skalierbarkeitsaspekte hin zu überprüfen. Dies machen wir auch bei herkömmlichen JEE-Applikationen, die wir neben Grails auch noch mit JEE (JPA, EJBs, Servlets, JSPs, JSF etc.) entwickeln.  Auch bei klassischen JEE-Applikationen mussten wir  schon des Öfteren unseren Sourcecode umbauen, da die anfängliche Implementierung nicht performant genug war. Da Grails auf Spring und Hibernate basiert, sollte sich immer ein Weg finden, um die Performanz zu optimieren. Notfalls direkt mit Java beziehungsweise Hibernate.
• Testbarkeit:
  Hier wird oft bemängelt, dass eine Grails Applikation nicht so einfach zu testen sei, da Groovy benutzt wird. Groovy ist eine dynamische Sprache und somit können Fehler erst zur Laufzeit auffallen, da hier – nicht wie bei Java – schon während  der Compilierung etwaige Probleme gefunden werden können. Grails bringt schon von Haus aus die Möglichkeit mit, JUnit-Tests zu entwickeln. Eine weitere Möglichkeit stellt das Tool Cobertura dar, mit dem es möglich ist, die Test-Coverage des Source-Codes zu bestimmen. Hier sei vielleicht folgender Blog [3] zu empfehlen. Benötigen Teile des Systems eine 100% Test-Coverage so können diese auch in Java entwickelt werden. Ein weiterer Punkt sollte nicht vergessen werden – mit Groovy wird ein kompakterer Code geschrieben, demzufolge sollte dieser auch weniger Fehler enthalten.
• Teamgröße:
  Ich habe neulich in einem Blog gelesen, dass Grails nicht für Teams > 5 Programmierer geeignet ist. Diese Aussage ist mir vollkommen schleierhaft. Geht man bei Grails von einer Produktivitätssteigerung vom 3-4 fachen – im Vergleich zu einem JEE Team – aus, so würde ein 5 Mann starkes Grails-Team ein 15-20 Mann starkes JEE Team ersetzten. Dies ist schon eine Teamgröße, mit der sich etwas bewerkstelligen lässt. Soll von noch größeren Teams ausgegangen werden, so ist es wohl immer auch eine Frage des Projektmanagers und des Architekten, wie so ein Projekt in Module aufgeteilt wird, die dann von den einzelnen Teams implementiert werden können. Bei Grails könnte man sich auch vorstellen, solche Module in Form von Plugins abzubilden.  Des Weiteren ist meiner Meinung nach die von Grails vorgegebene Projektstruktur ein klarer Pluspunkt, insbesondere wenn bedacht wird, dass es einfacher wird neue Entwickler in das Team zu integrieren, da einem Grails-Entwickler diese Struktur bekannt ist und er sich nicht in eine neue Struktur einarbeiten muss.
• Komplexität:
  Ein großer Vorteil von Grails ist das Paradigma „Convention over Configuration“.  Dies kann jedoch auch den Eindruck erwecken, dass nicht hochkomplexe Applikationen erstellbar sind, da man nicht alle Freiheitsgrade wie bei JEE vorfindet. Generell gilt auch hier, dass alles, was mit Spring/Hibernate funktioniert auch mit Grails funktioniert. Wird seitens des Projekts jedoch die Unterstützung von EJBs gefordert so muss der JEE Weg beschritten werden.
• JEE  6:
  Durch die Einführung von JEE 6 wird auch häufig diskutiert, ob es noch Frameworks wie Grails bedarf. JEE 6 stellt gegenüber seinem Vorgänger klare Verbesserungen – beispielsweise durch die Einführung des Paradigma „Convention over Configuration“ – dar, jedoch muss man JEE 6 mit dem Gesamtpaket von Grails [1] vergleichen. Meine Meinung  hier ist, dass Grails hier immer noch einige interessante Vorteile bietet. Hierbei zählt für mich auch die Sprache Groovy.

Fazit

Ich hoffe, es ist mir gelungen, ein paar Vorurteile gegenüber dem Einsatz von Grails bei „großen“ Projekten aus dem Weg zu räumen. Dennoch möchte ich mich hier auch nicht festlegen, was der Königsweg ist. Dies muss für jedes Projekt erneut entschieden werden. Aber gerade für Projekte, die sehr budgetsensitiv sind, führt meines Erachtens kein Weg an Grails vorbei. Früher hätte man JEE (oder genauer J2EE) auch nicht zugetraut, dass auf dieser Plattform einmal geschäftskritische Applikationen laufen.

Links