Backend API

Die Backend-API wird verwendet, um zwei Anforderungen zu erfüllen.- Speichern und Verwalten der Plättchen Verwaltung der aktiven Sitzungen

Funktionen:

Im Kontext von Plättchen:

• Neue Plättchen erstellen und Speichen
• Plättchen als JSON ausliefen
• Bestehende Plättchen bearbeiten
• Plättchen löschen.

Im Kontext von Sitzungen:

• Neue Sitzung erstellen
• Sitzung beitreten
• Plättchen platzieren
• Plättchen bewegen
• Plättchen im Feld löschen
• Sitzungaktivität übertragen
• Sitzungsinaktivität übertragen
• Sitzung verlassen.

Technische Umsetzung:

Für die Entwicklung des Backends wurden auf familiäre und bereits getestete Bibliotheken und Technologien gegriffen um den Entwicklungsprozess zu beschleunigen und auch die nachkommenden Entwicklern das Einsteigen in dem Projekt zu erleichtern.

Hierfür wurden folgende Technologien gewählt:

• NodeJs
• Express
• MongoDB
• Mongoose
• Multer
• SocketIO.

NodeJS

NodeJS ist eine JavaScript-Laufzeitumgebung, die auf Server läuft. Es ermöglicht Server Code mit JavaScript/TypeScript geschrieben. Durch die Erfahrung von der Entwicklung mit TypeScript im Frontend ist es jedem Entwickler dadurch möglich auch im Backend zu arbeiten. So muss keine andere Programmiersprache vorausgesetzt werden, um am Projekt zu arbeiten.

Express

NodeJS wird sehr oft dafür verwendet, um Web Server zu erstellen, die Daten liefen. Da es eine Aufgabe ist, die so oft vorkommt, wird die Bibliothek, Express genutzt. Express bietet standardisierte Funktionen, um Webservern in wenigen Schritten aufzusetzen.

MongoDB

Bei der Wahl der Datenbank wurde auf eine NoSQL Datenbank namens MongoDB gegriffen, da die Daten, die im Projekt verwendet, werden keine Relationen zueinander hat. Das heißt, dass, die Daten in simplen Objekt Format (JSON) gespeichert werden können. MongoDB wurde explizit gewählt, da es bereits Vorwissen zugab zu der Technologie, da die in anderen Projekten bereits verwendet wurde.

MongoDB bietet an, beliebige viele und unterschiedliche Objekt in einer Datenbank zu speichern. Diese Freiheit bedeutet jedoch, dass es zu Unregelmäßigkeiten im Code kommen kann. Aus diesem Grund musste vorher entschieden werden, wie genau ein Objekt auszusehen hat, bevor es gespeichert wird.

Dazu wurde ein Schema Definitionstool genutzt, namens Mongoose.

Mongoose:

Mongoose ist eine MongoDB Schema Definitionstool, womit festgelegt werden kann, wie ein Objekt aufgebaut ist, bevor es gespeichert wird. Das bietet auch den Vorteil dass, mit dem Schema, besonders in Verwendung mit TypeScript, ein Objekt validiert werden kann, bevor es verarbeitet wird.

Es wurde entschieden, das Schema so zu definieren:

Jedes Plätzchen muss einen Namen haben, einer Kategorie gehören und eine Referenz auf das Plättchen als PNG. Da der Name und die Kategorie in der Prototyping Applikation verwendet worden, ist es Pflicht, dass die angegeben werden.

Das Plättchen musste als PNG gespeichert werden, da es Komplikationen bei der Verwendung dieser Plättchen gab.

Es wurden verschiedene Alternativen getestet und ein Bild vom Plättchen hat sich als beste Methode zur momentanen Entwicklung herausgestellt, mit Anbetracht der Zeit und Aufwand.

Andere Methoden waren:

Dynamische Erstellen der Formen von Plätten in der Prototyping Applikation

Über einen Vektor von bestimmten Punkten konnte Polygone erzeugt werden, die die Form des Plättchen darstellen. Das Problem an dieser Methode ist jedoch, dass diese Koordinaten entweder pro Kachel gespeichert werden mussten oder die werden über eine Funktion deren Kategorien zugeordnet und gezeichnet. Visuell war es die schönste Methode, aber technisch die statische Methode. Bei der Annahme, dass sich die Form eines Plättchens ändert, müssen die neuen Vektoren berechnet werden und im Code geändert werden. Das erfordert Programmierkenntnisse und ein gutes Verständnis für den Code. Es erlaubt den Betreibern und Forscher im Projekt nicht Formen schnell zu ändern.

