Mittlerweile haben wir unsere Serverkomponente „amigo-platform“ als Prototyp in Betrieb genommen und den Großteil der geplanten Funktionalitäten implementiert. Amigo-platform ist ein Webservice, der als zentraler REST-Endpoint für unsere Apps fungiert. Um Testbarkeit, Community-Mitwirken und Maintainability zu erhöhen, haben wir uns für Spring Boot + Konsorten entschieden und mit Kotlin entwickelt. Die REST-Dokumentation wird automatisch erzeugt und laufend erweitert und ist öffentlich einsehbar. 

Cloud-Architektur 

In unserer Infrastruktur arbeiten wir mit Jitsi, um Video-Calls und Audio-Calls als Conference-Calls oder 1-on-1-Rooms zur Verfügung zu stellen. Jitsi wird als eigenständiger Service in einem docker-compose gemanagt. Ursprünglich wollten wir noch ein Storage-Tool wie MinIO verwenden, aus Komplexitätsgründen verzichten wird derzeit darauf, da es a) nicht notwendig wurde und b) mehr Ressourcen brauchen würde als Spring Boot alleine. Alle Daten werden in eine PostgreSQL-DB persistiert.

Neben den zentralen Verwaltungstools (User & Gruppen, Authentifizierung) sind die beiden wesentlichen Ziele der amigo-platform die Kommunikationsfunktionalitäten mittels Jitsi und per Messages, sowie die Multimediaverwaltung von Alben und Bildern. Wir hätten dies zwar auch als drei Microservices gestalten können, aber aufgrund der Kompaktheit des Projekts, sowie des zusammenhängendes Kontexts haben wir diese Domain als einen Bounded Context innerhalb eines Services modelliert. 

Features 

Authentifizierung & Autorisierung per JWT 

Als Authentication method verwenden wir JWT (Json Web Tokens) um unsere REST-Api entsprechend abzusichern. Bis auf die authentication endpoints selbst ist jeder Endpunkt abgesichert und nur eingeloggten Usern zugänglich. 

Mit Login, Registrierung und “Passwort vergessen” sind die notwendigen Methoden vorhanden. Mit einem Refresh Token, der  durch die Authentifizierung per Login langlebig zugewiesen wird, kann ein AccessToken geholt werden, mit dem dann auf die Endpunkte zugegriffen wird. Dadurch bleiben wir offen, um später eine eventuell notwendige OAuth-Flow-Architektur auch für andere Services bereitzustellen. 

Benutzer und Gruppen-Verwaltung 

Amigo-platform ist auch der Hauptservice für Accounts, Personen und Gruppen. Hier werden Berechtigungen und Zugehörigkeiten verwaltet, beispielsweise welche Digitals (Angehörige) in der gleichen Gruppe mit einem Analogue (Senior:in) sind und kommunizieren können.

Personen in einer Gruppe können alle mit dem Analogue kommunizieren, des Weiteren kann ein Admin die Gruppe verwalten und konfigurieren. 

Multimedia-Verwaltung 

Die Digitals können dem Analogue Multimedia-Dateien (Bilder, Audio, Video) schicken und bereitstellen. Dies kann einerseits als Message mit angehängtem Multimedia passieren oder als Freigabe auf ein Album. Dafür ist es notwendig, die Entitäten Album und Multimedia als Relationen abzubilden und Freigabeberechtigungen und Aktualisierungen zu verwalten. 

In unserem ersten Prototyp ist das Teilen nur innerhalb der Gruppe möglich, durch weitere Evaluationen und Usability Testing erwarten wir uns hier weitere Anforderungen und neues Verständnis von User Needs. 

Kommunikationsmöglichkeiten 

Das zweiter Herzstück des Servers ist die Kommunikationsplattform. Unser Spring-Boot-Service hat die Aufgabe, Messages zu erzeugen und zuzustellen sowie als Portal für Jitsi-Calls zu dienen. Die Messages werden per REST-Call erzeugt und zur Notification des Empfängers mit Firebase Cloud Messaging weitergeleitet, da dies State-of-the-art für Android-Apps ist. Die Apps erhalten diese Notification, welche lediglich IDs und keine personenbezogenen Daten enthält, und lädt damit von der Amigo-platform die Nachrichten und Multimedia-Files herunter zur lokalen Verwendung  

Die Integration von Jitsi war durchaus ein komplexes Thema: Jitsi bräuchte zunächst keine Hilfe; jeder Benutzer könnte sich per Jitsi-Website einen neuen Raum aufmachen und beitreten. Leider könnten dann beliebige Leute auch beitreten, und wir hätten ein Datenschutz und Security-Problem. Aus dem Grund übernimmt auch hier unser Server die zentrale Kontrolle und erzeugt für alle erlaubten Parteien eigene kurzlebige JWT-Tokens und eine Jitsi-Raum-URL. Nur mit den JWT-Token kann bei den Räumen beigetreten werden, die Apps müssen also über amigo-platform einem Call (im Amigo context) beitreten, dann erst kann eine Verbindung zu dem Jitsi-Call im Jitsi Context hergestellt werden. Das Prozedere mit JWT ist von Jitsi gut umgesetzt und erfüllt somit unsere Security-Bedürfnisse und ist ein gängiges Konzept von verteilten Systemen. 

Die folgende Dokumentation beschreibt unseren REST-API auch für andere Entwickler, und wird auch laufend ergänzt: 

• REST-API: https://ossi-austria.gitlab.io/amigo-server/develop/rest-api.html 
• Gitlab: https://gitlab.com/ossi-austria/amigo-server 

Das kommt als Nächstes

Neben der Amigo Server-Backend entwickeln wir die Prototypen für unsere zwei Android-Apps: “AmigoBox” für Analogues (Senior:innen)s und die “AmigoApp” für Digitals (deren Angehörige). Aktuell werden Interaktionsdesignprototypen finalisiert und die Arbeit an den Android-Prototypen ist in vollem Gange. Mehr dazu gibt es im nächsten Blog-Post.