Techno­lo­gie­ver­gleich am Beispiel eines Headless Blog

Jul 30, 2019 | Academy Day, Headless Blog, Wissen

Einleitung

Unser Academy-Day wurde ins Leben gerufen, um uns einen Rahmen zu schaffen in dem wir ohne Projekt­bezug Sachen auspro­bieren und uns weiter­bilden können. An diesem Tag können wir super coole interne Projekte bearbeiten, z.B. unser „Smart Project Board“ basierend auf einem Micro-Computer und Bausteinen eines deutschen Spiel­zeug­her­stellers oder einfach mit ein paar Sachen herum­spielen, die uns schon immer mal inter­es­siert haben.

An diesem spezi­ellen Academy-Day ging es darum, einmal unter­schied­liche Program­mier­sprachen und Frame­works auszu­pro­bieren. Wir wollten einfach heraus­finden, ob es Spaß macht damit zu arbeiten und ob sie uns eventuell nützlich sein könnten. Weiterhin wollten wir heraus­finden, wie lange es dauert, eine der neuen Techno­logien erfolg­reich einzu­setzen und diese mit den bewährten Werkzeugen zu vergleichen.

Nach Rücksprache mit dem Team konnten wir ein paar gut geeignete Program­mier­sprachen für unseren Vergleich auswählen:

  • PHP (die Bewährte)
  • JavaScript (die Vielseitige)
  • Elixir (die Skalierbare)
  • Go (die Aufstre­bende)

Folgende Themen sind im Rahmen dieser Beitrags­serie geplant:

  • PHP + Laravel
  • JavaScript + Adonis.js
  • JavaScript + Sails.js
  • Go + Gin Gonic
  • Elixir + Phoenix
  • Perfor­mance Test mit gatling.io
  • Ergebnis und Zusam­men­fassung

Vorbe­reitung und Planung

Damit unsere Imple­men­tie­rungen auch angemessen und aussa­ge­kräftig verglichen werden konnten, mussten wir uns ein geeig­netes Projekt und ein paar Testme­thoden ausdenken. Im Laufe der Planung hat sich folgendes Projekt-Szenario ergeben.

Projekt

Ziel war es grund­sätz­liche Funktionen und Konzepte einer typischen Weban­wendung zu unter­suchen. Das heißt wir brauchten:

  • Webserver
  • Datenbank oder einen anderen Storage
  • mehrere Entities und Bezie­hungen
  • API-Zugriff
  • einfache Authen­ti­fi­zierung, z.B. über einen Token
  • Wir sollten das in einem Tag hinbe­kommen können.
Das Ergebnis war ein recht einfacher „Headless Blog“ mit folgenden Entitäten:

Die folgenden Anwen­dungs­fälle sollten im Rahmen unseres Projektes abgebildet werden:

  • Lesen/Anzeigen der Posts und Comments
  • User
    • erstellen, bearbeiten, löschen von Posts
    • erstellen, bearbeiten, löschen von Kommen­taren
    • anzeigen aller Kommentare zu einem Post
  • anlegen, bearbeiten, löschen und anzeigen von Usern (vorerst ohne weitere adminis­tra­tiven Berech­ti­gungen)

Die API-Dokumen­tation erfolgte mit Postman. Sie ist sicherlich noch nicht perfekt, aber für unsere Zwecke ausrei­chend.

 

Vorbe­din­gungen

Da wir uns für Gitlab-CI als zentrales Werkzeug für Conti­nious Testing entschlossen haben, brauchten wir auch ein standar­di­siertes Projekt­setup. Natürlich haben wir uns da docker gewünscht! Neben der Projekt­be­schreibung haben wir also noch ein paar zusätz­liche  Anfor­de­rungen für ein testbares Setup via docker definiert.

  • Das Docker­setup läuft automa­tisch komplett durch und wartet auch auf alle abhän­gigen Container.
  • Die API ist zum Schluss unter http://api:80/ erreichbar.
  • Das ganze Setup darf nicht zu lange dauern, da wir nicht nach jedem Push eine Stunde auf die Ergeb­nisse warten wollen.

Der nette Neben­effekt dieser Anfor­de­rungen ist, dass wir so die Möglichkeit hatten funktio­nie­rende docker-compose-Setups für verschie­denen Sprachen und Frame­works zu bauen.

Nachdem die Planungen abgeschlossen waren fühlten wir uns bereit für den Tag. Wir haben eine E‑Mail mit allen notwen­digen Infor­ma­tionen und Tipps zum Docker­setup geschickt.

Durch­führung

Nach einer kurzen Begrü­ßungs­runde und einem ordentlich starken Kaffee haben wir dann allen Teilnehmern die Postman-API-Dokumen­tation zur Verfügung gestellt. Aus unserer Sicht sollte diese ausreichen, um das Projekt imple­men­tieren zu können. Während alle mit der Bearbeitung der Projekte beschäftigt waren, hat sich das Orga-Team des Academy-Days um die Imple­men­tierung der API- und Last-Tests gekümmert und die Konfi­gu­ration der CI-Pipeline vorge­nommen.

 

