Im Rahmen des Semesterprojektes (WS22) der Masterklasse Mobile wurde von den Studierenden Eva Altenburger, Ramon Brullo, Lukas Ganster, Fabian Gaugusch, Michelle Markl, Lisa Polena und Alex Schuster die Idee einer App für kollektives Musikhören bei Partys konzipiert und implementiert. Dieser Artikel wurde gemeinsam verfasst und stellt kurz und bündig den Projektumfang sowie die wichtigsten Eckdaten dar.

Einleitung

Jeder und jede weiß, dass bei einer erfolgreichen Party die passende Musik nicht fehlen darf und ein populärer Weg, um für gute Laune zu sorgen, ist eine Spotify-Playlist laufen zu haben. Mit der Spotify App kann aber nur immer eine Person die Hände am Steuer haben und die anderen Gäste können bei der Musikwahl nicht mitmischen. Um dieses Problem zu lösen, haben wir dieses Semester jukebox.party entwickelt.jukebox.party ist eine Web-App, die auch, und sogar spezifisch, für mobile Geräte optimiert ist, mit der eine Spotify-Session interaktiv von den Gästen einer Party gemanagt werden kann. Dabei braucht nur eine Person einen Premium Spotify-Account und ein Gerät für die Wiedergabe, damit die Party starten kann. Zugänglich ist die Developer-Version der App auf https://jukebox.herokuapp.com.

Featureumfang

Der Ablauf einer Party mit jukebox.party beginnt mit einer Person, die einen Premium Spotify-Account hat und die Party erstellt. Es wird ähnlich wie bei Kahoot ein eindeutiger Code generiert, über den andere Nutzer der Party durch eintippen oder einen QR-Code beitreten können.

In der Party kann man sehen, was gerade gespielt wird und welche Lieder als nächstes kommen. Auch Lyrics zum aktuellen Track kann man sich ansehen, falls man mitsingen will. Auch kann man das aktuelle Lied bewerten und sehen, welche Stimmen andere Party-gäste abgegeben haben. Diese Bewertungen sind in der History sichtbar, in der die bereits gespielten Tracks und deren Beliebtheit aufgelistet sind.

Als Host der Party hat man auch die Möglichkeit, das aktuelle Lied zu überspringen oder zu einem vorherigen zurückzukehren. Außerdem hat man die Berechtigung, Gäste aus der Party zu entfernen.

Das wichtigste Feature von jukebox.party ist jedoch das Mitbestimmen bei der Wahl der nächsten Tracks. Mithilfe einer Suchfunktion kann man seine Lieblingslieder finden und der Playlist hinzufügen. Falls man sich nicht sicher ist, kann man sich auch mit Vorschlägen, basierend auf den zuletzt gespielten Tracks, inspirieren lassen.

Technische Umsetzung

Bei der Applikation jukebox.party handelt es sich um ein Next.js-Projekt. Next.js ist ein Javascript Framework, das es ermöglicht, auf React basierende serverseitig gerenderte Webapplikationen zu erstellen. Wir haben uns für das Framework entschieden, da es nahe unseren persönlichen Skills und Interessen liegt und in einem Paket sowohl die Front-End- als auch die Back-End-Entwicklung vereint. Praktisch bedeutet das, dass das Front-End mit dem Javascript-Framework React geschrieben wird und gleichzeitig die Möglichkeit besteht, Javascript für die Server-Logik zu verwenden.

Als Datenbank wurde das von Google entwickelte Tool Firebase verwendet, da es neben der dokumenten-basierten einfachen Struktur auch die Möglichkeit für Echtzeitupdates bietet. Das bedeutet, dass mehrere Clients auf einen Datensatz, in unserem Fall eine Party, zugreifen und jegliche Änderungen dieser Party sofort an alle Clients übertragen werden.

Abgesehen von den gewählten Technologien basiert der Großteil der Funktionalitäten auf der von Spotify angebotenen Web-API. Diese bietet Entwickler:innen ein Reihe an verschiedenen Schnittstellen, die meist auch so in der bekannten Spotify-App zu finden sind. Speziell haben wir uns auf die “Queue”-basierten Schnittstellen fokussiert, da sich hier der meiste Content der Applikation abspielt.

Weiters wurden die meisten Komponenten und Backend-Schnittstellen auch Unit-tested. Dafür wurde die populäre Javascript Testing Library “Jest” verwendet. Auch eine CI-CD-Pipeline zur Versicherung eines robusten Deployment-Flows wurde mithilfe von “CircleCi” umgesetzt.

Herausforderungen bei der Entwicklung

Im Großen und Ganzen haben wir als Team sehr gut kommuniziert und funktioniert, sodass die Schwierigkeiten und Herausforderungen bei der Entwicklung minimal geblieben sind. Die erste und vielleicht größte Herausforderung war, dass die Spotify API nicht alle Funktionen zur Verfügung stellt, die wir gebraucht hätten. Am Anfang des Projektes hatten wir die Version, dass der Host der Party die Reihenfolge der Queue ändern und Lieder aus dieser entfernen kann. Allerdings hat uns da die API einen Strich durch die Rechnung gemacht, da sie leider diese Endpoints nicht anbietet. Somit mussten wir unser MVP überdenken und diskutieren, wie wir weiter vorgehen. Wir haben uns entschieden, diese Funktionen bei der ersten Version wegzulassen und wenn noch Zeit bleibt bzw. im weiteren Schritt die Queue bei uns zu hosten, damit wir die Funktionen einbauen können und Spotify immer nur den nächsten Track der Queue bekommt. 

