Du möchtest zur mobilen App beitragen? Dieser Beitrag soll Dir einen ersten Überblick vermitteln und häufige Fragen beantworten. Dieser Beitrag wird ggf. erweitert/aktualisiert.
Ist die App fertig?
Nein, aktuell ist sie nicht fertig und kann nicht genutzt werden. Wenn Du möchtest, dass sie schneller einsatzbereit ist, kannst Du gerne mithelfen 
Werden Beta-Tester benötigt?
Nein, aktuell ist das nicht nötig.
Welche Sinn und Zweck hat die App?
Die App kann und soll Portfolio Performance nicht ersetzen.
Die App soll es ermöglichen, ein Portfolio ohne Installation von Portfolio Performance auswerten zu können. Also insbesondere auf mobilen Endgeräten (Smartphone, Tablet), auf denen eine Installation nicht möglich ist, aber auch auf Desktops, auf denen Portfolio Performance aus anderen Gründen (Unternehmensrichtlinien, einmalige Nutzung, …) nicht installiert ist.
Der Fokus liegt auf einem reinen Lesen/Betrachten des bestehenden Portfolios. Schreib-Funktionen (z.B. Buchungen ändern/hinzufügen) wird es nicht geben, sind aber perspektivisch denkbar.
Wie sieht die Architektur aus?
Die App besteht aus einem Backend und einem Frontend. Das Backend läuft auf einem Server und hält die Daten und führt die wesentlichen Berechnungen aus. Das Frontend läuft auf dem Endgerät und ist für die Darstellung der Daten verantwortlich.
Portfolio Performance kann sich mit dem Backend synchronisieren und so die Daten in der Portfolio-Datei und im Backend identisch halten.
Warum erfolgt die Trennung in Backend und Frontend?
Dieser Punkt ist durch verschiedene Argumente begründet, u.a.:
-
Die Speicherung von Daten “in der Cloud”, um die sich ein Nutzer nicht im Detail kümmern muss, ist heutzutage nicht unüblich und wird teilweise sogar erwartet.
-
Durch die zentrale Ablage der Daten im Backend muss der Nutzer sich nicht um die Synchronisation verschiedener Endgeräte kümmern.
-
Durch die Datenhaltung im Backend kann der Datenverkehr reduziert werden. Bei Änderungen muss nicht das komplette Portfolio zum Backend übertragen werden, sondern nur die geänderten Buchungen, neuen Kurse, etc. Umgekehrt muss das Frontend nicht das komplette Portfolio runterladen, sondern nur die Daten, die der Nutzer aktuell anzeigen möchte.
-
Das Backend erlaubt den Zugriff von verschiedenen Frontends. D.h. es ist perspektivisch möglich, weitere Frontends zu bauen, die dann alle auf die gleichen Daten und die gleiche Rechenlogik zugreifen, ohne dass diese mehrfach entwickelt werden muss.
-
Das Backend erlaubt perspektivisch weitere Funktionen, z.B.
- Benachrichtigung bei bestimmten Ereignissen,
- regelmäßige Berichtserstellung,
- Freigeben eines Portfolios (oder Teilen davon) an andere Nutzer,
- Datenabruf von weiteren APIs (z.B. von Comdirect oder P2P-Anbietern).
Wie sieht es mit der Privatsphäre aus?
Privatsphäre ist ein sehr wichtiger Punkt und wird von der App folgendermaßen berücksichtigt:
-
Backend und Frontend sind open-source. Jeder kann den Quellcode überprüfen.
-
Das Backend kann als Docker-Container selbst gehostet werden. D.h. die Daten bleiben vollständig in der Hand des Nutzers.
-
Die App setzt keinerlei Tracker o.ä. ein und es werden keine Verbindungen zu Dritten hergestellt.
-
Zur Nutzung sind keine persönlichen Daten erforderlich (Name, E-Mail-Adresse, Kontoverbindung, …). Es sind nur Benutzername und Passwort nötig. Der Benutzername kann (und sollte) so gewählt werden, dass dadurch kein Schluss auf eine Person möglich ist.
Bitte melde Dich gerne, wenn Du weitere Vorschläge hast, wie der Schutz der Privatsphäre weiter erhöht werden kann.
Welche Technologie wird verwendet (und warum)?
Das Backend wird in Go entwickelt. Als Datenbank wird PostgreSQL verwendet.
Das Frontend ist eine PWA (Progressive Web App), d.h. eine Anwendung, die im Browser aufgerufen werden kann. Es wird in TypeScript entwickelt wird.
Warum wurden die Technologien so gewählt?
Die aktuelle Auswahl ist u.a. aufgrund folgender Überlegungen so ausgefallen:
-
Das Frontend soll auf möglichst vielen Endgeräten zur Verfügung stehen. Mit der PWA werden alle Geräte abgedeckt, auf denen ein Browser läuft. Es ist perspektivisch sowohl denkbar, die PWA als native App zu “verpacken” (Capacitor/Cordova) als auch eine native App separat zu entwickeln, die auf das gleiche Backend aufsetzt.
-
Es soll eine Sprache zum Einsatz kommen, die populär und weit verbreitet ist
- um möglichst vielen Personen zu ermöglichen, zu dem Projekt beizutragen und
- eine große Auswahl an bestehenden Bibliotheken nutzen zu können.
-
An JavaScript kommt man im Frontend-Bereich quasi nicht vorbei. TypeScript ist eine sehr mächtige Obermenge von JavaScript.
Können auch andere Technologien zum Einsatz kommen?
Ja, ich bin grundsätzlich für Vorschläge offen. Allerdings ist es nicht möglich, jeden Wunsch und jede Vorliebe zu berücksichtigen. Jede Wahl hat Vor- und Nachteile und ich glaube nicht, dass es eine perfekte Auswahl gibt.
Die Architektur ermöglicht es ggf. auch, einzelne Komponenten in einer anderen Sprache zu bauen und via API zu integrieren.
Wie kann ich beitragen?
Es wäre sicherlich hilfreich, wenn Du Grundkenntnisse in Go oder TypeScript mitbringst – oder in einem ersten Schritt erwirbst.
Mit diesem Grundwissen kannst Du Dir den aktuellen Stand in Github ansehen. Bitte melde Dich einfach über das Kontaktformular, wenn Du etwas beitragen möchtest.
Was gibt es konkret zu tun?
Es gibt aktuell einige Baustellen. Es gibt hier keine Aufgabenliste, da diese sich aktuell sehr häufig ändern würde. Ggf. ergänze ich das zu einem späteren Zeitpunkt.
Wenn Du ein Grundverständnis des Quellcodes hast, wird Dir evtl. selbst auffallen, wo man etwas tun müsste bzw. wo Du etwas tun kannst. Bitte trete einfach mit mir in Kontakt.
