Überblick über zur Verführung stehenden Frameworks

Webframeworks für C++
Kommentare

Die Programmiersprache C++ hat ihre feste Fangemeinde – große Projekte wie KDE werden mit ihr implementiert. Als Multiparadigmensprache ist sie flexibel und universell einsetzbar, dennoch ist sie in der Webprogrammierung unterrepräsentiert. Am Mangel an Frameworks kann es nicht liegen, wie dieser Artikel zeigen soll.

Es gibt eine Vielzahl an Möglichkeiten, mit C++ Webprogrammierung zu betreiben. Und auch wenn es so scheint, ist die Sprache im Bereich der Webprogrammierung alles andere als unterrepräsentiert – Frameworks gibt es zur Genüge. Welches Framework das richtige ist, hängt jedoch nicht allein von technischen Fragen ab. Welche Gründe könnten also überhaupt für die Webprogrammierung mit C++ sprechen?

Geschwindigkeit

Ein Grund könnte die Geschwindigkeit sein. Alle hier vorgestellten Frameworks sind um ein Vielfaches schneller als PHP, Ruby on Rails und Java. In Zukunft könnte es aufgrund steigender Energiekosten ein wichtige Faktor sein, ob man in seinem Rechenzentrum zwei Racks mit Strom und Klima versorgen muss oder einhundert. Aber auch heute kann es bereits interessant sein, auf schwachen Embedded-Systemen Web Services betreiben zu können, die für Java-Application-Server zu schwach oder deren Speicher zu klein sind.

Investitionsschutz

Ein anderer Grund könnte Investitionsschutz sein, wenn eine bestehende C++-Applikation zu wertvoll ist, um sie komplett neu zu reimplementieren. In diesem Fall ist es mit relativ wenig Aufwand möglich, eine Applikation „Cloud-fähig“ zu machen, indem man ihr nachträglich ein REST-API gibt und sie als Web Service nutzt. Wenn ein Web-Frontend gewollt ist, kann dies mit einer Technologie wie PHP oder Ruby On Rails realisiert werden, die auf diesem REST-API aufbaut. Wenn man keinen Technologiebruch möchte, oder keine serviceorientierte Architektur (SOA) braucht, kann man das Web-GUI auch direkt mit C++ implementieren. Dabei sollte man bei der Auswahl der richtigen Frameworks bedenken, dass die meisten Web-GUI-Frontend-Spezialisten keine Erfahrung mit C++ haben und die Zusammenarbeit schwierig wird, wenn dies zu viel Wissen über C++ voraussetzt.

Sicherheit

Ein dritter Grund, der für C++ auf dem Webserver spricht, ist das Thema Sicherheit. Viele der hier vorgestellten Frameworks verwenden kein Templatesystem, das in Echtzeit Code generiert und interpretiert, sondern wandeln die HTML-Templates zur Compilerzeit in Maschinencode um. Dies wird es dem Angreifer schwer machen, dem Servercode unterzuschieben. Es ist nicht möglich, den Code auf dem Webserver neu zu übersetzen, wenn der Angreifer den Sourcecode nicht besitzt und es auch keinen Compiler oder Interpreter gibt, um eigenen Code zu übersetzen oder auszuführen. Ich habe im Laufe meiner Recherchen bisher dreizehn Projekte entdeckt, die sich mit C++ als Technologiebasis für Webprogrammierung beschäftigen. Diese Projekte verfolgen zum Teil völlig unterschiedliche Ansätze. Ich möchte in diesem Artikel einen Überblick über diese Projekte liefern. Es würde den Rahmen sprengen, jedes Projekt in der ganzen Tiefe und Breite darzustellen. Ich beschränke mich deshalb darauf, lediglich die unterschiedlichen Konzepte anzureißen, die Projektgeschichte, den Reifengrad und einige wenige Codebeispiele zu zeigen. Bei der Reihenfolge gehe ich nach dem Alter der Projekte vor. Bei einigen Projekten begnüge ich mich damit, sie nur in Form eines kurzen Steckbriefs zu erwähnen. Im Fazit am Ende des Artikels nenne ich die Gründe, wegen denen ich eine nähere Betrachtung für nicht lohnenswert halte.