Eine weitere Herausforderung für uns alle waren die neuen Technologien, die wir eingesetzt haben. Das Team hatte mit den Technologien vor diesem Projekt wenig bis keine Vorerfahrung und musste so in kurzer Zeit diese lernen. Hierbei handelt es sich besonders um NextJS, Next-Auth und Firebase. Zusätzlich kam die Herausforderung dazu, dass die neue Version von NextJS wenige Tage vor dem Beginn des Projektes erschienen ist und wir uns dazu entschlossen haben, mit der neuesten Version zu arbeiten. Allerdings unterscheidet sich diese, in ein paar Aspekten, stark von der Vorherigen und die Dokumentation war noch nicht so gut, zumal Version 13 erst ein paar Tage alt war. 

Andere kleinere Herausforderungen waren zum Beispiel, dass die Projektstruktur sich am Anfang stark verändert hat und die Entwickler/Entwicklerinnen sich erst wieder zurechtfinden müssen, bevor mit dem Task weitergemacht werden konnte. Zusätzlich war es eine kleine Herausforderung, sich in den Code wieder einzulesen und die eigenen Funktionen wiederzufinden, nachdem der Code ein Refactoring bekommen hat. Allerdings sind wir für das Engagement unseres Teamkollegen sehr dankbar und haben dadurch auch einiges Neues gelernt.

Umsetzung mittels agilem Projektmanagement

Für die Umsetzung von Jukebox.party wurde ein agiler Ansatz ganz nach den Grundprinzipien des Scrum-Framework gewählt. Gearbeitet wurde mit dem Atlassian Tool Jira, welches sich im Bereich der Softwareentwicklung mittlerweile als Industriestandard durchgesetzt hat. Die verfügbare Arbeitszeit des Semesters wurde von Anfang November 2022 bis zur Projektevernissage im Jänner 2023 in insgesamt 6 Sprints aufgeteilt, wobei die jeweilige Sprintdauer variabel war.

Zum Ende eines Sprints gab es immer ein kurzes Sprint Review bzw. Sprint Planning für die nächsten Arbeitspakete in der jeweiligen Einheit der Masterklasse Mobile. Anfangs hatten wir uns auch um die Durchführung von Scrum spezifischen Techniken und Methoden wie Planning Poker oder dem exakten Definieren von User Stories bzw. Akzeptanzkriterien bemüht, merkten aber schnell, dass es für unser Teamaufstellung und unser Setting der geeignetere Modus Operandi wäre, die Arbeitspakete immer beim Planning vorab kurz zu definieren und dann auch frei aus dem Sprint-Backlog weg abzuarbeiten.

Präsentation bei der Projektevernissage

Bei unserem Stand für die Projektevernissage haben wir uns auf das Wesentliche konzentriert. Auf dem Haupttisch haben wir ein iPad ausgestellt, auf dem eine Party erstellt wurde. Abgespielt wurden die Songs über einen kleinen Lautsprecher. Daneben gab es auch ein iPhone, das als Gast bei der Party angemeldet war. So konnten wir den Besuchern beide Varianten zeigen. Natürlich konnten sie auch einfach selbst in die Party einsteigen und einen Song zur Warteschlange hinzufügen. 

Auf dem Poster konnte man neben Screendesigns auch einen QR-Code sehen. Dieser führte zu einem Linktree mit Verlinkungen zur Startseite von jukebox.party. Zusätzlich gab es auch einen Link zu einem Google Form, um sich für die Nutzung dieser Version anzumelden. 

Dadurch, dass bei unserem Stand Musik lief, interessierten sich einige Besucher für unseren Stand. Das Interesse war sehr groß und die Idee hat eigentlich jedem, der mit uns geredet hat, gefallen.

So geht es weiter

Mit der Projektevernissage haben wir unser erstes großes Ziel erreicht. Hier hat das Projekt bei den Standbesucher*innen großes Interesse geweckt und das Feedback war durchweg positiv. Einige der Besucher*innen wollten die Applikation direkt bei der nächsten eigenen Geburtstagsfeier, Familienfeier oder Ähnlichem nutzen. 

Zurzeit befindet sich das Projekt im Developer-Modus bzw. wird der Developer-Modus der Spotify API genutzt. Das bedeutet, dass Personen, welche jukebox.party nutzen möchten, im Developer Dashboard des Projekts eingetragen werden müssen. Hier können bis zu 25 Spotify Accounts, eingetragen durch die genutzte E-Mail Adresse bei Spotify, vermerkt werden. Ist der Spotify Account in dieser Liste hinterlegt kann unsere Applikation von bis zu 25 Nutzer*innen genutzt werden. Diese 25 hinterlegten Spotify Accounts beziehen sich bei unserer Projektidee nur auf die Hosts einer Party, da die Partygäste auf die Warteliste des Hosts zugreifen und nicht selbstständig über ihren eigenen Account Requests an Spotify senden.

Aufgrund des durchweg positiven Feedbacks bisher, überlegt die Projektgruppe, die Projektidee bei Spotify vorzustellen, um den ‘extended quota modus’ zu erhalten. Dieser Modus erlaubt eine höhere Serveranfrage-Rate und die Nutzung der Applikation durch unendlich viele Nutzer*innen (das Eintragen der Spotify-Accounts in die Liste entfällt). Jedoch muss hierfür ein Antrag mit einer Beschreibung des Projekts, mittels eines Formulars, bei Spotify eingereicht werden. Außerdem muss die Applikation einige Anforderungen erfüllen, welche in der Spotify Developer Policy festgelegt sind. Diese Regeln enthalten Kriterien zur Speicherung von (Nutzer*innen-)Daten, zum Branding, der Präsentation der Inhalte, etc. 