Darstellung der Plättchen als SVGs

SVGs sind skalierbare Vektorgrafiken, die einfach zu erstellen sind, mit Tools wie Photoshop, Canva oder Figma. Durch das Verwenden von SVGs könnte der Redakteur (Forscher oder Betreiber) Formen als SVGs erstellen und einfach hochladen. Das Problem an SVGs ist jedoch, dass, sie keine Dragging Funktionalitäten besitzen. Das heißt, dass man die Plättchen nicht bewegen kann, was ein Verstoß gegen die Akzeptanzkriterien des Projekts sind. Im Gegensatz zu SVGs besitzen PNGs eine Dragging Funktion. Jedoch sind PNGs nicht so Skalierbare wie SVGs. Das war jedoch ein Nachteil der verkraftbar war.

Speichern der PNGs

Die PNGs der Plättchen konnten auf verschiedene Weisen gespeichert werden. Es wäre möglich gewesen, die Bilder in einem externen Speichervolumen eines drittanbieteters zu speichern. Die Objekte in der lokalen Datenbank könnten einfach dass über die URL eine Referenz auf das Bild haben, womit die aufgerufen werden könnten, aber das würde für die Größe des Projekts eine nicht notwendige Abhängigkeit erzeugen.

Es ist auch möglich, die Informationen des Bildes als RAW Data (Text) mit in den Objekten zu speichern. Das würde aber die große von jedem Objekt in der Datenbank erhöhen, was die Netzwerkauslastung ebenfalls erhört bei der Nutzung der Applikation.

Die letzte und gewählte Methode ist es, die Bilder in einem Verzeichnis des Webservers zu speichern und im Objekt in der Datenbank die Referenz das pflegen. Dies spart uns eine Abhängigkeit sowohl als auch Datenvolumen bei der Größe von jedem Objekt, die gespeichert wird.

Um diese Methode auszuführen, wurde das Paket Muster verwendet.

Multer

Multer erlaubt dem Webserver Dateien als Nutzer Input zu verarbeiten. Die abgegebenen Dateien können über Multer nach Dateiformat und Größe validiert, bevor die in ihr festgelegtes Verzeichnis gespeichert werden. Mutter liefert ebenfalls auch die Referenz auf das Bild als URL zurück. Eine Besonderheit, die bei Mutter beachtet werden muss, ist, dass Multer Dateien nicht automatisch löscht, wenn der Datenbankeintrag dazu gelöscht wird. Es muss also manuell sichergestellt werden, dass die Datei aus dem Verzeichnis gelöscht wird. Dies kann aber über Node.js separat behandelt werden.

SocketIO

Um Ereignisse von allen Benutzern in einer Sitzung miteinander zu synchronisieren, wurde SocketIO ins Projekt eingebunden. Werden Daten aus dem Frontend an den Server geschickt, können diese über SocketIO empfangen und verarbeitet werden. Im Falle des Projekts, senden bei bestimmten Aktionen, die der Frontendapplikationen und Nachrichten mit angehängten Daten an den Server. Werden diese empfangen werden, die verarbeitet und weitergeschickt. Die Daten werden auf dem Server persistent pro Sitzung in einem Objekt gespeichert, die bei jeder Aktion an die Frontendapplikation gespiegelt wird. Sollte der Server jedoch ausfallen werden diese Daten gelöscht.

Auf dem Server gibt es neun Nachrichten, worauf der Server hört.

room-create

Wenn ein Nutzer die Frontendapplikation aufruft, verbindet diese/r sich automatisch über Websocket mit dem Server. Sollte der Nutzer eine Sitzung erstellen, wird dieser weitergeleitet und die „room-create“ Nachricht wird an den Server geschickt, mit den Nutzernamen und die ID der Sitzung. Daraufhin wird die Sitzung im Server gespeichert.

Join-room