OKWS

Das Projekt wurde 2003 gestartet, der Code steht unter der GPLv2. Das Framework dient dem Datingportal www.okcupid.com als Grundlage ihrer Website. Über den Code hinaus gibt es kaum Dokumentationen. Das Projekt ist mit drei Entwicklern gestartet und hat über lange Zeit nur einen aktiven Entwickler gehabt, seit 2012 sind ein paar Entwickler hinzugekommen – im April 2012 hatten sie mit acht Entwicklern ihren Höchststand. Die Firma im Hintergrund ist in New York ansässig und sucht wohl auch Personal, die Communityentwicklung scheint aber keine hohe Priorität zu haben. Deshalb ist es für Außenstehende schwierig zu erkennen, welche Philosophie verfolgt wird und wo die Reise künftig hingehen soll. Für OKWS spricht, dass sie mit ihrer Seite unter Beweis gestellt haben,

Tntnet

Auch dieses Projekt hat seine Praxistauglichkeit schon unter Beweis gestellt, da die Deutsche Börse Systems AG diese Technologie einsetzt. Ein weiterer Anwender ist das Projekt „VDR – The Video Disk Recorder“, das eine Steuerungsoberfläche mit Tntnet realisiert hat. Die Projektseite wird mit der eigenen Technologie betrieben. dass ihr Framework praxistauglich ist.

Steckbrief: Tntnet
Projektstart war 2004. Die umfangreiche Dokumentation mit den zahlreichen Beispielen macht den Einstieg recht leicht. Auf der Mailingliste werden bereitwillig Fragen beantwortet und Grundsatzfragen diskutiert. Das Entwicklerteam schwankte in den zehn Jahren des Bestehens zwischen einem und drei Entwicklern. Die Code-Base beläuft sich auf ca. 260 000 LoC. Das Framework steht unter der LGPL. Als Plattform werden Linux und Unix unterstützt. Das Projekt hat nur eine geringe Anzahl von Abhängigkeit zu anderen Libraries.

Die Philosophie von Tntnet ist, sich auf die wesentlichen Dinge zu konzentrieren und den Anwender nicht vorzuschreiben, wie er seinen Code zu organisieren hat. So präferiert Tntnet nicht das MVC-Konzept, es stellt sich dem aber auch nicht entgegen. Tntnet hat einen geringen Abstraktionsgrad. „Magic“, die Dinge kapseln und vereinfachen soll, wird bewusst zu Gunsten transparenter Lösungen vermieden. Tntnet möchte, dass der Anwender versteht, was passiert und sich selbst um die Abstraktion – in seinem Sinne – kümmert. Technologien und Konzepte sind gerade in der Webprogrammierung sehr kurzlebig; wer sich „entschleunigen“ will, findet in Tntnet sicherlich eine zuverlässige Konstante. Ganz ähnlich wie C++, das sich ständig weiterentwickelt, ohne mit der Abwärtskompatibilität zu brechen. Das bedeutet aber nicht, dass Tntnet deshalb umständlicher sei. Hier ein Beispiel, das zeigen soll, wie schnell mit Tntnet ein Web Service erstellt wird:

double add(double a1, double a2){
  return a1 + a2;
}

Hier wird eine Beispielfunktion erstellt, die stellvertretend für irgendeine Funktionalität stehen soll. Diese hier rechnet zwei Werte zusammen und gibt den Wert zurück.

cxxtools::Arg<std::string> ip(argc, argv, 'i');
cxxtools::Arg<unsigned short> port(argc, argv, 'p', 7002);
cxxtools::Arg<unsigned short> bport(argc, argv, 'b', 7003);
cxxtools::Arg<unsigned short> jport(argc, argv, 'j', 7004);
cxxtools::Arg<bool> daemonize(argc, argv, 'd');
cxxtools::Arg<std::string> pidfile(argc, argv, "--pidfile");

