Merb mal genauer betrachtet

Vor einiger Zeit habe ich mal eine kleine Liste von Rails-Alternative zusammengestellt und mir dieses Wochenende die Zeit genommen, mich mal genauer umzusehen. Durch einen Artikel auf Ruby Inside bin ich auf Waves gestoßen, welches den Anspruch hat, “the next-generation framework” zu werden. Ob dem nun wirklich so ist sei mal dahingestellt, Fakt ist aber, dass sich aktuell etwas bewegt und rechts und links von Rails interessante neue Alternativen entstehen.

Die Kernbestreben dabei sind immer, thread-safe und leichtgewichtiger als Rails zu sein - womöglich auch noch ohne unnötige Abhängigkeiten wie beispielsweise bei der Wahl des ORM-Layers oder der Templating-Engine einzuführen. Da ich in letzter Zeit immer mehr darüber gelesen habe, stand es nun mal an, mir Merb genauer anzugucken. Dazu hier ein paar Gedanken und Verweise auf weitere Quellen dazu.

A closer look at Merb

Merb startete ursprünglich mit dem Bestreben, als Handler für thread-safe Datei-Upload zu dienen und ist mittlerweile zu einem eigenständigen Framework geworden, was sich ganz klar an Rails orientiert, aber an bestimmten Stellen die in den letzten Jahren durch Rails gewonnenen Erfahrungen ausnutzt und besser sein will.

Auffällig vor allem ist, dass man sich aussuchen kann, ob man ActiveRecord oder DataMapper für das ORM verwenden möchte, wobei letzterer klar präferiert wird, da ActiveRecord nicht thread-safe ist. Auch bei der Wahl der Templating-Engine oder der verwendeten JavaScript-Frameworks gibt es keine Vorgaben. Überhaupt spielt Flexibilität und Leichtgewichtigkeit in Merb eine große Rolle, was sich auch schon bei der Installation der Pakete ausdrückt: Die Basis bildet das Gem merb-core, welches den absolut rudimentären Teil des Frameworks beinhaltet, welcher laut Ezra auch bald fertig gestellt und dann vorerst nicht erweitert werden soll. Weitere Pakete wie merb-more enthalten zusätzliche Features wie Generatoren, Mailer und Helper. Was den verwendeten Applicationserver angeht, so unterstützt Merb Rack und überlässt es auch hier dem Entwickler, sich für Mongrel oder Alternativen wie Thin zu entscheiden.

Mottos, die hinter der Motivation von Merb stehen sind “No code is faster than no code” und “Don’t be clever”. Merb ist bewusst schlanker als Rails und will auch nicht aus dem Stehgreif alle Probleme lösen, die Rails lösen kann. Es bringt keinen unnötigen Balast mit sich und die Funktionalitäten des Kerns sollen explizit über Plugins (welche hier im übrigen Gems sind) erweitert werden. In dem Sinne ist es auch möglich, eine komplette Applikation Camping-like in einer Datei zu entwickeln. Im Kern wird außerdem bewusst auf die Metaprogrammierungsfeatures von Ruby verzichtet, was zusätzlichen Performancegewinn bedeutet.

Am deutlichsten werden die Unterschiede zu Rails in den Controllern. Hier orientiert sich Merb etwas mehr an Ruby-Konventionen, so dass eine Action beispielsweise immer das Ergebnis des letzten Statements ausgibt. Bei diesem Ergebnis kann es sich um ein gerendertes Template, ein Objekt, einen einfachen String, einen Block oder auch eine Datei handeln. Wird ein Objekt zurückgegeben, wird auf diesem - je nach angefordertem Mime-Type - eine Rendermethode (beispielsweise to_xml oder to_json) aufgerufen, was dem respond_to-Block in Rails entspricht.

Möchte man in Rails teurere Tasks wie beispielsweise Versenden von E-Mails oder Anstoßen von Web-Services auf einen Backgroundprozess auslagern, um möglichst schnell eine Response liefern zu können (btw: der verlinkte Artikel ist ein Must-read, um die Problematik besser zu verstehen!), so ist man auf Plugins wie delayed_job oder Backgroundjob angewiesen. In Merb kann man dies direkt über den render_then_call-Block erledigen. Dabei wird zunächst die Antwort an den Browser geliefert (wodurch der Applicationserver für das Annehmen einer neuen Anfrage bereit ist) und anschließend der Inhalt des Blocks ausgeführt.

Darüber hinaus gibt es weitere feine Unterschiede, wie zum Beispiel das Handlen von Exceptions, welche einen eigenständigen Controller haben oder die Mailer, welche in Merb in der Controllerschicht untergebracht sind (in Rails sind die Mailer Modelle, doch ihre Funktionalität gehört eigentlich in die Controllerschicht).

Merb ist meiner Meinung nach eine sehr interessante Abzweigung von Rails und es wert, einen genaueren Blick zu riskieren. Bei kleineren Applikationen bringt Rails einfach Overhead mit sich, was Merb ohne Eleganzeinbußen umgeht und dabei zusätzliche Performancesteigerung bietet. Ich werde mich in nächster Zeit näher damit beschäftigen, es kann schließlich nie schaden, über den Tellerand hinaus zu gucken.

Read on…

Als Quellen dienten folgende Links:

  • Exploring Merb: Präsentation von Ezra Zygmuntowicz (dem Entwickler von Merb) beim Ruby Hoedown 2007. Die etwa 20-minütige Präsentation mit anschließender Fragerunde gibt einen guten Einstieg und verdeutlicht die Motivation, die hinter der Entwicklung von Merb als neues Framework steckt.
  • Meet Merb: Peepcode PDF, welches aktuell noch nicht komplett fertig gestellt ist. Ein paar Teile fehlen noch und ich bin gespannt, wie viel da noch zu kommt. Ist eine gute Zusammenfassung, aber irgendwie fehlt es dem bislang 63-seitigen PDF (mit viel Whitespace) noch an richtiger Substanz. Dien Infos daraus kann man sich auch mit etwas Mühe gut im Netz zusammensuchen.
  • Unterschiede von Rails und Merb
  • DataMapper: Thread-safe Alternative zu ActiveRecord als ORM-Layer
  • Unterschiede zwischen ActiveRecord und Datamapper
  • Screencast zu Merb und Datamapper

Viel Spaß beim Lesen, falls jemand schon Erfahrungen mit Merb gesammelt hat, lasst es mich wissen, ich denke da wird es in nächster Zeit mehr drüber zu hören geben.

iOS app for GitHub

iOctocat

ist GitHub für die Hosentasche - deine Projekte und das was dort passiert immer dabei mit deinem iPhone und iPod Touch.
Die App ist