Framework-unabhängige Produktsuche: warum ein SDK mehr bringt als fertige Such-Komponenten

Ein Entwicklerteam baut einen Composable-Shop. Für die Produktsuche wählt es einen Anbieter mit einer fertigen React-Komponente. Ein Nachmittag Arbeit, dann steht das Suchfeld und die Ergebnisliste rendert sauber.

Achtzehn Monate später zieht das Storefront auf ein anderes Framework um. Eine native App für den Außendienst kommt dazu, und das interne Katalogteam möchte dieselbe Suche nutzen. Die React-Komponente wandert in keinen dieser Fälle mit. Sie ist an ein Framework gebunden, und die Such-Oberfläche entsteht ein zweites und ein drittes Mal.

Diese Reihenfolge kennt fast jedes Headless-Projekt.

Genau hier trennt sich eine kurzfristige Abkürzung von einer langfristigen Grundlage. Die fertige Komponente spart Zeit in den ersten Wochen. Ein framework-unabhängiges Such-SDK entfaltet seinen Wert über die folgenden Jahre, weil die Suche einen Frontend-Wechsel übersteht. Der Unterschied liegt darin, was Sie an Ihr Frontend binden und was Sie davon lösen.

Warum fertige Such-Komponenten wie eine Abkürzung aussehen

Fertige Suchkomponenten sind ein verlockendes Angebot. Der Anbieter liefert ein Paket für React, eines für Angular, eines für Vue. Sie installieren es, hinterlegen einen API-Schlüssel und haben Suchfeld, Vorschlagsliste und Ergebnisraster in Stunden.

Dieser Reiz war lange berechtigt. Eine Such-Oberfläche von Grund auf zu bauen bedeutete früher echten Aufwand. Autovervollständigung, das Rendern von Facetten, Paginierung, Tastaturnavigation, Barrierefreiheit. Das waren Wochen an Frontend-Arbeit, die niemand doppelt leisten wollte. Eine fertige Komponente nahm diese Last ab, und das war ihr eigentlicher Wert.

Unter der Oberfläche ruft eine solche Komponente eine Such-API (Search API) auf. Sie schickt die Anfrage des Nutzers an einen Server, bekommt Treffer, Facetten und Vorschläge zurück und zeichnet sie im jeweiligen Framework. Die eigentliche Suche passiert nicht im Browser. Sie passiert hinter der API.

Was eine Komponente wirklich an Ihr Frontend bindet

Eine React-Komponente ist eine Vorlage für genau ein Rendermodell. Sie bringt den Zustandsbaum, den Lebenszyklus und die Markup-Konventionen von React mit. In Angular oder Vue lässt sie sich nicht einsetzen, weil diese Frameworks anders rendern und ihren Zustand anders verwalten.

Das ist der Punkt, den die Abkürzung verdeckt. An das Framework gebunden wird die Oberfläche um die Suche, also die Schicht, die Treffer anzeigt. Die Suche selbst liegt eine Ebene tiefer und ist davon nicht betroffen.

Relevanzberechnung, Fehlertoleranz und Facettenlogik liegen serverseitig. Die Komponente reicht Anfragen durch und stellt die Antworten dar. Eine framework-gebundene Komponente koppelt auf diese Weise eine serverseitige Fähigkeit an eine Frontend-Entscheidung, die sich über die Jahre verschiebt.

Der Wechsel, den kaum jemand einplant

Frontend-Frameworks haben eine begrenzte Halbwertszeit. React, Angular und Vue sind quelloffen und werden aktiv weiterentwickelt, doch Projekte wechseln, ergänzen ein zweites Frontend oder eine native App. In einem Composable-Aufbau ist das der Normalfall.

Rechnen Sie den Fall einmal durch. Ein Team, das von React auf ein anderes Framework migriert, plant Zeit für Seiten, Routing und Zustandsverwaltung ein. Die Suche taucht in dieser Planung oft gar nicht auf, weil sie als erledigt gilt. Beim Umbau zeigt sich dann, dass die Suchkomponente am alten Framework hing, und aus einer vermeintlich fertigen Aufgabe wird ein eigener Arbeitsblock, den niemand budgetiert hatte. Die Rechnung kommt spät. Genau dieser stille Posten macht die Abkürzung im Nachhinein teuer.

Trifft dieser Wechsel eine framework-gebundene Komponente, wird sie weggeworfen und neu gebaut. Trifft er eine API-first-Suche, bleibt die API stehen. Neu geschrieben wird nur die dünne Renderschicht darüber.

Die folgende Gegenüberstellung zeigt, wo der Aufwand jeweils anfällt.

Warum KI-gestütztes Coding die Rechnung verschiebt