In Listing 1 ist zu sehen, wie Tntnet dabei unterstützt, die Kommandozeilenparameter zu parsen. In diesen Fall wird die IP übergeben und die verschiedenen Portnummern, über die das REST-API erreicht werden kann. An Port 7002 wird XML, an Port 7003 Binary und an Port 7004 wird JSON übergeben. Darüber hinaus wird die Übergabe eines pidfile-Namen unterstützt, der gebraucht wird, wenn der Prozess im Hintergrund laufen soll (Flag daemonize).

cxxtools::EventLoop loop;
cxxtools::http::Server httpServer(loop, ip, port);
cxxtools::xmlrpc::Service xmlrpcService;
xmlrpcService.registerFunction("add", add);
httpServer.addService("/xmlrpc", xmlrpcService);
cxxtools::bin::RpcServer binServer(loop, ip, bport);
binServer.registerFunction("add", add);
cxxtools::json::RpcServer jsonServer(loop, ip, jport);
jsonServer.registerFunction("add", add);
cxxtools::json::HttpService jsonhttpService;
jsonhttpService.registerFunction("add", add);
httpServer.addService("/jsonrpc", jsonhttpService);

In Listing 2 wird der Event Loop eingerichtet. Beide Funktionen werden an die verschiedenen Dienste gebunden. Mit diesem Kommando wird der Dienst, wenn gewünscht, automatisch in den Hintergrund geschoben und der Loop gestartet. Das vollständige Beispiel findet sich hier. Mit diesen Zeilen ist nun die C++-Funktion Cloud-ready:

if (daemonize)
  cxxtools::posix::daemonize(pidfile);
loop.run();

Für die Programmierung eines Webinterface stellt Tntnet einen Precompiler namens ecppc zur Verfügung. Dieser verarbeitet die eccp-Templatedateien, in denen HTML zusammen mit C++-Code verwendet werden kann. Es entsteht eine C++-Codedatei, die mit einem normalen C++-Compiler übersetzt wird. Das kann aussehen wie in Listing 3.

<html>
  <head>
    <title>ecpp application myfirstproject</title>
  </head>
  <body>
    <h1>myfirstproject</h1>
    <{
      // we have a c++ section here
      double arg1 = 1.0;
      double arg2 = 3.0;
      double result = arg1 + arg2;
    }>
    <p>
    <$ arg1 $> + <$ arg2 $> =
      % if (result == 0.0) {
        nothing
      % } else {
        <$ result $>
      % }
    </p>
  </body>
</html>

Der Templatecode wird somit nicht zur Laufzeit interpretiert. Das hat Vor- und Nachteile: Der Code durchläuft die strenge Kontrolle des Compilers, sodass die Typensicherheit gewahrt bleibt. Zudem ist der Code in der Ausführung extrem schnell. Der Nachteil ist zugleich ein Vorteil: Der Code kann nicht so einfach geändert werden, da er jedes Mal neu übersetzt werden muss. Dies kann jedoch auch ein Sicherheitsfeature sein (siehe Einleitung). Mit Tntnet lassen sich statische Inhalte wie Bilder, CSS, JavaScrip etc. fest einkompilieren. Man erhält eine kompakt ausführbare Datei, in der alles enthalten ist. Dies kann das Deployment stark vereinfachen und verhindern, dass bösartige Inhalte untergeschoben werden. Die meisten Webframeworks setzen auf das MVC-Konzept (Model View Controller). Tntnet präferiert dies nicht, es lässt sich jedoch umsetzen. Hierzu gibt es verschiedene Lösungsansätze: In der Demosammlung auf der Website finden sich dazu Beispiele, ebenso in meinem Blog. Auch Features, die man von anderen Frameworks kennt, wie z. B. CSRF-Tokenschutz (Cross-Site Request Forgery) müssen vom Anwender implementiert werden. Tntnet gibt zu vielen Themen Best-Practice-Vorschläge.