Stacks/Frameworks

Die folgenden Stacks kamen zur Anwendung:

PHP mit Laravel

Elixir mit Phoenix

Go mit Gin-Gonic

JavaScript mit Adonis.js und Sails.js

Es hat sich heraus­ge­stellt, dass 1 Tag nicht genug ist, wenn noch keine Vorkennt­nisse mit der gewünschten Sprache existieren. Am Ende des Tages hatten wir ein PHP-Projekt und zwei JavaScript-Projekte, die alle Tests bestanden. Da aber jeder die Chance haben wollte, zu zeigen, dass sein Stack auch cool ist, haben wir einen zweiten Academy-Day angesetzt. Alle Projekte konnten erfolg­reich zum Abschluss gebracht werden.

API-Tests

Eine Anfor­derung an die Projekte war, dass sie die zur Verfügung gestellten API-Tests bestehen. Die API-Tests wurden im Laufe des Academy-Days imple­men­tiert, was sich im Nachhinein als eine kleine Schwach­stelle in unserer Planung heraus­stellte.

Unser super durch­dachte API-Dokumen­tation bot scheinbar doch mehr Inter­pre­ta­ti­ons­spielraum als wir erwartet hatten, so dass am Ende keines der Projekte die Tests beim ersten Anlauf bestehen konnte. Letzt­endlich haben wir dann einen relativ großen Teil der Zeit damit verbracht die Dokumen­tation und die Tests anzupassen, um möglichst alle schwammig definierten Stellen zu besei­tigen.

Am Ende des Tages haben es drei Projekte geschafft die Tests erfolg­reich zu bestehen. Die Tests wurden initial mit Postman geschrieben und konnten dort sehr gut ausge­führt werden. Für die GitlabCI-Pipeline konnten wir den Commandline-Runner Newton verwenden.

Beim zweiten Teil des Acade­myDays hat mein Kollege einen anderen Ansatz verfolgt. Er hat die Tests mit Chakram geschrieben und in einen Docker-Container gepackt. Die Tests konnten so nun noch einfacher ausge­führt werden.

Last-tests

Um die Performanz der Imple­men­tie­rungen einschätzen zu können, haben wir uns dazu entschieden Lasttests durch­zu­führen. Hier gab es Uneinigkeit im Lager. Ich hatte schon ein wenig mit Artillery.io herum­ge­spielt und fand es von der Handhabung her ganz ordentlich.

Meine Kollegen dagegen hatten die gleichen Erfah­rungen mit gatling.io gemacht und wollten wiederum von ihrer Position nicht abweichen. Am Ende des zweiten Tages hatten wir dann Lasttests mit beiden Frame­works erstellt. Für die Endab­nahme sollte dann gatling.io herge­nommen werden.

CI-Pipeline mit GitlabCI

Wie weiter oben erwähnt, haben wir uns als Build-Pipeline GitlabCI herge­nommen. Die Projekte sollten dort automa­tisch gebaut und getestet werden. Wir haben erwartet, dass wir das gut hinbe­kommen, wenn wir Rahmen­be­din­gungen an ein Docker-Setup stellen. Alle Tests würden dann gegen den festge­legten Endpunkt laufen.

Wir haben zwei verschiedene Ansätze verfolgt:

 

  • Ein selbst gehos­tetes Gitlab und alle Projekte sollten dorthin gepushed werden.
  • In Gitlab.com und wir haben die Repository-Adressen der anderen einge­sammelt und dort einge­bunden.

Zusam­men­fassung

In unserer kleinen Academy-Day-Serie haben wir besonders in folgenden Themen dazuge­lernt:

  • Entwicklung in den verschie­denen Sprachen und Frame­works
  • Projekt­setup mit Docker
  • API-Tests
  • Last-Tests
  • Projekt­orga­ni­sation und der eigene Horizont

Die wichtigste Erkenntnis für mich war, dass wir viel zu optimis­tisch geplant haben. Wenn man schon über Erfah­rungen zu Sprachen und Frame­works verfügt, dann lässt sich dieses Projekt relativ einfach im Laufe eines Tages umsetzen. Ist das nicht der Fall stolpert man unter Umständen über die einfachsten Sachen. Parallel zu den Imple­men­tie­rungen die API-Test, Last-Tests und die Pipeline zu erstellen, war ebenfalls ein viel zu hoch gestecktes Ziel. Ich bin insgesamt sehr erfreut und froh, dass jeder mit einem positiven Resultat aus unserer kleinen Serie herauskam.

Es werden nach und nach Blogbei­träge zu den einzelnen Themen dieses Acade­myDays entstehen, die wir hier dann veröf­fent­lichen und verlinken.

Stay tuned,
Steffen