Das stärkste Argument für die fertige Komponente war immer der Bauaufwand der Oberfläche. Dieses Argument verliert gerade an Gewicht.

KI-gestützte Entwicklungswerkzeuge wie Claude Code erzeugen heute eine Ergebnisliste, ein Facettenpanel oder eine Autovervollständigung gegen eine dokumentierte API in Stunden. Was vor wenigen Jahren eine Sprint-Aufgabe war, ist zur überschaubaren Sitzung geworden. Die Renderschicht ist kein Engpass mehr.

An einem Beispiel wird das greifbar. Eine neue Ergebnisansicht mit Filtern, Sortierung und Autovervollständigung, die früher mehrere Personentage im Team kostete, entsteht gegen eine saubere API mit KI-Unterstützung oft an einem einzigen Tag. Die verfügbare Zeit fließt dann in Feinschliff und Barrierefreiheit.

Damit dreht sich das Verhältnis. Der Nutzen der vorgefertigten Komponente lag in der gesparten UI-Zeit, und dieser Nutzen schrumpft nun. Die Bindung an ein Framework, die den eigentlichen Preis dieser Wahl ausmacht, besteht unverändert weiter.

Eine starre, vom Anbieter vorgegebene Komponentenvorlage, die früher als Fundament diente, wirkt inzwischen eher wie ein Relikt und eine Einschränkung, für die es kaum noch einen sachlichen Grund gibt.

Was ein framework-unabhängiges Such-SDK ausmacht

Ein framework-unabhängiges Such-SDK dreht die Reihenfolge um. Im Mittelpunkt steht eine sprachneutrale Such-API, die jedes Frontend aufrufen kann. Eine feste Oberfläche für ein bestimmtes Framework gibt es bewusst nicht. Dazu kommen ein Server-SDK für die Backend-Anbindung und ein clientseitiges SDK für JavaScript- und TypeScript-Umgebungen.

Bei BatteryIncluded sieht das konkret so aus (Stand 10.09.2026). Das PHP-SDK wird über einen einzigen Composer-Befehl eingebunden:

composer require batteryincluded/batteryincluded-php-sdk

Es verlangt PHP in Version 8.2 oder höher sowie die Erweiterungen ext-curl und ext-mbstring. Das Paket ist quelloffen unter MIT-Lizenz und auf Packagist mit stabilen Versionen gelistet. Für JavaScript- und TypeScript-Projekte gibt es ein eigenes TypeScript-SDK. Für zwei verbreitete PHP-Ökosysteme liegen fertige Integrationen bereit, ein Plugin für Sylius und ein Bundle für Symfony.

Noch nicht so weit ist Go. Ein Repository dafür ist angelegt, enthält aber noch keinen Code, und kein Team sollte heute mit einem einsatzfähigen Go-SDK planen.

Die öffentliche API-Dokumentation liegt im Postman-Workspace von BatteryIncluded und ist ohne Anmeldung einsehbar. Dort finden Entwickler die Endpunkte, die jedes Frontend gegen dieselbe Such-API ansprechen kann.

Der Grund, warum dieser Aufbau trägt, liegt in der Architektur. BatteryIncluded ist entkoppelte Infrastruktur (Decoupled Architecture) aus Deutschland, keine Erweiterung, die nur einen vorhandenen Index spiegelt. Die Suche aggregiert Daten nativ aus ERP, PIM, CMS und Shopsystem und stellt sie über die API bereit. Im Kern arbeitet Volt Search® als Suchmaschine, ergänzt um Hybrid LLM Search für Anfragen, die über exakte Begriffe hinausgehen.

Warum ein SDK überhaupt der schnellste Weg zur Datennutzung ist, vertieft der Beitrag warum ein SDK der Schlüssel zur schnellen Nutzung von AI Data Discovery ist. Die Produktseite zu Volt Search® zeigt die Suchmaschine dahinter.

So läuft die Anbindung in der Praxis ab

In der Praxis folgt der Ablauf einer klaren Reihenfolge. Zuerst bindet das Backend die Suche über das Server-SDK an, im PHP-Fall über das PHP-SDK. Die Suchinfrastruktur aggregiert danach die Produktdaten aus den angeschlossenen Quellsystemen und baut daraus ihren Index auf. Diese Aggregation läuft nativ und nicht als Spiegelung eines fremden Index.

Danach spricht das Frontend nur noch die Such-API an. Es sendet die Eingabe des Nutzers, empfängt Treffer, Facetten und Vorschläge und zeichnet sie im eigenen Framework. Welches Framework das übernimmt, ist für die API ohne Belang. React, Angular und Vue senden denselben Aufruf und bekommen dieselbe Antwort.