Das Projektteam plant als nächsten Schritt ein Code-Review, um die Wartbarkeit des Codes sicherzustellen. Außerdem sollen im Zuge dessen Bugs ermittelt und gelöst werden. Des Weiteren möchte die Projektgruppe die Spotify Developer Policy studieren, um feststellen zu können, welche Kriterien noch erfüllt werden müssen, um den ‘extended quota modus’ zu erhalten.Möglicherweise ist es bald soweit und jukebox.party bietet dir eine einfache Möglichkeit die Warteliste einer Party mit deinen Freund*innen zu gestalten – because music is always better with friends.

The post Jukebox.party – App für gemeinsames Musikhören appeared first on Mobile USTP MKL.

Performance und Security

In einer früheren Version von Lento wurden alle Requests, die an die Spotify-API geschickt werden, direkt vom Client-Gerät aus gesendet. Das hatte zur Folge, dass viele Requests redundant waren und auch hinsichtlich der Performance Luft nach oben hatten. Außerdem war die Idee im gesamten Funktionsumfang auch stark eingeschränkt, wenn die Daten zur Spotify-Authentifizierung nicht am Server, sondern am Client liegen. Funktionen wie die täglichen Empfehlungen oder die Playlisten von bestimmten Nutzer:innen waren nur eingeschränkt möglich.

Im Folge des dritten Semesters wurde aus technischer Sicht also in erster Linie ein Großteil der Spotify-bezogenen Logik vom Frontend (React Native App) ins Backend (Nest.js Server) verlagert. Dies bietet eine robuste Grundlage für die weitere Entwicklung und Skalierung der Software.

Farbe des Album-Covers durch Vibrant.js

Vibrant.js ist eine JavaScript-Bibliothek, die es ermöglicht, Farbpaletten aus Bildern zu extrahieren und diese Farben als JS-Objekte zu verwenden. Mit Vibrant.js können Entwickler:innen Farbpaletten aus Bildern generieren und diese Farben in ihren Webprojekten verwenden, um ein einheitliches Design zu erzielen oder Bildelemente hervorzuheben. Diese Library wurde in der neuen Version der Lento Api eingebettet und kann auch über die Schnittstelle https://lentoapi.herokuapp.com/dominantColor?url=albumartworkurl erreicht werden. Wie in Screenshot 3 ersichtlich, wurde damit die Anzeige der Songs bzw. Songcovers personalisierter gestaltet.

Next up

Im Rahmen des vierten Semesters und darüber hinaus ist geplant, die App weiterzuentwickeln und auch in naher Zukunft ein Minimal-Valuable-Product fertigzustellen. Ein Teammitglied (Fabian Gaugusch) arbeitet auch im Rahmen seiner Diplomarbeit an der App, speziell aus dem Aspekt der Datenvisualisierung, weiter.

The post Lento – Weiterentwicklung der Spotify-Social-Media-App appeared first on Mobile USTP MKL.

Technische Umsetzung

Für die Umsetzung der App, welche auf iOS und Android verfügbar sein wird, wurde die Library React-Native herangezogen. Ein wichtiges Augenmerk bei der Auswahl dieser Technologie waren die vielen Vorteile gegenüber vergleichbaren Frameworks wie Ionic (Handling des Back-Buttons) oder Flutter (Programmierung mit Plain JS). Das Testing während der Entwicklung lief mit dem Package Expo, welches eine stetiges Livetesten der App auf dem eigenen Smartphone mittels der Expo-App ermöglicht. Für das Backend wurde NestJS verwendet, was die wesentlichen Funktionalitäten einfach und recht unkompliziert bereitstellte. Noch dazu war hierbei ein wichtiges Argument, dass wir mit Armin Kirchknopf immer einen zuverlässigen Ansprechpartner bei etwaigen Problemen bzw. Herausforderungen mit der Technologie hatten. Die Datenspeicherung läuft über eine dokumentbasierte MongoDB-Datenbank, welche wir über die Laufzeit des Projektes zu lieben (und hassen) gelernt haben. Für die Spotify-Daten bzw. den Input Richtung soziales Netzwerk nutzten wir die offizielle Spotify API, welche vor allem am Anfang hinsichtlich Login-Prozess eine kleine Hürde war.

Funktionsübersicht

Im Wesentlichen soll es, wie bereits beschrieben, möglich sein, seine Meinung über bestimmte Songs, Alben oder Playlists mit anderen Personen (bereits bekannte Spotify-Follower:innen oder neue Leute) zu teilen. Lento soll hier als Austauschs- und Diskussionsplattform agieren und ein Ort sein, wo man gleichgesinnte Leute hinsichtlich des Musikgeschmackes (wir nennen es ‘Soulmates’) finden kann. Eine Visualisierung von ausgewählten Key-Features bzw. Eigenschaften eines Songs wie beispielsweise die tanzbarkeit oder die energy sollen auch visualisiert werden. Besonders wichtig ist hier auch die soziale Komponente in der Aktivitätsübersicht (analog zu Facebook bzw. Instagram), wo man die Aktivitäten von Personen, denen man in der App folgt, sehen kann

Learnings

Das Projekt hat wieder mal gezeigt, wie wichtig die sorgfältige Planung im Vorhinein für den späteren Verlauf des Entwicklung ist. Besonders gegen Ende des Semesters sind viele Pain-Points (zB.: Schlecht geschriebener/ unperfomanter Code) aufgefallen, die es im Fortlauf des Studiums zu beheben gilt. Die Verwendung von React-Native bzw. NestJS war mit Sicherheit die richtige Entscheidung, weil sich bis jetzt dadurch wenige Downsides aufgetan haben und die positiven Aspekte auf jeden Fall überwiegen.

Ausblick

Die Entwicklung von Lento ist mit dem aktuellen Stand (20.Juni 2022) noch lange nicht abgeschlossen. Geplant ist eine Fortführung der Plattform im 3.Semester (Refactoring, Neue Kernfeatures bzw. Beta-Phase) sowie eine Einreichung beim Creative-Pre-Incubator.

