Frameworks & Technologien

Platform

• Desktop Browser (Fireforx + Chrome + Safari)
• Desktop Electron (Cordov mit WebKit)
• Desktop PWA (Firefox + Chrome)
• mobil (iOS + Android) PWA (Firefox + Chrome)
• mobil (iOS + Android) almost nativ (Cordova mit WebKit)

Full-Stack

Als Full-Stack bezeichnet man Frameworks, die einem ein fertigen Rahmen für die Client- und Serverentwicklung geben. Es ist nicht unbedingt notwendig ein FullStck Framework zu verwenden aber es kann mitunter die inertiale Entwicklung beschleunigen.

• Vulcan.js
• Meteor
• Fulcro
• GRANDStack - Neo4J, GraphQL, React, Apollo

UI

Generell bietet es sich an ein modernes UI-Framework zu verwenden. Man profitiert von vielen bereits vorhandnenen Komponenten und kann außerdem auf bewährte Design-patterns (nicht Design im Sinn von Ausssehen sondern im Sinne der Strukturierung von Code) zurückgreifen. Im Web und App-Entwicklungsuniversum haben sich das funktionale Komponentenbasierte React-Framework bewährt, alternativen dazu wären Angular.JS oder WebComponents. Es gibt auch die Möglichkeit Platform native Komponenten zu nutzen, das schließt dann aber die Entwicklung von gleichzeitig einer Web-Anwendung aus. Auch die Platform-Übergreifende Entwicklung ist dann nicht möglich.

• React
• React-Native
• Reframe

UI Komponenten Sammlung

Neben der UI-Technologie gibt es noch die eigentlichen fertigen Komponenten auf die man um eines einheitlichen und komfortablen Designs wegen zurückgreifen kann. Wir ersparen uns dadurch nicht nur arbeit, es ist dann auch gewährleistet, dass die Grundbausteine auf allen Plattformen gut ausssehen. Persönlich bin ich von Framework 7 begeistert.

• Framework 7
• semantic UI
• Material.io
• Bootstrap

Datenhaltung

Im backend unserer Anwendung mössen Daten gespeichert werden. Es gibt viele verschiedene Möglichkeiten, wie das geschehen kann. Es kommt auch drauf an, um was es geht. Beisspielsweise könnten Garten-spezifische Konfigurationen in einer YAMl oder JSON Datei auf dem Server gespeichert werden, der Rest in einer Mongo-Datenbank. Die Pflanzinformationen wiederum könnten in einer RDF-Datenbank gespeichert werden. Auch SQL (Postgres, MariaDB) wäre denkbar. Wichtig wäre bei einem Prototyp die einfache Anpassbarkeit und Erweiterbarkeit und dass das Datenbankformat bereits in einem günstigen Format um besispielsweise für das Frontend (zb. per Graph-QL) ausgeliefert werden kann. Sollten wir uns für Meteor entscheiden ist Mongo-DB betreits festgelegt.

• Mongo DB
• RDF / Graphdatenbank
• Filebasierend
• Neo4j + graphQL

Statemanagement

Das Statemanagement ist entscheidend für die Erweiterbarkeit und die langfristige Wartbarkeit einer Anwendung. Hier entstehen auch die meisten Fehler. Redux, verursacht zwar ein wenig mehr Aufwand, da man viel "Boilerplate" schreiben muss, erleichtert aber das Debugging und die Wartbarkeit ungemein, da man jede Zustandsänderung global zurückverfolgen kann.

• redux
• react
• react-hooks
• meteor
• Apollo

backend-Frontend Kommunikation

An verschiedenen Stellen des Programms kann es unterschiedliche Anforderungen geben. Wir müssen an dieser Stelle abwägen und uns gedanken machen an welchen Stellen wir eine sofortige Aktualisierung aller Clients wünschen (zum Beispiel bei der gemeinsamen Bearbeitung der Gartenkarte) und an welchen Stellen wir eher eine Offline Funktionalität wünschen. Es ist schwierig aber nicht unmöglich beides zu erreichen. Vielleicht nehmen wir deshalb auch unterschiedliche Ansätze.

• GraphQL
• Pub-Sub
• meteor/mini-mongo

Programmiersprache

Es bietet sich an die gleiche Sprache für Front und Backend zu verwenden. Muss aber nicht. Der Vorteil ist dass man Code in Backend und Frontend gleichermaßen verwenden kann, dass man eventuelle Specs und Type-definitionen nur einemal schreiben muss und, dass ein_e Entwickler_in, die sich in einer SPrache besonder wohl fühlt besser Front und Backend gleichermaßen entwickeln kann.

• Clojure / ClojureScript
• JavaScript
• TypeScript
• PHP

Build-Pipeline

• Backend
  • backpack
  • codegen (graphql -> typescript)
• Frontend
  • babel + ts
  • webpack
    • codegen (graphql -> typescript)
  • pre-commit hook -> husky -> eslint --fix
    • prettify
  • cordova-cli
    • android
    • electron
    • iOS

CI/CD

• Circle CI
• [HQ] ?

Workflows

• test
• puppeteer
• build-web
• build-cordova
  • android
  • android+test

spezial Bibliothek

Für verschiedene Teilaufgaben brauchen wir "Spezial"-Bibliotheken.

• openlayers / leaflet -> Gartenkarte

• OAuth

• Apollo Client+Server (graphQL)

  • neo4j-driver

Experimente

https://codimd.gra.one/tBUxcSawQO-T-xILFxdYIg#