--- title: "Technologie: Drupal 11, Nuxt 4 und Open311" description: "Der Technik-Stack hinter Mark-a-Spot: Drupal 11 als Open-Source-Backend unter GPL-2.0, Nuxt 4 im Frontend, Open311 GeoReport v2 als offene Schnittstelle. Betrieb in Deutschland oder im eigenen Rechenzentrum." lang: es source: rendered --- # Die Technik dahinter Drupal 11 im Backend, Nuxt 4 im Frontend, Open311 GeoReport v2 als Schnittstelle. Betrieb in Containern, in unserer Cloud in Deutschland oder in Ihrem Rechenzentrum. Diese Seite richtet sich an Ihre IT. Sie beschreibt, woraus Mark-a-Spot besteht, welche Schnittstellen es gibt und wie der Betrieb aussieht. [Dokumentation ansehen](/docs)[Quelltext auf GitHub](https://github.com/markaspot/markaspot) ## Der Stack im Überblick Was Mark-a-Spot ausmacht, und unter welcher Lizenz es jeweils steht. Komponente Technologie Lizenz Backend Drupal 11, PHP 8.4 GPL-2.0 Frontend Nuxt 4, Vue 3, TypeScript MIT oder BSL, je nach Variante Schnittstelle Open311 GeoReport v2, JSON:API Offener Standard Datenbank MariaDB 11 GPL-2.0 Karte MapLibre GL, eigener Vektor-Tile-Server BSD-3-Clause Betrieb Docker, Kubernetes Apache-2.0 Die Lizenzspalte nennt bei Backend und Frontend die Lizenz unseres eigenen Codes, in den übrigen Zeilen die der eingesetzten Fremdkomponenten. Das Backend ist vollständig quelloffen. Beim Frontend gibt es zwei Varianten: eine frei verwendbare Bürgeransicht unter MIT-Lizenz und das Pro-Frontend mit Dashboard und Progressive Web App, das lizenzpflichtig ist. ## Warum headless Klassische Fachverfahren liefern Oberfläche und Datenhaltung als ein Stück. Bei Mark-a-Spot sind das zwei Teile, die über eine Schnittstelle miteinander reden. Diese Trennung bestimmt, was Sie später ohne Verfahrenswechsel ändern können. ### Daten und Oberfläche sind getrennt Das Backend hält die Meldungen und stellt sie über eine dokumentierte Schnittstelle bereit. Die Bürgeransicht ist eine eigene Anwendung, die diese Schnittstelle nutzt. Sie können die Oberfläche also ersetzen, ohne die Datenhaltung anzufassen. ### Einbettung ins vorhandene Portal Sie können die Bürgeransicht unter einer eigenen Domain betreiben, in Ihr Bürgerportal einbetten oder durch eine eigene Oberfläche ersetzen. Das Verfahren dahinter bleibt dasselbe. ### Eine Anwendung für alle Geräte Das Frontend ist eine Progressive Web App. Bürger melden vom Telefon, die Sachbearbeitung arbeitet im Browser, der Außendienst nutzt dieselbe Anwendung mobil. Es gibt keine getrennte App, die separat gepflegt werden muss. ### Serverseitiges Rendering Die Seiten werden auf dem Server erzeugt und ausgeliefert. Das hilft bei langsamen Verbindungen und macht Meldungen für Suchmaschinen lesbar. Offener Standard ## Open311 GeoReport v2 Open311 ist eine öffentlich spezifizierte Schnittstelle für Bürgeranliegen, die Städte in Europa und Nordamerika einsetzen. Ein Client, der den Standard spricht, kann Mark-a-Spot ansprechen. Kategoriezuschnitt, Statusabbildung und Zugangsdaten sind trotzdem pro Kommune abzustimmen, das nimmt kein Standard ab. `GET /georeport/v2/services` Kategorien und ihre Pflichtfelder abrufen `GET /georeport/v2/requests` Meldungen abrufen, gefiltert nach Zeitraum, Status oder Kategorie `POST /georeport/v2/requests` Meldung anlegen, etwa aus einem Fremdsystem oder einer eigenen App `GET /georeport/v2/requests/{id}` Einzelne Meldung mit Verlauf abrufen Antwortformat ist JSON oder XML. Der vollständige Bearbeitungsverlauf gehört nicht zum Open311-Standard. Dafür steht JSON:API bereit, im Rahmen der Berechtigungen des zugreifenden Kontos, dazu ein CSV-Export mit Koordinaten für Auswertungen. Einen nativen GeoJSON-Export von Meldungen gibt es nicht. GeoJSON nutzt Mark-a-Spot als Eingang für Gebietsgrenzen, etwa zur Prüfung, ob eine Meldung im eigenen Zuständigkeitsgebiet liegt. Braucht Ihr GIS einen GeoJSON-Ausgang, ist das eine Anpassung, die wir im Projekt einplanen. Verarbeitungskette ## Erst anonymisieren, dann analysieren Die Erkennung personenbezogener Daten läuft vor der KI-Analyse, nicht danach. Was an einen KI-Dienst geht, ist bereits reduziert. Eine automatisierte Erkennung ist dabei keine Garantie auf Vollständigkeit, deshalb bleibt die redaktionelle Prüfung vor der Veröffentlichung Teil des Verfahrens. ### Schritt 1: Bild anonymisieren Ein eigener Dienst auf unseren Servern in Deutschland erkennt Gesichter und Kennzeichen und macht sie unkenntlich. Das unkenntlich gemachte Bild ersetzt das Original, der Vorgang wird protokolliert. Dieser Schritt verlässt Deutschland nicht. Erkennt der Dienst Personen, die trotz Verpixelung identifizierbar blieben, wird das Bild nicht veröffentlicht. ### Schritt 2: Text prüfen Aus dem Meldungstext werden Kontaktdaten entfernt: E-Mail-Adressen, Telefonnummern und IBAN. Eine Erkennung von Personennamen lässt sich zusätzlich aktivieren. Freitextangaben wie eine geschilderte Anschrift erfasst die Mustererkennung nicht, das gehört zur fachlichen Prüfung. ### Schritt 3: Analysieren Erst jetzt geht die reduzierte Meldung in die Analyse. Sie schlägt Kategorie und Priorität vor und prüft auf Gefahrenhinweise. Standardmäßig läuft das über Microsoft Azure OpenAI in der Region Germany West Central, ohne Training auf Ihren Daten. Auf Wunsch nutzen wir stattdessen einen deutschen Anbieter. Alle KI-Funktionen sind einzeln abschaltbar. ### Schritt 4: Ausgeben Das Ergebnis landet als Vorschlag im Dashboard, den die Sachbearbeitung bestätigt oder korrigiert. Erkannte Gefahrenhinweise kann Mark-a-Spot im CAP-Format ausgeben, dem internationalen Austauschformat für Warnmeldungen, sodass ein Warnsystem sie weiterverarbeiten kann. ki-analyse im dashboard ![KI-Analyse einer Meldung im Sachbearbeiter-Dashboard](/_vercel/image?url=%2Fassets%2Fimages%2Fscreenshots%2Fdashboard-ai-en.webp&w=1536&q=100) ## Zugriff, Rechte, Updates Wer sich anmeldet, wer was sieht und wie Aktualisierungen eingespielt werden. ### Anmeldung der Beschäftigten Anbindung an einen vorhandenen SAML-Identity-Provider, sodass die Sachbearbeitung keine zusätzlichen Zugangsdaten braucht. Alternativ eine passwortlose Anmeldung per Einmalcode an die dienstliche Adresse. ### Rechte und Zuständigkeiten Rollenbasierte Rechtevergabe, dazu eine Trennung nach Organisationseinheiten. Ein Bauhof sieht die Meldungen seines Bereichs, nicht die des ganzen Hauses. ### Mandantentrennung Mehrere Kommunen in einer Installation, jede mit eigenen Kategorien und eigenem Branding. Die Trennung ist logisch umgesetzt, über Mandantenzuordnung und Berechtigungen. Wer eine getrennte Instanz mit eigener Datenbank braucht, bekommt sie, das ist dann aber ein anderes Betriebsmodell. ### Updates Drupal hat ein eigenes Sicherheitsteam mit festem Veröffentlichungsrhythmus. In der Cloud-Variante spielen wir Sicherheits- und Funktionsupdates ein, beim Self-Hosting liefern wir die aktualisierten Container-Images. ## Drei Betriebsmodelle Die Software ist in allen dreien dieselbe. Was sich unterscheidet, ist die Aufteilung der Betriebsverantwortung, und die gehört in den Vertrag, nicht auf eine Website. ### Betrieb durch uns Server in Deutschland, Hetzner Nürnberg. Aktualisierungen, Sicherung und Überwachung liegen bei uns. Was das konkret an Reaktionszeiten und Wiederanlaufzeiten bedeutet, steht im Vertrag und nicht auf dieser Seite. ### Betrieb im eigenen Rechenzentrum Wir liefern die Container-Images, Sie betreiben sie auf Ihrer Infrastruktur. Für Docker Compose gibt es eine fertige Zusammenstellung des kompletten Stacks. Die Betriebsverantwortung liegt dann bei Ihnen, wir liefern Software und Unterstützung. ### Betrieb durch Ihren IT-Dienstleister Mark-a-Spot läuft bei kommunalen IT-Dienstleistern in Kubernetes. Die Übergabe stimmen wir direkt mit dem Betriebsteam ab, die Aufteilung der Zuständigkeiten wird dabei schriftlich festgehalten. ### Wechsel zwischen den Modellen Ein Wechsel ist eine Migration derselben Software, kein neues Verfahren. Was sich ändert, ist nicht die Anwendung, sondern wer für Betrieb, Sicherung und Störungsannahme einsteht. ## Warum diese Entscheidungen Kriterium Was dahintersteckt Berechenbarer Veröffentlichungsrhythmus Drupal veröffentlicht Sicherheitsupdates nach festem Zeitplan und pflegt jede Hauptversion über einen angekündigten Zeitraum. Ihre IT kann Update-Fenster deshalb vorausplanen, statt auf Anbietermeldungen zu warten. Quelloffenes Backend Das Backend steht unter GPL-2.0 auf GitHub und drupal.org. Sie können es prüfen, selbst betreiben und weiterbetreiben, auch ohne uns. Das Pro-Frontend mit Dashboard ist davon ausgenommen, es ist lizenzpflichtig. Standard statt Hausformat Open311 GeoReport v2 ist eine öffentlich spezifizierte Schnittstelle. Was sie liefert, lässt sich vor der Beschaffung nachlesen und mit anderen Angeboten vergleichen. Bestehende Infrastruktur Docker und Kubernetes sind in kommunalen Rechenzentren im Einsatz. Für Mark-a-Spot muss Ihr Betrieb keine Sonderumgebung aufbauen, die er sonst nirgends braucht. Verfügbare Fachkräfte PHP und JavaScript sind verbreitete Sprachen. Das ersetzt keine Einarbeitung in Mark-a-Spot, senkt aber die Hürde, wenn Ihr Rechenzentrum oder ein Dienstleister eigene Anpassungen machen will. ## Selbst nachsehen Das Backend ist öffentlich einsehbar. Ihre IT kann den Quelltext lesen, bevor Sie eine Beschaffungsentscheidung treffen. [GitHub](https://github.com/markaspot/markaspot)[drupal.org](https://www.drupal.org/project/markaspot)[Dokumentation](/docs) ## Häufige Fragen der IT Warum Drupal und nicht eine eigene Plattform? Können wir das Backend selbst betreiben? Welche Daten bekommen wir über die Schnittstelle heraus? Wie läuft die KI-Verarbeitung technisch ab? Was hat es mit CAP auf sich? Lässt sich Mark-a-Spot an unsere Fachverfahren anbinden? Wo finden wir den Quelltext und die Dokumentation? ## Fragen, die hier nicht stehen? Für Markterkundungen und Vergabeverfahren brauchen Sie mehr als eine Website: Angaben zu Reaktionszeiten, Sicherung und Wiederanlauf, Auftragsverarbeitung, technischen und organisatorischen Maßnahmen, Unterauftragnehmern und Barrierefreiheit. Sagen Sie uns, welche Nachweise Ihr Verfahren verlangt, dann bekommen Sie sie schriftlich. [Technisches Gespräch vereinbaren](/demo)