Im Rahmen der Lehrveranstaltung Tun-Forschen-Gründen wurde Lento auch als Business-Idee präsentiert. Die dazugehörigen Folien zum Pitch finden sich im Anhang dieses Artikels.

Um einen Einblick in das Look and Feel der App zu bekommen kann auch gerne der Figma-Prototyp durchgeklickt werden.

TFG-Pitch Folien

The post Intro – Lento: Soziale Plattform aufbauend auf Spotify appeared first on Mobile USTP MKL.

CI/CD-Workflows und DevOps-Testumgebungen werden durch die Verwendung von Docker, das im Wesentlichen eine Reihe von Softwaretools ist, die gemeinsam genutzt werden können, erheblich verbessert. Kubernetes ist ein weiteres Tool, das für den Betrieb mehrerer Docker-Container verwendet wird, allerdings in einem viel größeren Maßstab. Das wird vor allem relevant, wenn man bei seinen Anwendungen von Skalierbarkeit spricht.

In diesem Beitrag zeige ich, wie man ein NodeJS Express-Backend und ein React-Frontend in einem Docker-Container erstellt und betreibt.

Inbetriebnahme eines Node-Backends in Docker

Bevor ihr beginnt, solltet ihr sicherstellen, dass Docker auf eurem Computer installiert ist und läuft.

Nun navigieren wir in ein Verzeichnis, wo unser Docker-Container platziert werden soll. Anschließend werden folgenden Code-Zeilen ausgeführt.

mkdir my-app-docker
cd my-app-docker
touch docker-compose.yml
mkdir api
cd api
npm init -y
npm i express
touch app.js Dockerfile .dockerignore
cd ..

Wir haben ein Backend namens api eingerichtet und einige Docker-Dateien erstellt. Öffnen wir nun das Projekt in unserem Code-Editor und fügen den untenstehenden Code in die entsprechenden Dateien ein.

Fügen den Code in die Datei docker-compose.yml ein. Die Formatierung der yaml-Datei muss sorgfältig vorgenommen werden, da sonst Docker-Fehler auftreten, wenn versucht wird, die Datei auszuführen.

version: '3.8'
services:
  api:
    build: ./api
    container_name: api_backend
    ports:
      - '4000:4000'
    volumes:
      - ./api:/app
      - ./app/node_modules

Und folgender Codeblock wird in die app.js – Datei geschrieben und repräsentiert unser Node-Backend.

const express = require('express');

const app = express();

const port = process.env.PORT || 4000;

app.get('/', (req, res) => {
  res.send('Home Route');
});

app.listen(port, () =>
  console.log(`Server running on port ${port}, http://localhost:${port}`)
);

Anschließend kann man das .dockerignore – File so konfigurieren, dass der node_modules-Ordner, ähnlich wie beim Git-Ignore, nicht mitprotokolliert wird. Einfach folgende Zeile beifügen.

node_modules

Desweiteren wird folgender Code in die Datei Dockerfile hinzugefügt.

FROM node:16-alpine

WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

EXPOSE 4000

CMD ["node", "app.js"]

Abschließend wird noch folgender Abschnitt ins package.json – File hinzugefügt:

"scripts": {

 "start": "node app.js"

},

(Optional) Nodemon um automatische Server-Restarts bei Änderungen zu ermöglichen

Wenn man möchte, dass der Server jedes Mal neu startet, wenn man eine Änderung an den Dateien im Backend vornimmt, kann man ihn für die Verwendung von Nodemon konfigurieren.

Dazu ist es ausreichend, die Dockerfile– und package.json-Datei im api-Ordner zu aktualisieren.

Aktualisiere den Code in der Dockerdatei mit dem unten stehenden Code. Wir installieren nun Nodemon beim Start und verwenden dev als Ausführungsbefehl.

FROM node:16-alpine

RUN npm install -g nodemon

WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

EXPOSE 4000

CMD ["npm", "run", "dev"]

Natürlich muss auch das package.json-File wie folgt aktualisiert werden für die Verwendung Nodemon:

"scripts": {

 "start": "node app.js",

 "dev": "nodemon -L app.js"

},

Zusammengefasst wurde ein einfacher NodeJS Server mit Express, der auf Port 4000 läuft, aufgesetzt. Wichtig ist hierbei, dass auch der Port 4000 im Docker-Container “verwendet” wird, um sozusagen ein Mapping zu ermöglichen.

Starten des Servers

Um den Server außerhalb eines Docker-Containers (auf herkömmliche Art) mit Node wie gewohnt auszuführen, muss nur der folgende Code in der Kommandozeile eingegeben werden.

Dabei müssen vor allem die Inhalte des api-Ordners berücksichtigt werden. Wenn man http://localhost:4000 aufruft, sollte man die “Home-Route” in seinem Browserfenster sehen.

npm run start

Um die NodeJS Express-App innerhalb von Docker zum Laufen zu bringen, ist ein anderer Befehl erforderlich. Zunächst muss man sich im Stammverzeichnis befinden, in dem sich die Datei docker-compose.yml befindet. Anschließend führen wir den unten stehenden Befehl aus und die Anwendung sollte in einem Docker-Container laufen.

docker-compose up

Man muss natürlich darauf auchten, zuerst den Node-Server zu stoppen, da man nur einen Server auf Port 4000 laufen lassen kann.

Wenn man nun wieder auf http://localhost:4000 geht, sie man ebenso die “Home-Route”. Nur diesmal direkt aus Docker heraus.

Den Server kann man mit dem unten stehenden Befehl stoppen, oder man geht zur Docker-App und stoppt die Ausführung des Containers.

docker-compose down

Aufsetzen des React-Frontends in Docker