Zum von Tntnet unterstützten Funktionsumfang zählt ein URL-Routing-System, das auch RegEx erlaubt. Das Laufzeitverhalten des Servers lässt sich fein einstellen (Anzahl der Threads, Timeouts, SSL-Verschlüsselung, Request Size, Kompression usw.). Es gibt ein Session Handling, auch wenn ACL selbst implementiert werden muss. Das Templatesystem besitzt so genannte Savepoints. Sie erlauben es, ähnlich wie bei einem Exception Handling, darauf zu reagieren, wenn bei der HTML-Generierung eine Ausnahme geworfen wird. Auch das Manipulieren von Bildern mithilfe der GD-Lib (Graphics Library) – wie man es von PHP kennt – ist kein Problem. Zum Einbetten wiederkehrender Elemente wie Menüs gibt es eine statische und eine dynamische Methode. Es gibt eine Unterstützung für Internationalization. Und die Möglichkeit der Serialization von Klassen in .json, .csv und .xml. Tntnet bringt außerdem ein eigenes signal/slot-Konzept mit, das weder auf Qt noch auf Boost aufsetzt. Eine wichtige Funktionalität ist die Datenbankanbindung (TntDB). Hier wird als Backend MySQL, PostgreSQL, SQLite und Oracle unterstützt. Diese bieten auch Schutz vor SQL Injection durch automatisches Maskieren von Sonderzeichen. Database-Connection-Pools sorgen dafür, dass Verbindungen nicht jedes Mal neu aufgebaut werden müssen. Mit Replace Condition kann man bedingte SQL Selects erstellen (Listing 4). Ein vollständiges Beispiel ist hier zu finden.

tntdb::Statement stmt = 
  conn.prepare( 
  tntdb::SqlBuilder(
    "select a from %table where a in (%v) or b in (%w) and z = :z %q1 %q2"
  ).extendParam("v", v.size())
  .extendParam("w", w.size())
  .replace("table", mytable)
  .replaceIf(condition1, "q1", "and z > :z")
  .replaceIf(condition2, "q2", "and y > :y")
);

stmt.set("v", v);
stmt.set("w", w);
if (condition1)
  stmt.set("z", 5);
if (condition2)
  stmt.set("y", 18);

 

Steckbrief: WSO2 – Web-Service-Framework für C++

Das Projekt startete um das Jahr 2007. Die Firma hinter dem Framework hat ihren Sitz in Sri Lanka. Der Funktionsumfang beinhaltet lediglich die Möglichkeit, Web Services mit C++ zu erstellen, da es sich als Middlewaretechnologie versteht. Lizenziert ist WSO2 unter Apache 2.0. Als Plattform werden Windows, Linux, Unix (Solaris) und Mac OS unterstützt. Die Dokumentation ist sehr umfangreich. Auch wenn die Firma noch existiert, zeigt das Projekt in den letzten Jahren wenig Aktivitäten. Die Website finden Sie hier.

Steckbrief: CppCMS

Das Projekt wurde um das Jahr 2008 ins Leben gerufen. Mit seinen 1 800 000 Zeilen hat es mit Abstand die größte Code-Base, nur Node.js kommt an diese Zahl heran. Diese beachtliche Anzahl erklärt sich vor allem aus dem Anspruch, ein Full-Featured-Framwork sein zu wollen. Lizenziert ist das Framework unter GPLv3 oder alternativ mit einer Commercial License. Als unterstützte Plattform werden Linux, Unix, Mac OS und Windows genannt. In der verfügbaren Dokumentation findet sich nur Grundlegendes; die API-Dokumentation ist lückenhaft. Es gibt keine Mailingliste, über die man sich austauschen und Fragen stellen könnte.

NaCl

Bis in das Jahr 2009 lässt sich die Codegeschichte von NaCL (Native Client SDK) zurückverfolgen. Treibende Kraft scheint vor allem Google zu sein. Das Ziel des Projekts ist es, C++ im Google-Chrome-Browser einbetten zu können. Trotz guter Personalausstattung des Projekts ist die Dokumentation unzureichend und verwirrend. Als Lizenz wurde die Google BSD License gewählt. Der Codeanalyse nach scheint das Interesse von Google an dem Projekt bereits abzuflauen. Es hinterlässt bei mir den Eindruck, dass es sich bei dem Framework um einen Proof of Concept handelt.

Node.js mit C++

