Softwareentwicklung und Architektur / 01.10.2020 / Sergej Epp

Teil 3: Entwicklung einer Absence-App mit Grails und Neo4J

W√§hrend eines ihrer Kunden-Engagements haben unsere Kollegen Sergej Epp und Felix Hau ein ‚ÄěOn-the-fly‚Äú-Projekt realisiert: N√§mlich eine App, die die Stakeholder √ľber geplante Absenzen der Teammitglieder informiert. F√ľr das Projekt kamen das Web-Framework Groovy on Grails sowie die Graphdatenbank Neo4J zum Einsatz. In dieser dreiteiligen Blogserie beschreiben sie, welche Vorteile die beiden Technologien haben und wie sie sich im Praxis-Einsatz bew√§hren. Teil 3 stellt den Projektverlauf mit der App vor und zeigt, wie Grails und Neo4J sich dabei schlagen.

Absenzverwaltung mit Slack-Anbindung

In einem unserer PENTASYS-Kundenprojekte waren Abwesenheiten verschiedener Teammitglieder im Projektverlauf vorgesehen. Damit die Stakeholder im Voraus Bescheid wissen, welches Teammitglied an welchen Tagen nicht verf√ľgbar ist und wer es vertritt, war bereits ein einfaches Tool im Einsatz. Dieses hatten wir im Rahmen eines ‚ÄěFedEx-Days‚Äú entwickelt ‚Äď also einem Format, bei dem die L√∂sung f√ľr eine bestimmte Fragestellung innerhalb von 24 Stunden konzipiert und entwickelt wird.

Technologisch baute das erste Tool auf Java und Spring Boot auf. F√ľrs erste tat es seinen Dienst. Im Lauf des Kundenprojekts kamen jedoch neue Anforderungen auf. Denn zun√§chst gab es keine Login-Funktion. Neue Nutzer konnten sich nicht √ľber die grafische Oberfl√§che registrieren, sondern mussten per Rest-Endpoint eingef√ľgt werden. Au√üerdem entwickelte sich Slack zu einem der pr√§ferierten Kommunikationskan√§le im Team, weshalb eine Ausweitung der Benachrichtigungen auf diesen Kanal w√ľnschenswert war.

Insofern entschieden wir uns daf√ľr, die App neu aufzusetzen und damit verbunden auch die Basis-Technologie zu wechseln. Dabei ging es zum einen um eine √úbersetzung der alten App auf Grails in Verbindung mit Neo4J und zum anderen darum, die neuen Features mit einzubauen. Grails und Neo4J haben wir bereits in den ersten beiden Artikeln dieser Blogserie vorgestellt.

Die App sollte die folgenden Anforderungen ber√ľcksichtigen:

  • Login ‚Äď Der Einfachheit halber sollte die App keinen separaten Login erfordern, sondern diesen vielmehr √ľber die bereits bestehenden Zugangsdaten des LDAP-Servers erm√∂glichen.
  • Graphical User Interface ‚Äď Die Benutzeroberfl√§che sollte funktional, √ľbersichtlich und gut zu bedienen sein. Dies hat auch den Hintergrund, die Akzeptanz unter den Nutzern zu erh√∂hen. Eine ‚Äěbesondere‚Äú UX stand hierbei jedoch nicht im Vordergrund, ebenso wenig das Corporate Design ‚Äď denn schlie√ülich richtet sich die App an Teammitglieder und interne Stakeholder und nicht an Kunden oder dergleichen.
  • Auswahl Abwesenheiten ‚Äď F√ľr die Auswahl sollten ein Datepicker sowie ein DropDown-Men√ľ zur Verf√ľgung stehen.
  • Benachrichtigung ‚Äď Die Benachrichtigung √ľber aktuelle Abwesenheiten und Vertretungen sollte jeden Morgen √ľber die ausgew√§hlten Slack-Kan√§le versendet werden.
  • Betrieb und Weiterentwicklung ‚Äď Die App sollte auf dem internen Server betrieben werden, WebApp und Datenbank dabei in Docker-Containern laufen.

Aufbau und Entwicklung der App

Die St√§rken von Grails beziehungsweise Groovy haben sich besonders bei der Programmierung des Logins gezeigt. Dank der hauseigenen Dokumentation sowie zahlreicher Dokumente aus der Community lie√ü dieser sich mit den oben beschriebenen Anforderungen schnell umsetzen. F√ľr die sicherheitsrelevante Verschl√ľsselung der Login-Daten ist das Grails Plugin jasypt-encryption gut geeignet. Ebenso n√ľtzlich war aus unserer Sicht das View-Layer, kombiniert mit dem Einsatz von Groovy Server Pages (GSPs). Damit lie√ü sich der GUI-Teil unseres Projekts einfach implementieren.

Insgesamt ist uns sowohl der Aufbau von Grails als auch die Programmierung in der dazugeh√∂rigen Programmiersprache Groovy positiv aufgefallen. Die syntaktischen Erweiterungen von Groovy gegen√ľber Java helfen bei einer besseren Leserlichkeit und Handhabbarkeit des Codes. Auch f√ľr Apps, die ein h√∂heres beziehungsweise komplexeres Datenvolumen aufweisen, sind die beiden Technologien gut geeignet. Bei der Abw√§gung, ob Spring-Boot oder ein anderes Framework anstelle von Grails gew√§hlt werden soll, ist insbesondere der Gesichtspunkt der Performance zu beachten.

In punkto Datenbank w√§re Neo4J als Graphdatenbank zwar keine obligatorische Wahl gewesen, da die Datenrelationen in dieser App nicht allzu komplex sind. Es h√§tte also auch eine relationale Datenbank zum Einsatz kommen k√∂nnen. Aber auch wenn keine zwingenden fachlichen Gr√ľnde f√ľr eine Graphdatenbank vorliegen, ist Neo4J stets einen Blick wert. Die Vorteile sind die reibungslose Integration sowie die komfortable Bedienung.

Teil 1 und Teil 2 dieser Artikelserie finden Sie in unserer Rubrik Einblicke.

 

Einblicke

Shaping the future with our clients