Im nächsten Schritt erstellen wir innerhalb unseres Docker-Containers ein React-Frontend. Dafür navigieren wir mittels der Kommandozeile in den Root-Ordner von my-app-docker. Einfach folgende Befehle fürs Setup ausführen:

npx create-react-app client
cd client
touch .dockerignore Dockerfile

Nun fügen wir den untenstehenden Code in die korrespondierenden Files ein:

Diese Zeile kommt, wie gewohnt, ins .dockerignore File:

node_modules

Genauso wie bereits oben, wird auch das Dockerfile File konfiguriert:

FROM node:17-alpine

WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Schließlich aktualisieren wir das docker-compose.yml File im Root-Ordner mit dem untenstehenden Codeblock. Im Gegensatz zu vorhin gibt es jetzt auch eine Sektion am Ende, die für die Einstellungen bzw. Konfigurationen des React-Frontend-Projektes stehen. Hier muss man wieder besonders vorsichtig mit der richtigen Formattierung des YAML-Files sein, um etwaige Docker-Fehler präventiv zu vermeiden.

version: '3.8'
services:
  api:
    build: ./api
    container_name: api_backend
    ports:
      - '4000:4000'
    volumes:
      - ./api:/app
      - ./app/node_modules
  client:
    build: ./client
    container_name: client_frontend
    ports:
      - '3000:3000'
    volumes:
      - ./client:/app
      - ./app/node_modules
    stdin_open: true
    tty: true

Grande finale – Starten der Applikation

Ähnlich wie vorhin kann man mit einem simplem Befehl die Applikation normal (außerhalb von Docker) starten. Sicher gehen, dass man im Folder der Client-App ist und den untenstehenden Befehl ausführen. Wenn man jetzt zu http://localhost:3000 geht, sollte man die Startseite einer Boilerplate-React-App sehen.

npm run start

Um die React-App innerhalb von Docker zum Laufen zu bringen, ist ein anderer Befehl erforderlich. Zunächst muss man sich im Root-Ordner befinden, in dem sich die Datei docker-compose.yml befindet. Anschließend sollte die App innerhalb eines Docker-Containers laufen, indem man den folgenden Befehl ausführen:

Natürlich darf auch hier nicht vergessen werden, die React-App auf Port 3000 zu beenden, da nur immer eine Applikation den Port 3000 verwenden kann.

docker-compose up

Erwartungsgemäß findet man auf http://localhost:3000 danach die laufende Applikation von React.

Schließen lässt sich die Anwendung hier, genauso wie beim Backend mit:

docker-compose down

Mit diesem Setup kann man ein NodeJS-Backend und ein React-Frontend gleichzeitig innerhalb von Docker laufen lassen! Wenn Fehler auftreten, muss man möglicherweise die Docker-Desktop-Anwendung öffnen und alle Images entfernen bzw. neu installieren, die mit diesem Projekt verbunden sind. Dann kann man versuchen, den Befehl docker-compose up erneut auszuführen und mit etwas Glück sollte dieses Mal alles wie erwartet funktionieren.

Quellen

Docker – Getting started

Towardsdev – React App In Docker

The post How To: Docker mit React und Node appeared first on Mobile USTP MKL.

https://github.com/PartyHubAT

Minispiel 1 – Exposed

Bei “Exposed” können die Nutzer, nachdem sie das Spiel betreten haben, eine der verfügbaren Kategorien auswählen (Normal oder Spicy). Abhängig von der gewählten Kategorie wird dann allen Nutzer:innen eine der Fragen aus der gewählten Kategorie präsentiert. Zusätzlich werden dann zwei der Spieler:innen herausgepickt und die restlichen Mitspielenden müssen sich dann für eine der beiden Personen entscheiden. Die präsentierte Frage richtet sich nach dem Motto “Wer würde am ehesten …” und stellt somit ein unterhaltsames Partyspiel dar. Nachdem alle Personen abgestimmt haben, wird das Ergebnis dann, natürlich schön visuell aufbereitet, präsentiert. Dieser Prozess wird beliebig oft wiederholt, bis jede Person mit jeder Anderen ein “Match”, also ein Voting hatte. Zum Endes des Spiels wird dann eine Zusammefassung aller durchgespielten Fragen bzw. der Gesamtanzahl der Votingpunkte pro Spieler:in visualisiert.

https://github.com/PartyHubAT/game-exposed

Minispiel 2 – Heads Up

Das Spiel “Heads Up” ist ein Partyspiel in dem zwei Teams aus jeweils mindestens zwei Personen gegeneinander antreten und versuchen, mehr Punkte als ihre Gegner zu erreichen. Die Spieler:in, die gerade an der Reihe ist, hält sich ihr Smartphone an die Stirn, sodass ihre Mitspieler:innen den Bildschirm sehen können, sie selbst jedoch nicht. Auf dem Bildschirm ist ein Wort aus einer zuvor ausgewählten Kategorie zu sehen. Die Spieler:innen, die nicht an der Reihe sind, müssen nun versuchen, ihrer Mitspieler:in so viele Begriffe wie möglich innerhalb von 30 Sekunden zu erklären, wie möglich. Durch das nach vorne oder hinten Kippen des Smartphones kann die aktive Spieler:in ein richtiges Wort bestätigen oder ein zu schweres Wort überspringen. Pro Runde ist jede Spieler:in beider Teams einmal dran. Das Ziel des Spiels ist es natürlich, mehr Wörter als das Gegnerteam zu erreichen.

https://github.com/PartyHubAT/game-heads-up

Minispiel 3 – And then