Für die Renderschicht kommt heute die KI-Unterstützung ins Spiel. Ein Entwickler beschreibt die gewünschte Darstellung der Ergebnisse, das Werkzeug erzeugt gegen die dokumentierte API einen ersten Entwurf, und der Entwickler prüft und schärft ihn nach. So entsteht in kurzer Zeit eine Oberfläche, die zum eigenen Design passt und keiner fremden Vorlage folgen muss.

Über die Jahre bleibt die Such-API bestehen, während die Frontends darüber ausgetauscht werden. Diese Trennung von Suche und Oberfläche ist der eigentliche Gewinn, weil das Team seine Arbeit in eine stabile Schnittstelle investiert und diese Arbeit einen Technologiewechsel im Frontend übersteht.

Was hinter der API gleich bleibt

Der eigentliche Wert steckt in dem, was sich beim Frontend-Wechsel nicht bewegt. Die Suchfähigkeiten leben serverseitig und werden über denselben API-Aufruf angesprochen, egal ob React, Angular oder Vue das Ergebnis zeichnet.

Dazu gehört Fehlertoleranz (Typo-Tolerance). Ein Tippfehler führt damit nicht in eine leere Trefferliste. Die Facettensuche (Faceted Search) filtert nach Eigenschaften wie Größe, Marke oder Verfügbarkeit. Semantische Suche (semantic search) erfasst den User Intent hinter einer Formulierung, und hybride Suche (Hybrid Search) verbindet einen exakten Treffer mit unscharfer Bedeutung in derselben Anfrage.

Ebenso serverseitig liegt die Echtzeit-Synchronisation (Real-time Sync) der Daten. Ändert sich ein Preis oder ein Lagerbestand im ERP, ist die Änderung in der Suche sichtbar, ohne dass ein Frontend etwas dafür tun muss. Auch AI Recommendations und die Relevanzsteuerung arbeiten hinter der API.

Weil die Suche serverseitig und cookieless arbeitet, braucht dieses Modell kein Tracking im Browser und keine Zustimmung über ein Consent-Banner. Das macht die Ergebnisse zu DSGVO-konformer KI, unabhängig davon, welches Frontend sie darstellt. Für Entwicklerteams bedeutet das einen praktischen Vorteil, weil sie sich weder um die Einbindung eines Consent-Managers in jede Frontend-Variante noch um eine je Framework unterschiedliche Behandlung von Nutzerdaten kümmern müssen, solange die Suche selbst datensparsam hinter der API bleibt.

Wie diese Bedeutungsebene funktioniert, erklärt der Grundlagenbeitrag was ist semantische Suche.

Ein Index, der jedes Frontend versorgt

Damit ergibt sich ein weiterer Vorteil fast von selbst. Wenn Suche, Content und Produkte über eine Such-API laufen, ist es gleich, ob die Anfrage aus dem Web-Shop, einer App oder einem internen Katalog kommt. Alle greifen auf denselben Index zu.

Der Pflegeaufwand sinkt spürbar. Eine Relevanzregel, ein Synonym oder eine neue Datenquelle wird einmal serverseitig gepflegt und wirkt sofort in jedem angebundenen Frontend. Wie sich Inhalte und Produkte in einer Suche zusammenführen lassen, zeigt der Beitrag unified search für Content und Produkte.

Wenn im Backend mehrere Sprachen laufen

Größere Shops betreiben selten nur eine Sprache im Backend. Ein Dienst läuft in PHP, ein zweiter in JavaScript, ein interner Job vielleicht in einer weiteren Sprache. Eine framework- und sprachneutrale Such-API kommt damit ohne Sonderfall aus, weil jeder Dienst sie über HTTP anspricht.

Heute deckt BatteryIncluded PHP über das PHP-SDK sowie JavaScript und TypeScript über das TypeScript-SDK direkt ab. Ein Dienst in einer Sprache ohne fertiges SDK ruft die API weiterhin direkt auf, solange er HTTP-Anfragen stellen kann. Damit hängt die Erreichbarkeit der Suche nicht an der Sprachwahl eines einzelnen Teams.

Grenzen: wann eine fertige Komponente genügt

Nicht jedes Projekt braucht diesen Weg. Es gibt Fälle, in denen eine vorgefertigte Komponente die richtige Wahl bleibt.

Dazu zählt ein Wegwerf-Prototyp. Wenn Sie eine Idee validieren, ein Widget in Ihr einziges Framework setzen und das Ergebnis nach wenigen Wochen wieder verwerfen, zahlt sich Portabilität nicht aus. Die Bindung an ein Framework kostet dann nichts, weil der Code ohnehin nicht überlebt.

