KI-Einschätzung erhalten 
In unserem letzten Artikel, Warum LIVOI API-first gebaut ist, ging es um eine einfache, aber grundlegende Idee: APIs dürfen kein nachträglicher Zusatz sein. Sie müssen das Fundament des Produkts bilden.
Aber “API-first” ist ein Buzzword, das schnell gesagt ist. Entscheidend ist, was diese Architektur in der Praxis tatsächlich ermöglicht. Genau hier wird es spannend. Und genau hier beginnen viele Standard-API-Designs zu scheitern.
Das Problem, auf das wir immer wieder gestoßen sind
Wenn Sie schon einmal mehr als einen einfachen Prototypen gebaut haben, kennen Sie das Muster. Am Anfang gibt es ein paar saubere Endpunkte: GET /users, GET /orders, vielleicht noch einen einfachen Statusfilter. Alles funktioniert.
Bis es das nicht mehr tut.
Denn sobald echte Nutzer mit dem Produkt arbeiten, kommen die Anforderungen:
- “Können wir noch einen Filter für Datumsbereiche ergänzen?”
- “Können wir in dieser Ansicht die letzten drei Bestellungen des Nutzers direkt mitliefern, damit wir einen Request sparen?”
- “Für das neue Admin-Dashboard brauchen wir einen komplett anderen Datenausschnitt.”
Plötzlich bauen Sie kein Produkt mehr. Sie bauen eine Endpunktfabrik. Jede neue Frontend-Anforderung bedeutet ein Backend-Ticket, eine angepasste Datenbankabfrage und ein neues Deployment.
Die API wird zum Flaschenhals.
Also haben wir aufgehört, Endpunkte zu bauen
Statt immer mehr spezialisierte Endpunkte zu ergänzen, haben wir eine andere Frage gestellt: Was wäre, wenn der Client einfach genau das anfordern könnte, was er braucht?
Nicht theoretisch und nicht als hochabstraktes Konstrukt. Sondern so, dass es in echter Produktion funktioniert und skaliert.
Aus dieser Frage ist eines der Kernfeatures von LIVOI entstanden: POST /dynamic/query.
Anstelle einer explodierenden Zahl an API-Varianten haben wir einen einzigen, einheitlichen Endpunkt gebaut. Mit Dynamic Queries definiert der Client selbst, welche Daten er braucht, wie sie gefiltert werden sollen und in welcher Struktur sie zurückkommen. Die API führt das einfach aus.
Keine Abstimmungsschleifen zwischen Frontend und Backend. Kein Warten auf den nächsten Sprint, nur um einen weiteren Filter zu bekommen.
Wie sich dadurch die Produktentwicklung verändert
Das ist keine kleine Komfortfunktion für Entwickler. Es verändert grundlegend, wie sich ein Produkt weiterentwickelt.
1. Sie werden schneller
Wenn sich Anforderungen im UI ändern, müssen Sie das Backend nicht anfassen. Sie passen die JSON-Abfrage auf Client-Seite an. Frontend-Teams bleiben beweglich und unabhängig.
2. Ihr UI hört auf, eingeschränkt zu sein
Komplexe Oberflächen wie Dashboards, Admin-Bereiche oder interne Tools sind nie wirklich fertig. Dynamic Queries erlauben es, diese Ansichten ohne Reibung weiterzuentwickeln und genau die Daten zu laden, die sie gerade brauchen.
3. Ihr Backend wird einfacher
Sie müssen nicht länger Dutzende maßgeschneiderte Endpunkte pflegen, Validierungslogik duplizieren oder Sonderfälle für jede neue Ansicht bauen. Stattdessen pflegen Sie ein System und ein sicheres Muster.
4. Flexibilität kostet keine Performance
Flexibilität bringt nichts, wenn dabei die Datenbank einbricht. Deshalb haben wir die Engine von Anfang an so gebaut, dass sie große Datenmengen, effiziente Pagination und reale Query-Muster performant verarbeiten kann.
”Ist das nicht einfach GraphQL?”
Die Frage ist berechtigt. Auf hoher Ebene verfolgen beide Ansätze ein ähnliches Ziel: dem Client mehr Kontrolle über den Datenzugriff zu geben. Trotzdem haben wir uns bewusst gegen GraphQL entschieden. Aus vier Gründen:
- Keine neue Sprache: GraphQL bringt eine eigene Query-Syntax, eigenes Tooling und ein zusätzliches mentales Modell mit. Diese Reibung wollten wir nicht. Für LIVOI reicht standardisiertes JSON.
- Keine parallelen Abstraktionsschichten: GraphQL verlangt Schemas, Resolver und eine zusätzliche Mittelschicht, die laufend gepflegt werden muss. Bei LIVOI ist das Datenmodell gleichzeitig die Query-Ebene.
- Für dynamische Filter gebaut: GraphQL ist stark, wenn die gewünschte Datenstruktur klar feststeht. Schwieriger wird es bei hochdynamischen, tief verschachtelten Filtern und wechselnden Bedingungen. Genau dafür ist unsere Dynamic-Query-Engine gemacht.
- Weniger bewegliche Teile: GraphQL-Setups verteilen Logik schnell über viele Dateien und Ebenen. Wir wollten das Gegenteil: ein System mit vorhersagbarem, transparentem Verhalten.
Wann das besonders sinnvoll ist
Dynamic Queries sind genau dann die richtige Wahl, wenn sich Ihr Produkt schnell weiterentwickelt, Ihre Anforderungen an den Datenzugriff nicht starr feststehen und Flexibilität kein Randfall, sondern Kernanforderung ist.
Wenn Sie eine Analytics-Plattform, ein stark angepasstes internes Tool oder einen KI-Agenten mit flexiblem Zugriff auf strukturierte Daten bauen, fühlt sich dieser Ansatz wie ein echter Hebel an. Wenn Sie dagegen eine komplett statische Website mit einer kleinen, unveränderlichen API bauen, reicht klassisches REST weiterhin aus. Auch das ist völlig in Ordnung.
Unterm Strich
Dynamic Queries sind eine direkte Folge davon, wie wir bei LIVOI über Produktarchitektur nachdenken. Eine API sollte kein starres, fragiles Vertragskonstrukt sein, das Sie ausbremst. Sie sollte eine Engine sein, die mit dem Produkt mitwächst.
Der Ansatz verschiebt die Kontrolle weg von starren Backend-Definitionen und direkt zu den Entwicklern, die das Nutzungserlebnis bauen. Und wenn man einmal so arbeitet, ist es erstaunlich schwer, wieder zurückzugehen.
Den technischen Deep Dive finden Sie in der LIVOI Dynamic Query Dokumentation.