Eine digitale Version, des klassischen Kinderspiels, bei dem man in der Gruppe eine Geschichte erzählen muss, indem man immer einen Satz zur Geschichte hinzufügt, aber immer nur den letzten Satz als Kontext kennt. Jeder Spieler beginnt einen Text mit einem Satz. Der Satz wird von jedem Spieler auf seinem Gerät eingegeben und sollte für die anderen Spieler nicht sichtbar sein. Wenn der Satz fertig ist, wird er abgeschickt und es wird gewartet, bis alle Spieler ihren Text begonnen haben. Als nächstes wird jeder Text zum “nächsten” Spieler weitergegeben, also rotiert. Dieser sieht von dem Text nur den zuletzt geschriebenen Satz und muss nun einen Neuen hinzufügen. Wenn alle Spieler fertig sind, werden diese Schritte wiederholt, bis alle Texte eine zuvor festgelegte Länge an Sätzen haben. Am Schluss werden die gemeinsam geschriebenen Texte den Nutzern präsentiert. Es gibt verschiedene Arten von Texten oder Genres, von denen Spieler wählen können, wie beispielsweise Horror-geschichten, Rezepte und Rap-texte.

https://github.com/PartyHubAT/game-and-then

Technische Umsetzung

Das Projekt wurde mithilfe einer Kombination eines node.js-servers, vue-frontends und Kommunikation mittels http-requests und socket.io umgesetzt. Der Webserver erlaubt Zugriff auf das Frontend in dem sich die Spieler mithilfe von WebSockets in einen gemeinsamen Raum zusammenfinden können. Die Kommunikation hier ist bidirektional und in Echtzeit zwischen dem Server und allen Spielern. Jeder Spiele-entwickler stellt die eigene server-seitige und client-seitige Logik zur Verfügung die bei Auswahl und Start des Spiels geladen und an alle Spieler gesendet wird. Die Spiele werden im Frontend innerhalb eines iFrames gehostet und kommunizieren ebenfalls mithilfe von WebSockets mit dem Server.

Leasons learned

Beim Projekt „PartyHub“ haben sich die drei Studenten ein großes und aufwendiges Ziel gesetzt. Neben dem Implementieren eines Spieles von jedem der drei Mitglieder war die Hoffnung von PartyHub, es anderen Student:innen zu ermöglichen, ihre eigenen Spiele zu programmieren und dem PartyHub hinzuzufügen. Dies gelang den drei zwar, jedoch mit mehr Einschränkungen als geplant.

Im Laufe des Projektes waren sie mehrmals sowohl in technischer, als auch in organisatorischer Hinsicht vor Probleme gestellt, die zu lösen waren, bevor das Projekt gut voranschreiten konnte. Obwohl das Projekt letztendlich ihrer Meinung nach nicht zur vollständigen Zufriedenheit abgeschlossen werden konnte, diente es trotzdem als hervorragende Unterlage für neue Erkentnisse was die Arbeit im Team und die technische Umsetzung eines solchen Projektes betrifft.

The post PartyHub – Semesterprojekt WS21 appeared first on Mobile USTP MKL.

Grundlegender Aufbau von HTTP

Aus einer Zusammenarbeit der IETF (Internet Engineering Task Force) und dem W3C (World Wide Web Consortium) wurde ein weltweit gültiger Standard für das Hypertext Transfer Protocol entwickelt. Das Übertragunsprotokoll wird zustandlos betrieben, was bedeutet, dass Informationen von früheren Anforderungen nicht gespeichert werden. Durch Konzepte wie Cookies oder Local Storage wird es Programmen möglich gemacht, bestimme Informationen (zum Beispiel die Artikel eines Warenkorbes) entsprechend zuzuordnen. Durch die Verwendung des zuverlässigen und verbindungsorientierten Transportprotkolls TCP können nicht nur Hypertext-Übertragungen stattfinden, sondern jegliche Art von Datne übertragen werden.(Was ist HTTP?, o. J.)

Status quo mit HTTP/2

Die aktuell gängige Version HTTP/2, die am 14.Mai 2015 mit Google als treibende Kraft eingeführt wurde, brachte wesentliche Erneuerungen hinsichtlich der Minimierung von Bildinhalten und Skritpen sowie der Möglichkeit des Multiplexing von Requests und Respones. Primär sollten damit die Probleme hinsichtlich der Übertragsgungslatenz von HTTP/1.1 minimiert werden, um eine Beschleunigung der Netzwerkverbindung und des Internets im Allgemeinen zu erreichen (Belshe et al., 2015). Aktuell bieten knapp 97% aller modernen Webbrowser eine Unterstützung für Version 2, wie auf Abbildung 1 zu sehen ist.

Statistiken über die Verwendung des Standards von 2015 im Internet zeigen, dass etwa 46.5% aller Webseiten, wie Statistiken über die Verwendung des Standards im Internet zeigen, dass etwa 46.5% aller Webseiten, wie auf Abbildung 2 illustriert, die Version 2 integriert haben. Die aktuellen Datenlage zeigt also, dass HTTP/2 wesentliche technische Verbesserungen im Bereich der Ladezeiten bietet, aber dennoch noch nicht flächendeckend verwendet wird und inzwischen sogar eine dritte Iteration vor der Tür steht.

Was ist HTTP/3?

Zum Zeitpunkt des Verfassens dieses Artikels im Februar 2022, handelt es sich bei HTTP/3 um einen IETF-Internet-Draft oder ID, was heißt, dass es derzeit von der Internet Engineering Task Force – einem internationalen Gremium für Standards im Internet wie TCP oder IPv6 für eine Klassifizierung als kommender offizieller Internet-Standard geprüft wird (AUTH48 status page for C430 » RFC Editor, o. J.). Bei der neuen Iteration wurde das Rad aber keinesfalls neu erfunden, sondern von der IETF einfach die Zeichen der Zeit erkannt und ein neueres Webprotokoll entworfen, dass mehr Sicherheit bieten, eine Übertragung sowie effektivere Verbindungen gewährleisten soll.

