Jobsuche Portal

SS22 – Dev4Cloud Projekt – von Robin Härle und Anton Gerdts

1. Ideenfindung

    Zu Beginn der Ideenfindungsphase für unser Projekt sahen wir uns die verschiedenen Apis auf Bund.dev an, um uns von der Thematik der verfügbaren Daten inspirieren zu lassen. Wir entschieden uns ohne lange abzuwägen dafür ein Jobsuche-Portal mit der Jobsuche API als Datenquelle zu kreieren, da der Inhalt unseres Projekts zweitrangig war und es uns mehr darum ging, technisch interessante Cloud-Dienste auszuprobieren. Als nächstes erstellten wir eine entsprechende Liste von Features die wir in unserer App einbauen wollten und realistisch umgesetzt werden könnten: Neben der klassischen Suchfunktion für Jobs nach Parametern wie Ort, Beschäftigungsart und Titel sollten sich User über eine Single-Sign-On oder Email-Registrierung authentifizieren können. Als authentifizierter User sollte man auf der Detailansicht eines Job-Angebots eine Chat- und Bewertungsfunktion nutzen können, welche über Websockets Echtzeit-Kommunikation mit anderen Usern auf derselben Seite ermöglichen sollten.

Anschließend entschieden wir uns, unser Projekt in der AWS Cloud umzusetzen, da uns hierfür bereits der AWS Cloud Foundations Videokurs zum Lernen zur Verfügung gestellt worden war und AWS im Rahmen des Free Tier sehr umfangreiche Funktionen bietet.

Das Backend bzw. die Cloud-Infrastruktur sollte über Terraform deployed werden; bezüglich des Frontend-Frameworks entschieden wir uns für Vue, da Robin damit schon viel Erfahrung hatte. Außerdem wollten wir das Component basierte UI-Framework Naive UI nutzen, um uns möglichst wenig mit Design und mehr mit der Funktionalität und den Cloud-Diensten beschäftigen zu können.

2. Umsetzung

Zum Start der eigentlichen Umsetzung der oben beschriebenen Webanwendung hatte Robin bereits vorab Cloud-Funktionen in der IBM Cloud implementiert, welche das Aktualisieren von Tokens zur Authentifizierung für die Jobsuche API übernahmen und somit einfache, direkte Abfragen der Job-Daten aus unserer App heraus ermöglichten.

Die User Authentifizierung realisierten wir über AWS Cognito. Wegen Zeitmangel war leider keine SSO-Authentifizierung mehr umsetzbar. Das Konfigurieren eines Cognito User-Pools funktionierte ohne Probleme, allerdings war die Integration dessen im Frontend schwieriger. Die Dokumentation des AWS SDK für JavaScript, dessen verschiedene Versionen und unterschiedliche Verwendung dieser sowie der Hinweis, dass man für die Authentifizierung über User-Pools (anstatt Identity Pools) eine dedizierte JavaScript Library verwenden soll (amazon-cognito-identity-js) waren unübersichtlich und sehr knapp. Zusätzlich war die API der erwähnten JavaScript Library umständlich designed (z.B. sind User-Daten nach Authentifizierung nicht direkt zugreifbar, sondern müssen jedes mal über eine Methode mit Callback für Success und Failure abgerufen werden). Aus diesem Grund implementierten wir eine Wrapper-Klasse, die für unseren Usecase eine optimierte API bereitstellte.

    Die Live-Chat Funktion realisierten wir über ein Zusammenspiel aus zwei Dynamo-DB Tabellen, drei Lambda Funktionen und einer Websocket API-Gateway Resource. Beim Aufruf einer Job-Detailansicht wird eine Verbindung mit dem Websocket Endpoint aufgebaut. In der “Connections” Dynamo-DB Tabelle wird die Connection-Id der Job-Id der aufgerufenen Detailansicht zugeordnet. Außerdem werden aus der “Comments” Tabelle alle Kommentare des aktuellen Jobs abgerufen und an den Client geschickt. Postet dieser ein neues Kommentar wird dieses in die “Comments” Tabelle gespeichert und an alle Connections, die in der“Connections” Tabelle der gleichen Job-Id zugeordnet sind, gebroadcastet Wird die Job-Detailansicht geschlossen wird auch aus der “Connections” Tabelle der Eintrag mit der Entsprechenden Connection-Id gelöscht.

Hierbei stießen wir auf zwei Probleme: Das erste bezog sich auf Terraform und zeigte, dass die Nutzung von Terraform nicht nur wie anfangs erwartet ein “Segen” wegen einfacherer Nachvollziehbarkeit und Reproduzierbarkeit der Infrastruktur in Code-Form ist, sondern auch Nachteile mit sich bringt: In vielen Fällen werden beim Erstellen von Cloud Ressourcen über die AWS Management Console Parameter automatisch passend konfiguriert, z.B. bei der Integration von Lambda-Funktionen mit einer API-Gateway Route: hier werden unter anderem “Invoke-Permissions” der Lambda-Funktion automatisch gesetzt, d.h. die Lambda-Funktion wird so konfiguriert, dass sie vom API-Gateway getriggert werden darf. Diese und andere Attribute muss man beim Verwenden von Terraform selbst korrekt setzen, was nicht immer einfach ist, da die Dokumentation von Terraform bezüglich solcher “Detail-Attribute” sehr knapp ist.

Das zweite Problem bestand darin, dass sich der gewohnte DevOps-Workflow nicht ohne weiteres mit der Entwicklung von Code für Serverless Cloud-Services wie Lambda-Funktionen vereinen lässt.

Anders als das Frontend einer Webanwendung konnten wir den Code einer Lambda Funktion nicht ohne weiteres in einer lokalen Testumgebung auf unseren Rechnern testen und die Zeit sich in entsprechende Tools wie z.B. das AWS SAM CLI einzuarbeiten fehlte uns. In unserem Fall genügte es den Code zwar in einem Git Repository zu versionieren, allerdings über die AWS Management Console zu testen und zu deployen. In Zukunft wäre es ideal für jegliche Serverless Services Testumgebungen für Entwicklungsrechner und Runner der Git Testing-Pipelines zu erstellen. Damit könnte Anwendungscode den üblichen DevOps Lifecycle durchlaufen und müsste nicht in der Cloud selbst getestet werden, wodurch vermieden werden könnte, dass Fehler bei der Entwicklung (z.B. fehlerhafte Bedienung der AWS Management Console) Cloud Ressourcen zum Absturz o.ä. bringen.