Sollte ein Nutzer die eine bereits laufende Sitzung beitreten wollen, kann er/sie dies tun, indem beim Aufruf der Applikation den Namen und die ID der Sitzung angegeben wird. Daraufhin wird die „join-room“ Nachricht an den Server geschickt mit den angegebenen Daten. Auf dem Server wird geprüft, ob eine Sitzung mit dieser Nummer existiert. Ist dies der Fall, wird der Nutzer weitergeleitet auf die Sitzung und die Daten des Nutzers in der Sitzungsdaten hinzugefügt. Zuletzt bekommt der Nutzer die gesamten Sitzungsdaten zugeschickt, damit er/sie die bereits vergangenen Ereignisse mitbekommt.

Wenn die angegebene Sitzungsnummer nicht gefunden werden kann, wird eine Fehlernachricht an den Nutzer geschickt.

Tile-drop

Wenn ein Nutzer in einer Sitzung ein Plättchen bewegt und seine Position verändert, sollen alle anderen Nutzer der Sitzung dies ebenfalls mitbekommen. Aus dem Grund wird nach jedem bewegen von einem Plättchen die „tile-drop“ Nachricht an den Server geschickt. Diese Nachricht wird an alle anderen Nutzer in der Sitzung zu Echtzeit verbreitet.

Tile-drag

Ebenfalls wie „tile-drop“ sollen alle Nutzer zu Echtzeit mitbekommen, wenn ein Plättchen gezogen wird.

Cursor

Um die Echtzeitaktivitäten von anderen Nutzern in der Sitzung sichtbar zu machen werden die Bewegungen vom Mausiger jeden Nutzers an den Server gesendet und gespeichert. Zeitgleich werden diese an alle anderen Nutzern geschickt.

Tab-focus

Es wurde festgelegt, dass keine Cursor-Aktivitäten an den Servern geschickt werden sollen, wenn die Applikation im Browser sich nicht im Fokus befindet. Deshalb wird jedes Mal, wenn das Browserfenster sich nicht im Fokus befindet, die „tab-focus“ Nachricht an den Server geschickt, mit dem booleschen Wert „true“ oder „false“. Dieser Wert wird im Browser gelesen und bei false den Cursor vom Benutzer ausgeblendet, die zu dem Zeitpunkt nicht aktiv ist.

Tile-delete

Sollte ein Nutzer in der Sitzung ein Plättchen löschen, was sich im Feld befindet, wird diese Aktion an den Server gesendet. Daraufhin wird das Plättchen aus den Sitzungsdaten gefiltert und an alle anderen Nutzer widergespiegelt.

Disconnect

Die disconnect Nachricht behandelt die Logik dafür, dass ein Nutzer eine Sitzung verlässt oder die Applikation schließt.

Wenn ein Nutzer die Sitzung verlässt, wird geprüft, ob sich andere Personen noch in der Sitzung befinden. Falls dies der Fall ist, wird der Nutzer aus den Sitzungdaten entfernt und die übrigen Nutzer benachrichtigt.

Falls der Nutzer alleine ist, wird die gesamte Sitzung beendet und gelöscht.

Error

Error gibt bei Serverproblemen den Fehler in der Konsole aus. Es sollte aber noch spezifiziert werden, wie mit Fehlern umgegangen wird. Eine mögliche Lösung dafür wäre es Log Dateien zu nutzen, wo die Errors reingeschrieben werden.

Backend API für Plättchen

Die Backend-API bietet nach dem REST (Reprisentational State Trasfer ) Standard Operationen an, um die Plättchen zu lesen, erstellen, aktualisieren und löschen (CRUD). Die Daten werden im JSON (JavaScript Object Notation) ausgegeben.

Diese Operationen können nur von den Betreibern der Applikation verwendet werden. Um die CRUD Operationen möglichst einfach zu verwenden, wird eine separate React Applikation angeboten. Dieser ist ebenfalls in TypeScript geschrieben und mit TalwindCSS gestaltet. Es bietet eine einfache Rasteransicht, um die bereits vorhandenen Kacheln zu sehen. Über ein Formular ist es möglich eine neue Kachel zu erstellen, die in die Datenbank gespeichert wird.

Man kann mit einem Klick auf ein bereits erstelltes Plättchen kann diese auch editiert werden.