didi/xiaoju-survey: Ein Questionnaire-Baukasten mit eigenem Meta-Protokoll
XIAOJUSURVEY is an enterprises form builder and analytics platform that allows users to create questionnaires, exams, polls, quizzes, and analyze data online.
Auf einen Blick
- Was ist das?
- XIAOJUSURVEY ist ein quelloffenes System zum Bauen, Ausliefern und Auswerten von Umfragen, Tests und Formularen. Der interessanteste Teil ist nicht die Oberfläche, sondern die Standardisierung des Fragebogens als Datenstruktur.
- Für wen ist es gedacht?
- Wer eine eigene Umfrage- oder Testplattform mit Anbindung an bestehende Systeme braucht und bereit ist, NestJS und MongoDB zu betreiben, findet hier eine vollständige Produktoberfläche statt eines reinen UI-Kits. Wer nur ein einzelnes Formular in eine bestehende App einbetten will, sollte zu einem rendererorientierten Paket greifen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 58 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem der Baukasten abdeckt und für wen er gedacht ist
Ein Umfragewerkzeug selbst zu bauen klingt nach einem Wochenendprojekt, bis die erste Fachabteilung bedingte Fragen verlangt, die zweite ein Quiz mit Auswertung, die dritte einen Export nach Excel und die vierte eine Freigabe vor der Veröffentlichung. Genau an dieser Stelle setzt xiaoju-survey an. Das Repository beschreibt das Projekt als leichtgewichtiges, sicheres Befragungssystem, das laut README als Produktlösung für Personen und Unternehmen gedacht ist und die gesamte Lebensdauer einer Umfrage abdeckt: anlegen, bearbeiten, ausliefern, einsammeln, auswerten.
Der Umfang ist im README konkret benannt: 40+ Fragetypen und 100+ kuratierte Vorlagen, entstanden aus dem internen Einsatz bei Didi. Die Zielgruppe ist damit klar umrissen. Es sind Teams, die eine eigene Instanz betreiben wollen, weil Daten das Haus nicht verlassen dürfen, oder weil die Umfrage in eine bestehende Anmeldung und Rechteverwaltung eingebettet werden soll. Wer dagegen einmalig einen Fragebogen für eine Marktstudie braucht, wird mit dem Betriebsaufwand nicht glücklich.
Bemerkenswert ist die Themenliste des Repositories: ai, llm, react-native, vue3, java, nodejs. Die Bandbreite deutet auf ein gewachsenes System mit mehreren Oberflächen hin, nicht auf ein einzelnes Frontend-Paket.
Das Meta-Protokoll ist der eigentliche Kern
Die Dokumentation stellt an erster Stelle der Projektvorteile ein standardisiertes Fragebogen-Protokoll vor, das in zwei Kategorien zerfällt: eine fachliche Beschreibung (Fragebogen- und Fragetyp-Protokoll) und eine Materialbeschreibung (Fragetyp-Material-Protokoll, das Fragetyp und Konfigurator umfasst). Das ist die interessanteste Designentscheidung im ganzen Projekt.
Sie bedeutet praktisch: Ein Fragebogen ist keine HTML-Struktur, sondern ein serialisierbares Objekt nach einer festen Vereinbarung. Der Editor erzeugt dieses Objekt, der Renderer liest es, die Statistik arbeitet darauf. Weil beide Seiten dieselbe Vereinbarung kennen, hält das Projekt nach eigener Aussage die Darstellung zwischen Editor und veröffentlichter Ansicht konsistent. Genau hier scheitern viele Eigenbauten: Der Editor zeigt etwas anderes als die Auslieferung, und niemand merkt es bis zur ersten Beschwerde.
Der zweite Teil des Konzepts ist die Materialisierung der Fragetypen. Jeder Fragetyp bringt allgemeine Grundfähigkeiten mit und dazu atomare Einzelfähigkeiten, die sich konfigurieren lassen. Ein neuer Fragetyp ist damit kein Eingriff in den Kern, sondern ein Material, das sich in das Protokoll einfügt. Ob das in der Praxis so sauber trägt, lässt sich aus dem Repository allein nicht beurteilen; die Dokumentation beschreibt das Prinzip, nicht seine Grenzfälle.
Architektur: Vue3 im Browser, NestJS und MongoDB im Hintergrund
Der Technikabschnitt des README ist knapp, aber ausreichend für eine Einordnung. Die Weboberfläche läuft auf Vue3 mit ElementPlus. Der Server ist NestJS mit MongoDB. Für die Auslieferung auf mobilen Endgeräten gibt es ein SDK auf Basis von React Native. Das ist eine ungewöhnliche Kombination: zwei verschiedene Frontend-Stacks im selben Projekt.
Daraus folgt ein Datenfluss, den man beim Lesen der Dokumentation im Kopf behalten sollte. Der Editor im Verwaltungsbereich erzeugt das Fragebogen-Objekt nach dem Meta-Protokoll und legt es in MongoDB ab. Die Auslieferungsansicht unter einem Pfad der Form /render/:surveyPath lädt dieses Objekt und rendert es. Antworten werden zurückgeschrieben und dort ausgewertet, wo das README die Analysefähigkeiten nennt: Statistik pro Frage, Kreuzanalyse, Analyse über mehrere Kanäle.
Die Speicherwahl MongoDB passt zum dokumentorientierten Fragebogen-Objekt, weil sich unterschiedliche Fragetypen ohne Schema-Migration abbilden lassen. Der Preis ist bekannt: Wer eine relationale Datenhaltung mit Fremdschlüsselintegrität für Auswertungen bevorzugt, muss die Antwortdaten selbst überführen. Das README nennt dazu keinen Mechanismus, nur die Exportfähigkeit.
Lokal starten und deployen: die konkreten Befehle
Das README gibt für die lokale Entwicklung zwei Blöcke vor. Der Server wird im Verzeichnis server gestartet, mit npm install und anschließend npm run local. Die Oberfläche liegt im Verzeichnis web, ebenfalls npm install, dann npm run serve. Als Node-Version nennt das Repository ein Badge mit >=18.
Nach dem Start sind zwei Einstiegspunkte erreichbar. Die Verwaltungsseite für Autorinnen und Autoren liegt unter http://localhost:8080/management, die Auslieferungsansicht unter http://localhost:8080/render/:surveyPath. Der Pfadparameter ist offenbar die Kennung des veröffentlichten Fragebogens.
Für den Produktivbetrieb verweist das README auf eine Docker-Anleitung und beschreibt zwei Images. xiaojusurvey/xiaoju-survey:latest-slim basiert auf node:18-slim und ist für Produktionsumgebungen gedacht. xiaojusurvey/xiaoju-survey:latest-full basiert auf node:18 und enthält zusätzlich Werkzeuge wie curl, vim und git, was für Entwicklung und Fehlersuche gedacht ist. Umgeschaltet wird über das Image-Tag in docker-compose.yaml. Wer das übersieht, zieht sich eine deutlich größere Angriffsfläche in die Produktion als nötig.
Für die Anbindung an fremde Systeme nennt das README konfigurierbare Hooks, konkret für Datenweitergabe und Benachrichtigungen. Details zu den Schlüsselnamen stehen dort nicht, sie liegen in der verlinkten Dokumentation.
Wo das System an Grenzen stößt
Die auffälligste Schwäche liegt in der Nachvollziehbarkeit des Projekts. Das Repository liefert zum Zeitpunkt der Prüfung keine abgerufenen Releases. Es gibt kein Changelog im Repository selbst, sondern einen Verweis auf ein Issue mit der Bezeichnung MAJOR CHANGELOG. Wer Versionsstände für ein Upgrade planen muss, findet im Repository keine Versionshistorie, sondern muss der verlinkten Dokumentation folgen. Das erschwert eine Risikoabschätzung vor dem Produktiveinsatz erheblich.
Der zweite Punkt betrifft die Dokumentationssprache. Das README liegt auf Chinesisch vor, mit einem Verweis auf eine englische Fassung. Die verlinkte Produktdokumentation ist im README durchgehend mit chinesischen Pfadsegmenten angegeben, etwa für Produkthandbuch, Designprinzipien und Engineering-Deployment. Für Teams ohne chinesischsprachige Mitwirkende ist das ein realer Einarbeitungsaufwand, der in keiner Feature-Liste auftaucht.
Drittens die Betriebsabhängigkeit. NestJS und MongoDB sind keine Nebenbedingung, sondern die Grundlage. Wer MongoDB nicht betreiben will, kann das Projekt nicht sinnvoll nutzen. Und wer nur eine Umfrage in eine bestehende React-Anwendung einbetten möchte, trägt hier einen kompletten Server, eine Datenbank und einen zweiten Frontend-Stack mit. Die React-Native-Komponente allein löst dieses Problem nicht, weil sie ohne das Backend keine Auswertung liefert.
Was eine Alternative anders macht
Der naheliegende Vergleich ist ein rendererorientiertes Formularpaket wie SurveyJS. Der Unterschied liegt nicht im Funktionsumfang, sondern im Zuschnitt. SurveyJS liefert im Kern einen Fragebogen-Renderer und einen Editor als Bibliothek, die man in eine bestehende Anwendung einhängt; die Speicherung der Antworten und die Auswertung bleiben Aufgabe der einbettenden Anwendung. xiaoju-survey geht den umgekehrten Weg und liefert die Anwendung mit: Benutzerverwaltung mit Anmeldung und Registrierung, Rechteverwaltung pro Fragebogen, Verwaltungsoberfläche, Auslieferungsansicht, Analyse. Man adoptiert ein System, keine Bibliothek.
Für die Entscheidung heißt das: Wer bereits eine Anwendung mit Authentifizierung und Datenhaltung hat und nur die Befragungsstrecke ergänzen will, zahlt bei xiaoju-survey für Funktionalität, die er schon besitzt. Wer umgekehrt keine Lust hat, Rechteverwaltung und Auswertungsoberfläche selbst zu bauen, bekommt hier genau das, muss aber die Meinung des Projekts zu Datenmodell und Betrieb übernehmen.
Ein zweiter Unterschied betrifft die Erweiterbarkeit. Beide Ansätze erlauben eigene Fragetypen, aber xiaoju-survey bindet sie an ein veröffentlichtes Meta- und Material-Protokoll. Das ist strenger und macht Fragetypen über Systemgrenzen hinweg austauschbar. Ob dieser Vorteil zum Tragen kommt, hängt davon ab, ob die eigene Organisation mehrere Werkzeuge auf dasselbe Fragebogenformat bringen will.
Wartung, Lizenz und was vor dem Einsatz zu klären ist
Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im Juli 2026, und das README verweist auf einen Beitragenden-Leitfaden sowie auf eine Liste künftiger Aufgaben in einem Issue. Ein öffentlicher Fahrplan für Versionen ist daraus nicht ableitbar. Für die Wartungsplanung bedeutet das: Man sollte mit einem festen Commit arbeiten und Upgrades bewusst ziehen, statt einem Versionskanal zu folgen, dessen Inhalt das Repository nicht dokumentiert.
Lizenzseitig steht das Projekt unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Änderungen und verlangt, dass Lizenz- und Urheberrechtshinweise erhalten bleiben; für geänderte Dateien sind die Änderungen kenntlich zu machen. Ein Punkt, der bei einer Marke wie dieser praktisch relevant wird: Apache-2.0 gewährt ausdrücklich keine Rechte an Namen und Marken des Lizenzgebers. Wer die Oberfläche unter eigenem Branding ausliefert, sollte das prüfen, bevor Logos oder Produktnamen übernommen werden. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stelle, an der eine Prüfung sinnvoll ist.
Der Aufwand für ein Upgrade hängt an zwei Stellen. Erstens am Meta-Protokoll: Ändert sich die Vereinbarung, müssen gespeicherte Fragebögen weiterhin lesbar bleiben, und dazu nennt das README keine Migrationsstrategie. Zweitens an der Hook-Konfiguration: Eigene Integrationen für Datenweitergabe und Benachrichtigungen hängen an internen Schnittstellen, die nicht Teil des veröffentlichten Protokolls sind. Wer hier investiert, sollte den Anschluss klein halten.
Redaktionelles Fazit
Wer eine eigene Umfrage- oder Testplattform mit Anbindung an bestehende Systeme braucht und bereit ist, NestJS und MongoDB zu betreiben, findet hier eine vollständige Produktoberfläche statt eines reinen UI-Kits. Wer nur ein einzelnes Formular in eine bestehende App einbetten will, sollte zu einem rendererorientierten Paket greifen. Vor dem Adoptieren zuerst das Fragebogen-Meta-Protokoll lesen und prüfen, ob die eigenen Fragetypen sich darin abbilden lassen, danach das docker-compose.yaml auf die slim-Variante umstellen und die Hook-Konfiguration gegen die eigene Datenhaltung testen.
Community-Notizen