Ähnlich liegt der Fall bei einem einzigen, dauerhaft festgelegten Frontend. Ein Shop, der auf Jahre bei einem Framework bleibt, keine App plant und nur einen Kanal bedient, spürt die Kopplung vielleicht nie. Dann ist die schnellere Komponente ein legitimer Handel.

Auch ein sehr kleines Team ohne Frontend-Kapazität fährt mit einer fertigen Komponente manchmal besser, sofern es nur einen Kanal betreibt und keinen Wechsel absehen kann. Der Gewinn an Startgeschwindigkeit wiegt hier schwerer als eine Bindung, die sich womöglich nie auswirkt.

Zudem bleibt eine Grenze auf beiden Seiten. Ein SDK samt API baut die Oberfläche nicht für Sie. Selbst mit KI-Unterstützung entscheidet ein Mensch über Layout, Barrierefreiheit und den markeneigenen Umgang mit Suchergebnissen. Die API liefert dafür die Daten, doch wie diese erscheinen, bleibt eine Design- und Entwicklungsentscheidung, bei der ein Mensch im Prozess bleibt (Human-in-the-Loop).

Die Entscheidung im Team

Vor der Wahl helfen drei Fragen. Wie viele Frontends bedienen Sie heute, und wie viele in zwei Jahren? Rechnen Sie mit einem Framework-Wechsel oder einer nativen App? Laufen im Backend mehrere Sprachen, die dieselbe Suche brauchen?

Je öfter die Antwort auf mehr als ein Frontend hinausläuft, desto stärker spricht sie für den API-first-Weg. Bei einem einzelnen, stabilen Frontend darf die fertige Komponente gewinnen. Die Frage ist nicht, welcher Ansatz moderner klingt, sondern welcher zu Ihrer Frontend-Landschaft der nächsten Jahre passt.

Häufige Fragen

Brauche ich für React, Angular und Vue jeweils eigene Suchkomponenten?
Bei einer framework-gebundenen Komponente ist das nötig, weil jede an ihr Framework geknüpft ist. Bei einer API-first-Suche entfällt es. Alle drei Frontends rufen dieselbe Such-API auf und rendern die Antwort in ihrer eigenen Sprache.

Was ist der Unterschied zwischen einer UI-Komponente und einem Such-SDK?
Eine UI-Komponente ist fertiges Frontend für genau ein Framework. Ein Such-SDK ist eine Programmierschnittstelle, die dieselbe Suche ansprechbar macht, ohne eine Oberfläche vorzuschreiben, und lässt die Wahl des Frameworks offen.

Warum bindet ein PHP-SDK die Suche nicht an ein Frontend-Framework?
Ein PHP-SDK läuft im Backend und spricht die Such-API serverseitig an. Es bleibt damit unabhängig davon, ob im Frontend React, Angular oder Vue läuft, denn das Frontend sieht nur die API-Antwort.

Was passiert mit der Suche, wenn wir das Frontend-Framework wechseln?
Die Suche bleibt unberührt, weil sie serverseitig hinter der API liegt. Neu entsteht nur die Renderschicht im neuen Framework. Relevanz, Fehlertoleranz und Facetten bleiben identisch.

Lohnt sich ein framework-spezifisches Suchwidget gegenüber einer API-first-Lösung?
Für einen kurzlebigen Prototyp oder ein einziges, dauerhaft festgelegtes Frontend kann sich das Widget rechnen. Sobald ein zweites Frontend, eine App oder ein Framework-Wechsel realistisch wird, trägt die API-first-Lösung länger.

Welche PHP-Version verlangt das PHP-SDK von BatteryIncluded?
Das PHP-SDK setzt PHP 8.2 oder höher voraus, dazu die Erweiterungen ext-curl und ext-mbstring (Stand 10.09.2026). Der Bezug erfolgt über Composer mit dem Paket batteryincluded/batteryincluded-php-sdk.

Gibt es auch ein SDK für Go?
Für Go liegt noch kein einsatzfähiges SDK vor, das Repository ist zwar angelegt, aber ohne Code. Verfügbar sind heute das PHP-SDK und das TypeScript-SDK sowie die fertigen Integrationen für Sylius und Symfony.

Nächster Schritt

Ob eine framework-unabhängige Suche zu Ihrer Frontend-Landschaft passt, zeigt sich am schnellsten an Ihrem eigenen Katalog und Ihren eigenen Anfragen. In einer Demo sehen Sie die Such-API mit Ihren Produktdaten, inklusive Fehlertoleranz, Facetten und hybrider Suche. Zu Ihrer kostenlosen Demo, oder sprechen Sie uns direkt über die Seite Kontakt an.