Help-Center · 8 Antworten
Backend, API und Integrationen
Technische Hilfe zur PLANT-ID API, Mandantenfähigkeit, Rechten, Ereignissen, Offline-Synchronisation und Integrationen.
01Wie ist das Backend aufgebaut?
Der Start ist als modularer Monolith mit PostgreSQL geplant. Fachmodule für Identität, Pflanzen, Tags, Scan, Pflege, Standorte, Medien, Benachrichtigungen und Audit bleiben im Code klar getrennt.
02Welche API-Konventionen gelten?
JSON über HTTPS, Versionierung unter /v1, OAuth 2.1/OIDC für Menschen, enge Geräte-Credentials, Cursor-Paginierung, Idempotency Keys, Versionsprüfung und standardisierte Problem-Details.
03Wie wird ein öffentlicher Tag aufgelöst?
Der öffentliche Schlüssel wird gehasht zur aktuellen Tag-Zuordnung aufgelöst. Das Backend erzeugt daraus ein minimiertes öffentliches View Model ohne interne Spalten und vertrauliche Daten.
04Wie funktioniert Mandantenfähigkeit?
Organisation, Rollen und optional Standortbereiche begrenzen jeden Zugriff. Der Mandant stammt aus dem verifizierten Token und wird niemals allein aus einem frei gesetzten Request-Header vertraut.
05Wie werden doppelte Offline-Aktionen verhindert?
Jede Mutation erhält eine clientseitige UUID als client_event_id. Das Backend verarbeitet dieselbe ID pro Mandant nur einmal und meldet accepted, duplicate, conflict oder rejected zurück.
06Welche Integrationen sind vorgesehen?
REST-API, Webhooks, CSV, ERP, PIM, GS1/EPC, Wetterdienste, Push, optionale Bilderkennung, Smart Home und Reader-Gateways sind im Zielbild berücksichtigt.
07Wo läuft das produktive Backend?
Backend-Anwendungen werden getrennt vom öffentlichen STRATO-Frontend über die Serverdomain apps.suites89.de betrieben. Der konkrete PLANT-ID-Dienst wird im Projektverlauf als eigener isolierter Service eingerichtet.
08Wie werden Backend-Versionen veröffentlicht?
Vorgesehen ist ein eigener VCS-Flow: Push auf den produktiven Git-Eingang, Installation und Tests im Releaseordner, atomarer Wechsel des aktiven Releases und Neustart des isolierten systemd-Dienstes.