Manch einer wird sich wundern, warum Node.js hier in der Liste auftaucht. Denn die meisten werden mit dem im Jahr 2009 gestarteten Projekt vor allem JavaScrip und nicht C++ verbinden. Der Initiator von Node.js, Ryan Dahl, hat schon vor Node.js ein Framework auf Basis von C geschrieben. Das konnte sich jedoch nicht durchsetzen, da die Akzeptanz von der Programmiersprache C unter Webprogrammierern zu gering war (siehe dazu „Node.js“ von Sebastian Springer). Node.js ist ebenfalls zu 64 Prozent in C/C++, und nur zu 18 Prozent in JavaScript geschrieben – es ist quasi nur die Frontend-Sprache. Dieses Mal scheint Ryan Dahl auf größeren Zuspruch zu stoßen, da JavaScript den meisten Webprogrammierern sehr vertraut ist. Für den C++-Backend-Programmierer bietet Node.js eine Schnittstelle, denn es ermöglicht überaus leicht Module (bzw. „Add-ons“) in C++ für Node.js zu schreiben. Frontend-Entwickler können diese Module gewohnt per JavaScript ansteuern und nutzen, ohne sich mit den Details von C++ beschäftigen zu müssen. Allerdings ist auf der Seite von C++ die Typsicherheit durch die Limits von JavaScript begrenzt – eine genaue Prüfung der übergebenen Werte ist deshalb auf Seiten der C++-Programmierer existenziell.

Offenbar können JavaScript- und C++-Programmierer mit dem Lösungsansatz gut leben. Das zeigt die regen Aktivitäten der Projektmitglieder und Anwender. Die Code-Base beläuft sich auf 1 800 000 Zeilen. In den letzten zwölf Monaten gab es 1 300 Commits. Das Entwicklerteam schwankt zwischen 20 bis 35 Aktiven. Darin enthalten sind noch nicht die zahlreichen Erweiterungen anderer Projekte. Das Subsystem wird über ein eigenes Paketsystem namens npm (Node Package Manager) verwaltet. Auf der dazugehörigen Website finden sich über 70 000 NPMs. Sowohl der Anstieg der Anzahl an Paketen, als auch die Zahl der Downloads (ca. 10 000 000 täglich) ist beachtlich. Ein weiterer, kaum zu überschätzender, Vorteil von Node.js ist die große Zahl an Dokumentationen und sogar Büchern. Wer zum ersten Mal ein eigenes Add-on in C++ schreiben will, findet sehr schnell sehr gute Beispiele. Node.js bringt ein eigenes Build-Tool mit, das node-gyp heißt. Es handelt sich um ein in Python geschriebenes Programm, das als Wrapper für die C++-Build-Tools dient. Im Hintergrund werden damit Makefiles erstellt und verarbeitet. Die Targets (Build-Regeln) werden in Form von JSON in einer Konfiguration geschrieben, wodurch der Build-Prozess stark vereinfacht wird. Die erstellten Makefiles sind gut lesbar und beinhalten zahlreiche Kommentare. Möglicherweise lässt sich der Build-Prozess auch mit Tools wie CMake abbilden; der Mehrwert scheint aber fraglich zu sein. Das .gyp-Dateibeispiel aus Listing 5 stammt aus der Formatreferenz.

{
  'targets': [
    {
      'target_name': 'cruncher',
      'type': 'static_library',
      'sources': ['cruncher.cc'],
      'direct_dependent_settings': {
        'include_dirs': ['.'], # dependents need to find cruncher.h.
      },
      'link_settings': {
        'libraries': ['-lm'], # cruncher.cc does math.
      },
    },
    {
      'target_name': 'cruncher_test',
      'type': 'executable',
      'dependencies': ['cruncher'],
      'sources': ['cruncher_test.cc'],
    },
  ],
}

Das Build-Tool ist sehr mächtig und erlaubt z. B. auch, Conditions zu definieren, sodass Pakete abhängig vom Betriebssystem unterschiedlich gebaut werden. Nach dem erfolgreichen Build-Prozess steht nun dem JavaScrip-Programmierer ein Add-on zur Verfügung, das er wie gewohnt einbinden und benutzen kann. Für eine hohe Produktivität von Node.js sorgt insbesondere die bereits erwähnte Vielzahl von fertigen Modulen. Hier werden alle gängigen Herausforderungen der Webprogrammierung abgedeckt: Session Handling, Datenbankanbindung (SQL und NoSQL), Authentifizierungsverfahren (LDAP, OAuth, OpenID usw.), Template Engines (HTML- und YAML-basiert), WebSockets, CSRF-Tokens und vieles mehr.