Google entwickelt bereits seit dem Jahr 2012 an einer Alternative der bisher gängigen Datenübertragung bei HTTP bis zur Version 2. Das Übertragungsprotokoll QUIC, was soviel wie Quick UDP Internet Connections heißt, setzt im Vergleich zu den bisherigen Versionen auf das verbindungslose Transportprotokoll User Datagram Protocol (UDP) und soll in naher Zukunft die TCP-basierten Verbindungsprotokolle ablösen. UDP baut während des Datentransports keine expliziten Verbindungsleitungen auf und verlangt keine Bestätigung des Datenempfangs. Eventuell erforderliche Fehlerkorrekturen erfolgen auf QUIC-Ebene, was letztlich die Anzahl der Pakete reduziert und zu einer erheblichen Geschwindigkeitssteigerung führt. Die IETF einigte sich darauf, dass von Google präsentierte Technologie QUIC als Grundlage für die nächste HTTP-Version herangezogen werden soll (HTTP/3, o. J.-a, S. 3).

Vorteile und mögliche Probleme von HTTP/3

Bei HTTP/3 werden die einzelnen Datenströme getrennt behandelt. Geht ein Paket auf dem Weg verloren, sind also nicht mehr alle Datenströme betroffen, wie es bei einer TCP-Übertragung der Fall war. Stattdessen muss bei HTTP/3 nur der tatsächlich betroffene Datenstrom warten, bis das fehlende Paket nachgeliefert wird. Zusätzlich dazu wird auch noch die Paketumlautzeit reduziert. Dabei handelt es sich um die Zeit, die ein Datenpaket benötigt, um an seinem Ziel anzukommen, zusätzlich zu der Zeit, die für die Bestätigung des Empfangs der Daten erforderlich wäre.

Die Verbindungen in der zu QUIC-Technologie werden über die IP-Adresse sowie einen UDP-Port aufgebaut. Sobald die Verbindung erfolgreich aufgebaut worden ist, wird eine eindeutige Verbindungskennung vergeben, mit der es in weiterer Folge dann auch möglich ist, die Verbindung unabhängig von der jeweiligen IP-Adresse zuzuordnen. Somit ist es durchaus möglich, einen Download auf einem Gerät in einem WLAN-Netzwerk zu starten und später mit dem Mobilfunknetzt fortzuführen (HTTP/3, o. J.-b).

Ein großes Problem welches die Einführung von einem UDP-basierten Standard mit sich bringen könnte wäre, dass das mit TCP verbundene Verschlüsselungsprotokoll Transport Layer Security (TLS) auch verloren ginge. Da Sicherheitsüberprüfung und Verschlüsselung dann nicht mehr über TLS, sondern über UDP direkt erfolgt, befürchten viele Provider einen massiven Anstieg von schlecht zu prüfender Datenübertragung (HTTP/3, o. J.-a, S. 3).

Fazit und Ausblick

Die grundlegenden Ideen und Vorstellungen von HTTP/3 sind alle nachvollziehbar und bringen in der Theorie deutliche Verbesserungen zum bisherigen Hypertext Transfer Protocol. Vor allem die schnelleren Datenübertragunsraten könnten für eine, immer vernetztere Welt und Innovationen wie Internet of Things oder Cloud-Services einen deutlichen Mehrwert darstellen.

Ob und wie schnell der Entwurf auch offiziell als Standard klassifiziert bleibt in der Praxis abzuwarten. Inzwischen haben aber bereits alle modernen Browser wie Chrome, Mozilla und Safari eine Unterstützung für die neue Technologie vorgestellt (HTTP/3 protocol | Can I use… Support tables for HTML5, CSS3, etc, o. J.). Sobald dieser Standard dann verabschiedet wurde, muss das neue Protokoll dann auch von der breiten Masse akzeptiert und implementiert werden. Realistisch betrachtet, dürften aber noch einige Jahre vergehen.

Literaturverzeichnis

AUTH48 status page for C430 » RFC Editor. (o. J.). Abgerufen 21. Februar 2022, von https://www.rfc-editor.org/auth48/C430

Belshe, M., Peon, R., & Thomson, M. (2015). Hypertext Transfer Protocol Version 2 (HTTP/2) (Request for Comments RFC 7540). Internet Engineering Task Force. https://doi.org/10.17487/RFC7540

„http2“ | Can I use… Support tables for HTML5, CSS3, etc. (o. J.). Abgerufen 5. Februar 2022, von https://caniuse.com/?search=http2

HTTP/3: Das nächste Hypertext Transfer Protocol einfach erklärt. (o. J.-a). IONOS Digitalguide. Abgerufen 21. Februar 2022, von https://www.ionos.at/digitalguide/hosting/hosting-technik/http3-erklaert/

HTTP/3 protocol | Can I use… Support tables for HTML5, CSS3, etc. (o. J.). Abgerufen 21. Februar 2022, von https://caniuse.com/http3

HTTP/3: Wir erklären die nächste Version des Hypertext Transfer Protocols. (o. J.-b). t3n Magazin. Abgerufen 21. Februar 2022, von https://t3n.de/news/http3-erklaert-hyper-text-transport-protocol-1398125/

The HTTP Protocol As Implemented In W3. (o. J.). Abgerufen 5. Februar 2022, von https://www.w3.org/Protocols/HTTP/AsImplemented.html

Usage Statistics of HTTP/2 for Websites, February 2022. (o. J.). Abgerufen 5. Februar 2022, von https://w3techs.com/technologies/details/ce-http2

Was ist HTTP? (o. J.). IONOS Digitalguide. Abgerufen 5. Februar 2022, von https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-http/

Download als PDF

The post Die Zukunft der Webentwicklung: HTTP/3 appeared first on Mobile USTP MKL.