Steckbrief: Wt „Witty“

2009 gestartet, verfolgt das Projekt das Ziel, Webapplikationen so zu schreiben, als wären sie eine Qt-Desktopanwendung. Der Code steht unter GPL oder wahlweise einer Commercial License. Auch wenn Qt nachgeahmt wird, verwendet es keine Qt-libs, ein MVC-Ansatz ist nicht vorgesehen. Das Entwicklerteam bestand im Laufe der Zeit maximal aus drei aktiven Entwicklern; die Entwicklung erfolgt über die Jahre jedoch kontinuierlich. Die Aktivitäten auf der Mailingliste zeigen eine rege Kommunikation zwischen Entwicklern und Anwendern, und die Dokumentation ist umfangreich.

CPPSP „C++ Server Pages“

Der Code des 2011 gestarteten Projekts steht unter der GPLv2. Als Vorbild diente der Aussage der Entwickler nach die ASP.NET-Technologie von Microsoft. Welche Betriebssysteme unterstützt werden, ist der Website nicht zu entnehmen; ohnehin ist die Doku äußerst spärlich. Das Code-Repository hinterlässt einen sehr chaotischen Eindruck. Im Repository sind nur 30 Prozent C++-Code zu finden, der größte Teil ist XML und JavaScript. Das Konzept von CPPSP sieht vor, dass der Code zur Laufzeit bei Bedarf rekompiliert wird. Das bedeutet, dass die C++-Sourcen auf dem Server liegen müssen (mit allen Risiken und Nachteilen, die das mit sich bringt).

Steckbrief: Duetto

Die Arbeiten an diesem Projekt begannen 2011. Zu ersten Mal wurde es Ende 2013 sichtbar gemacht, als u. a. auf Heise über das Projekt berichtet wurde. Das Projekt steht unter einer Doppellizenz: GPL, LGPL, NCSA Open Source License oder Commercial Licenses. Nach der eigenen Definition will Duetto kein Framework sein, sondern eine Erweiterung von C++ 11, das die Grundlage für moderne Webprogrammierung bereitstellt. Auch bei diesem Projekt ist es schwierig, den Code zu analysieren, da dieser ein Fork des Clang-Compilers ist. Deshalb ist auch schwer zu sagen, wie viele Zeilen Code tatsächlich zum Projekt gehören. Hinter diesem steht eine Firma namens Leaning Technologies. Das Konzept von Duetto sieht vor, die Notation von C++ zu erweitern, und vom Compiler z. T. JavaScript für die Clientseite zu generieren, der bei Bedarf C++-Funktionalitäten auf dem Server aufruft. Die Dokumentation umfasst nur die Grundlagen und die API-Dokumentation. Es werden die Betriebssysteme Linux, Windows und Mac OS unterstützt.

Steckbrief: QtWebApp

Das Ein-Man-Projekt steht unter der LGPL, auch wenn es kein öffentliches Code-Repository gibt, weshalb die Codegeschichte auch nicht analysierbar ist. Der Projektstart muss jedenfalls vor 2012 gewesen sein, denn so alt ist das älteste TAR-File mit dem Sourcecode. In einer persönlichen Mail teilte mir der Entwickler mit, dass er kein Interesse daran habe, eine Community aufzubauen; deshalb gibt es auch keine Mailingliste. Dokumentation, die über das API hinausgeht, ist sehr spärlich. Als Plattform werden Linux, Windows, Mac OS und Android unterstützt, als Technologielieferant dient die Qt-Lib.

ffead-cpp

Das Projekt ist 2012 gestartet und zeigte bereits wenige Monate später nur wenig Aktivität. Das letzte Release, Version 1.9, war im März 2014. Das Projekt hat keine richtige Website, sondern nur die Code-Repository-Sites. Es nutzt somit die eigen erstellte Technologie nicht für sich selbst, was man als Indiz für das (mangelnde) Vertrauen in die eigene Arbeit werten könnte. Die Dokumentation ist eine unstrukturierte Sammlung von Beispielen. Ich habe in den Include-Files kein dokumentiertes API gefunden, auch nicht mit Doxygen. Das Selbstverständnis des Projekts gebe ich mit einem Zitat von der Website wieder: „The framework is developed for rapid development of Enterprise application on the C++ platform.“ Lizenziert ist der Code unter Apache 2.0. Unterstützt werden die Plattformen Linux, Unix und Windows/Cygwin. Als Mailingliste wird Google-Group genutzt – 2012 und 2013 gab es darin jeweils acht Beiträge, 2014 noch keinen.

Treefrog

Das 2012 gegründete Projekt verfolgt das Ziel, Ruby on Rails für C++ nachzuahmen. Die Technologiebasis ist die Qt. Als Templatesysteme stehen zwei verschiedene zur Verfügung: Otama, das sich mehr an JavaServer Faces orientiert und mit einem Precompiler arbeitet und ERB, das sich an Ruby anlehnt. Treefrog steht unter der New BSD License. Treefrog arbeitet, wie Ruby on Rails, mit Generatoren für Scaffolds und Makefiles; also viel „Magic“ und hoher Abstraktion. Da verwundert es nicht, dass es auch ein O/R Mapping gibt. Durch die Funktionalität von Qt werden eine ganze Reihe von Datenbanken unterstützt: MySQL, PostgreSQL, SQLite, Oracle, DB2, InterBase aber auch NoSQL-DB und MongoDB. Als unterstützte Plattformen werden Linux, Windows, Mac OS und Unix-ide Systeme genannt. In der Dokumentation findet man die Grundlagen erklärt; die API-Dokumentation ist lückenhaft. Es gibt eine recht aktive Mailingliste. Der Hauptentwickler stammt (wenn ich es recht verstanden habe) aus Japan – was erklärt, warum ein Großteil der Dokumentation auf Japanisch ist. Es gibt auch eine japanische Mailingliste, die ich mangels Sprachkenntnisse nicht verfolgt habe. Für die Website wird ein WordPress verwendet und nicht die eigene Technologie. In letzter Zeit wurde auf der Mailingliste Unzufriedenheit über das Tempo, in dem der Hauptentwickler Patches einpflegt, geäußert, sodass es zwischenzeitlich so aussah, als wenn ein Fork unvermeidlich werden würde.

Casablanca

Das um 2013 gegründete Projekt wurde von Microsoft initiiert, steht jedoch unter der Apache License. Erklärtes Ziel des Projekts ist es, C++-Programme Cloud-fähig zu machen. Damit ist nichts anderes gemeint, als C++-Programmen ein REST-API geben zu können. Somit ist es ein REST- und kein „Full Featured Web Framwork“. Überraschenderweise unterstützt es neben Windows auch Linux und Unix als Plattformen. Das Projekt hat keine Mailingliste, aber ein aktives Forum. Ein Alleinstellungsmerkmal ließ sich für mich nicht finden.

Fazit

Wir sehen also: Es gibt eine Vielzahl an Möglichkeiten, mit C++ Webprogrammierung zu betreiben. Welches Framework das richtige ist, hängt jedoch nicht allein von technischen Fragen ab. Es ist wichtig, sich von vornherein klar darüber zu sein, welche Philosophie verfolgt werden soll. Soll die Frontend-Gestaltung von den C++-Programmierern mit übernommen werden, oder soll es eine Arbeitsteilung geben? Wenn es eine Arbeitsteilung gibt, muss abgewogen werden, über welche Schnittstellen Frontend und Backend miteinander verknüpft werden. Der geringste Aufwand für C++-Entwickler wäre sicherlich, ihrem Code einfach ein REST-API zu geben, das dann von anderen Webapplikationen genutzt wird, die die Aufgabe des Frontends übernehmen. Hier für kommen Cxxtools (bzw. Tntnet) und Casablanca in die engere Wahl. WSO2 ist aufgrund seiner geringen Projektaktivität sicherlich mit Vorsicht zu betrachten. Aber möglicherweise ist WSO2 in einem Java-EE-Server-Umfeld von Vorteil. Sollte die Zielplattform ein Embedded-System sein, ist wahrscheinlich eine serviceorientierte Architektur (SOA) nicht der geeignete Lösungsansatz. Hier wird eine kompakte Lösung mit robuster Architektur, also ein Full-Stack-Framework, benötigt. Dieses Prädikat nehmen gleich eine ganze Reihe von Projekten für sich in Anspruch.