Damit man Informationen als Client von einer Website bzw. einem Server aktualisieren kann, gibt es typischerweise drei unterschiedliche Vorgehensweisen:

• Vollständiges erneutes Laden aller Informationen
• Nachladen von Inhalten mit AJAX
• Regelmäßige Abfrage in Intervallen

Diese Methoden haben alle ihre Anwendungsgebiete, werden aber spätestens dann unpraktisch, wenn Informationen möglichst schnell, am besten in Echtzeit, zur Verfügung stehen müssen. Hier schafft WebSockets Abhilfe, welches ein auf TCP basierendes Netzwerkprotokoll ist und parallel zur HTTP-Abfrage des Clients eine weitere Verbindung zum Server herstellt. Socket.io verwendet in erster Linie das WebSockets-Protokoll mit Polling über HTTP als Fallback-Option, falls das genannte Kommunikationsprotokoll nicht unterstützt wird. Die Bibliothek kann einfach als Wrapper für WebSockets verwendet werden, bietet aber darüber hinaus auch viele weitere Funktionen im Vergleich zu WebSockets, einschließlich Broadcasting an mehrere Sockets, speichern von Daten, die mit jedem Client verbunden sind, und asynchrones I/O.

Wofür kann man socket.io verwenden?

Die verschiedenen Anwendungsmöglichkeiten für socket.io lassen sich prinzipiell in vier Bereiche untergliedern:

1. Benachrichtigungen – Wenn serverseitig ein Ereignis auftritt und der Client benachrichtigt werden muss, eignet sich der eventbasiertes Aufbau von socket.io besonders gut.
2. Kommunikation – Nachrichten lassen sich mit einer geringen Serverlast und einer schneller Durchlaufzeit versenden, da nur dann Informationen geladen werden, wenn dies erforderlich ist. Besonders hier ist die Broadcast-Option von socket.io praktisch.
3. Spiele – Ebenfalls bietet sich die Bibliothek für Echtzeit-Online-Spiele an, um beispielsweise Positionen von Spielfiguren zu synchronisieren.
4. Steuerung – Die Steuerung von Microcontrollen bzw. Sensoren ist auch eine gute Anwendungsmöglichkeit dieser JavaScript-Bibliothek.

Installation über npm

Die offizielle Implementierung der serverseitigen Bibliothek setzt auf node.js als Framework auf. Von der Community gibt es aber auch Implementierungen in Python, C++ oder Java. Um das Package von socket.io für seine Node-Projekt verwenden zu können, muss man ein neues Projekt anlegen und in diesem Verzeichnis in der Konsole einfach npm install socket.io eingeben, um die Installation zu starten.

How To

Um einen einfachen Überblick zu bekommen, wie genau die Client-Server-Kommunikation mit socket.io funktioniert, lässt sich am besten mit einem einfachen Beispiel illustrieren.

Serverseitiger Code – server.js

// Kleiner HTTP-Server auf Port 8080
var app = require('http').createServer(serveStaticIndex).listen(8080);
 
// Laden von Socket.io
//(Gibt für die Demo nur Fehler/Warnungen auf der Konsole aus)
var io = require('socket.io').listen(app).set('log level', 1);
 
// Zugriff auf das Dateisystem (zum Ausliefern der index.html)
var fs = require('fs');
 
// Liefert die Startseite aus
function serveStaticIndex(req, res) {
  var fileStream = fs.createReadStream(__dirname + '/index.html');
      res.writeHead(200);
      fileStream.pipe(res);
}
 
// Socket.io-Events
io.sockets.on('connection', function (socket) {
  console.log('[socket.io] Ein neuer Client (Browser) hat sich verbunden.\n');
 
  console.log('[socket.io] SENDE "welcome"-Event an den Client.\n');
  socket.emit('welcome', "Hello world");
 
  socket.on('user agent', function (data) {
    console.log('[socket.io] EMPFANGE "user agent"-Event vom Client:');
    console.log(data, '\n');
  });
});

Code für den Client – index.html

<!DOCTYPE html>
<html>
<head>
  <title>Socket.io Test</title>
 
  <!-- Dieses Script wird von Socket.io automatisch zu Verfügung gestellt -->
  <script src="/socket.io/socket.io.js"></script>
 
  <script>
    // Mit dem Socket.io-Server verbinden
    var socket = io.connect('http://localhost');
 
    // Warten auf Nachrichten
    socket.on('welcome', function (data) {
      console.log('[socket.io] "welcome"-Event vom Server empfangen:\n' + data);
 
      // Eigenen Event vom Client an den Server schicken
      socket.emit('user agent', navigator.userAgent);
    });
  </script>
</head>
 
<body>
</body>
 
</html>

Viel mehr Code wird nicht benötigt, um die Funktionsweise von WebSockets bzw. der socket.io-Bibliothek zu demonstrieren. Zum Ausprobieren muss lediglich der Server mit node server.js gestartet werden, was anschließend den Server auf Port 8000 startet. Ruft man dann in seinem Browser die URL http://localhost:8080/ auf, kann man in der Entwickler-Konsole bzw. dem Terminal von Node beobachten, wie die übermittelten Nachrichten zwischen Client und Server ausgegeben werden.

In a nutshell

Die JavaScript-Bibliothek socket.io bietet eine unglaublich einfache Option, in seinen Projekten eine Echtzeitkommunikation umzusetzen. Vor allem das eventbasierte System und die breite Browserunterstützung machen dieses Werkzeug für viele Anwendungsbeispiele relevant. Wer mehr über die Bibliothek lernen will, wirft am besten einen Blick in die Dokumentation.

https://socket.io/docs/v4/

The post Echtzeitkommunikation mit socket.io appeared first on Mobile USTP MKL.