Hier kann man aber schon mal die aussortieren, deren Entwicklung/Support weitestgehend eingeschlafen ist. Hierzu würde ich CppCMS zählen. Eine unzureichende Dokumentation würde ich auch als Knock-out-Kriterium betrachten. Hier disqualifizieren sich leider OKWS, QtWebApp und ffead-cpp. CPPSP hat zudem noch erheblichen Nachholbedarf bei dem Thema Projektorganisation. Verbleiben noch Tntnet, Wt („Witty“) und Treefrog. Stehen die C++-Entwickler mit HTML, JavaSript und CSS auf Kriegsfuß und ist eine individuelle Gestaltung des Aussehens (Stichwort „Corporate Identity“) nachrangig, könnte Wt interessant sein. Die Webgestaltung kann ausschließlich über C++-Code erfolgen, ohne eine Zeile HTML, JavaSript und CSS schreiben zu müssen. Sollte jedoch noch ein Webdesigner die Frontend-Gestaltung übernehmen, wird sich die Zusammenarbeit für beide Seiten schwierig gestalten. Für diesen Fall ist ein Framework mit einer Template-Engine der bessere Weg. Handelt es sich um ein Projekt, das „from scratch“ erstellt wird, wird man Dank Scaffolding-Tool mit Treefrog recht schnell zu Ergebnissen kommen. Hat man hingegen ein bestehendes Projekt, das nachträglich mit einem Web-GUI ausgestattet wird, ist Tntnet sicherlich die bessere Wahl, da kein Programmierparadigma vorgegeben wird.

Die meisten Websites werden in Rechenzentren betrieben, für die meisten Websites ist Innovation überlebensnotwendig. In den letzten Jahren wurden in einem atemraubenden Tempo neue Technologien und Konzepte entwickelt. Um als Framework auf Dauer mithalten zu können, braucht es eine große Entwickler- und Anwendergemeinde. In diesem Umfeld sehe ich Node.js. als einzigen ernstzunehmenden Herausforderer zur PHP-, Java-, Python- und Ruby-Konkurrenz. Den Kompromiss, den man bei Node.js eingehen muss, ist die mangelnde API-Stabilität der Add-ons. Die npms ändern ihre APIs öfter, als es ein C++-Programmierer von z. B. Boost gewohnt ist. Ein weiterer Nachteil ist, dass die JavaScrip-Codes (weitestgehend) zur Laufzeit auf dem Server gelesen und ausgeführt werden. Es ist also durchaus denkbar, dass bei einer erfolgreichen Attacke dem Node.js-Application-Sever fremder (JavaScript-)Code untergeschoben werden kann. Natürlich ist die Gefahr von Laufzeitfehlern im JavaScrip-Codeteil höher, als wenn alles in C++ geschrieben und kompiliert wäre. Zu Duetto und NaCl fällt mir kein sinnvoller Anwendungsfall ein. NaCl scheint mir ein Proof of Concept von Google zu sein, wobei Googles Interesse jedoch bereits abgeflaut zu sein scheint. Bei Duetto sehe ich das Hauptproblem darin, dass der Code des Clang-Compilers geforkt wurde, um Funktionalitäten einzubauen. Das schafft eine sehr enge Bindung an das Clang-Projekt und macht intransparent, worin die Arbeit von Duetto besteht. Deshalb ist eine Codeanalyse mit www.ohloh.net nicht möglich. Die unzureichende Dokumentation ist ein weiterer Punkt, der kritisch zu betrachten ist.

Aufmacherbild: Creative 3D pieces of puzzle and word C++ von Shutterstock / Urheberrecht: MoneyRender

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -