Als ich mit der Entwicklung der makesmart-Webseite begonnen habe, lag mein Fokus von Anfang an auf drei Aspekten: Stabilität, Modularität und Wartbarkeit. Die Suche war dabei lange ein fehlendes Feature - und ich wollte sie nicht einfach „hardcoden“ - denn sie sollte sich nahtlos in die bestehende Architektur einfügen und denselben Prinzipien folgen wie der Rest des Systems.

Und das hat sich ausgezahlt - es ist eine Suche entstanden, die sich tatsächlich selbst erweitert.

Zum Kapitel springen Architektur-Grundlage: Core & Plugins

Das makesmart-Framework ist bewusst pluginbasiert aufgebaut. Im Zentrum steht ein schlanker Core, der ausschließlich grundlegende Funktionen bereitstellt – etwa Routing, Authentifizierung, Rechteverwaltung und gemeinsame Utilities.

Alle zusätzlichen Features wie Blog, Threads oder die Suche sind als eigenständige Plugins umgesetzt. Diese lassen sich gezielt ein- und aushängen (hook-on / hook-off), ohne dass der Rest der Seite davon betroffen ist.

Jedes Plugin kapselt seine eigene Logik und besitzt klar definierte Zuständigkeiten. Gleichzeitig ist eine Kommunikation zwischen Plugins möglich, ohne direkte Abhängigkeiten zu erzeugen. Stellt ein Plugin Informationen für ein anderes Plugin bereit, wird der bestehende Inhalt lediglich angereichert. Ist das entsprechende Plugin nicht vorhanden, findet diese Anreicherung schlicht nicht statt.

Praktisch lässt sich dieses Prinzip am Zusammenspiel der Plugins Blog und Discord veranschaulichen. Beim Aufrufen eines Blog-Beitrags wird ein filter-Hook ausgelöst – das Blog-Plugin sendet dabei ein Event. Dieses Event kann entweder ins Leere laufen oder von anderen Plugins abgefangen werden.

In diesem Fall lauscht das Discord-Plugin auf den Hook und kann zusätzliche Informationen zurückliefern. Anhand der Tags des Blog-Beitrags wird anschließend entschieden, ob eine Verlinkung zum Discord-Server hergestellt wird – vorausgesetzt, ein gleichnamiger Kanal existiert.

Diese Architektur bildet die Grundlage für makesmart – und sie definiert auch die Anforderungen an die Suche.

Zum Kapitel springen Bezogen auf die Suchfunktion

Wie der Blog oder die Threads ist auch die Suche ein eigenständiges Plugin. Sie kann jederzeit hinzugefügt oder entfernt werden, ohne dass die Seite dabei „kaputtgeht“. Wird ein anderes Plugin entfernt, verschwinden lediglich dessen Suchergebnisse - sofern es überhaupt welche bereitgestellt hat. Der Rest des Systems bleibt davon unbeeinflusst.

Dieses Prinzip gilt auch in umgekehrter Richtung. Es wäre fatal, wenn bei jedem neuen Feature oder bei jeder neuen durchsuchbaren Datenquelle das Such-Plugin oder gar der Core angepasst werden müsste.

Kommt ein neues Plugin hinzu, das durchsuchbare Inhalte bereitstellt, werden diese automatisch Teil der Suche – ganz ohne Änderungen am Code der Suchfunktion.

Das zentrale Prinzip der Suche lautet daher:

Die Suche weiß nicht, was sie sucht oder wie sie sucht – sondern nur, dass sie sucht.

Zum Kapitel springen Selbstverwaltung durch Plugins

Die Suche trägt sich selbst: Die einzelnen Plugins entscheiden, was gesucht wird, wie gesucht wird und sogar ob gefundene Ergebnisse überhaupt in den Suchergebnissen erscheinen dürfen.

Das bringt gleich mehrere Vorteile. Eine zentrale Suche müsste entweder mit sehr komplexer, schwer wartbarer Logik arbeiten oder zwangsläufig immer dieselben Felder durchsuchen. Bei einer pluginverwalteten Suche ist das nicht der Fall.

Sucht man beispielsweise in Blog-Beiträgen, sind andere Felder relevant als bei Threads. Für Blog-Beiträge können das etwa folgende Felder sein:

title
content
description

Bei Threads hingegen spielen wiederum ganz andere Felder eine Rolle.

Da jedes Plugin seine Suche selbst verwaltet, bleiben die Zuständigkeiten klar getrennt – und die Suche passt sich automatisch an die jeweilige Datenstruktur an. Sie empfängt letzten Endes einfach nur die Ergebnisse einzelner Plugins und zeigt diese an.

Zum Kapitel springen Der Ablauf einer Suche

Zum Kapitel springen Sammeln der Queries

Wird eine Suche gestartet, löst das System ein Event aus. Symbolisch lässt sich dieses Event wie folgt darstellen:

filter:plugin:search:collect-plugin-query

Auf dieses Event lauschen alle Plugins, die Suchergebnisse bereitstellen. Aktuell sind das der Blog und die Threads.

Wie der Name des Events bereits andeutet, liefert jedes Plugin an dieser Stelle einen eigenen Query. Das Blog-Plugin definiert beispielsweise, welche Felder es durchsuchen möchte, ebenso das Threads-Plugin. Die jeweiligen Queries können sich dabei stark unterscheiden – abhängig davon, welche Inhalte ein Plugin zur Suche beitragen will.

Sobald alle Plugins ihre Queries bereitgestellt haben, verfügt die Suche über eine vollständige Abfragestruktur. Diese wird anschließend an eine Datenbank bzw. einen Suchindex übergeben, der die eigentliche Suche ausführt und die Treffer zurückliefert.
Im Fall der makesmart-Suche kommt hierfür Elasticsearch als Suchindex zum Einsatz.

Das Ergebnis dieser Abfrage sind sämtliche Treffer aller beteiligten Plugins, gebündelt in der Antwort des Suchindexes.

Da die erhaltenen Daten direkt raw aus einem Suchindex kommen, gibt es in der Search-Chain nun einen weiteren Schritt: Die Ergebnisse aus dem Suchindex werden anschließend wieder an die jeweiligen Plugins zurückverteilt.

Zum Kapitel springen Validieren der Ergebnisse

Nachdem die Suchergebnisse vom Suchindex zurückgeliefert wurden, werden sie erneut über ein Event an die Plugins übergeben. Auch dies geschieht über einen Hook, der symbolisch wie folgt aussieht:

filter:plugin:${PLUGIN-NAME}:search:validate-search-result

Dabei steht PLUGIN-NAME für das Plugin, das das jeweilige Suchergebnis validieren soll. Für Blog- und Thread-Ergebnisse würden entsprechend folgende Hooks ausgelöst:

filter:plugin:blog:search:validate-search-result
filter:plugin:threads:search:validate-search-result

Die gefundenen Treffer werden an die jeweils verantwortlichen Plugins zurückgesendet, damit diese ihre eigenen Ergebnisse validieren können – etwa im Hinblick auf Sichtbarkeit, Rechte oder inhaltliche Relevanz.

Ist man beispielsweise auf makesmart eingeloggt, erscheinen in den Suchergebnissen auch eigene Entwürfe. Diese sind ausschließlich für den jeweiligen Nutzer selbst sowie für Moderatoren sichtbar – nicht jedoch für die Öffentlichkeit.

Durch diese Validierung verbleibt die Kontrolle vollständig bei den einzelnen Plugins. Gleichzeitig entsteht ein gezielter Security-Layer, der insbesondere bei der Verwendung eines externen Suchindexes außerhalb der Hauptdatenbank unerlässlich ist, um die Integrität der Daten zu gewährleisten.

Zum Kapitel springen Einheitliches Suchergebnis-Format

Auch wenn die Suche Inhalte aus völlig unterschiedlichen Plugins verarbeitet, müssen die Ergebnisse am Ende in einer einheitlichen Form vorliegen. Genau dafür ist die Validierung in den Plugins zuständig.

Jedes Plugin übersetzt seine internen Datenstrukturen beim Validieren in ein gemeinsames, standardisiertes Suchergebnis-Format. Unabhängig davon, ob es sich um einen Blog-Beitrag, einen Thread oder etwas anderes handelt, liefert jedes Plugin dieselben grundlegenden Felder zurück – etwa Titel, Beschreibung, URL und Metadaten.

// Standardisiertes Suchergebnis-Format
const searchResult = {
  origin:      string,   // Name des Plugins (z. B. "blog", "threads")
  subOrigin:   string,   // Optionale Unterkategorie (z. B. Thread-Kategorie)
  title:       string,   // Haupttitel des Suchergebnisses
  description: string,   // Kurzbeschreibung / Vorschautext
  url:         string,   // Ziel-URL des Ergebnisses
  date:        Date,     // Relevantes Änderungs- oder Erstellungsdatum
  image:       string | null // Optionales Vorschaubild
}

Die Suche selbst arbeitet ausschließlich mit diesem Standardformat. Sie kennt weder die ursprüngliche Datenstruktur noch das zugrunde liegende Plugin. Dadurch lassen sich Suchergebnisse aus unterschiedlichen Quellen problemlos zusammenführen, sortieren und darstellen.

Dieses Vorgehen sorgt nicht nur für eine konsistente Darstellung, sondern trennt auch hier wieder klar die Zuständigkeiten:
Die Plugins kennen ihre Daten – die Suche kennt nur Ergebnisse.

Zum Kapitel springen Relevanz, Ranking und Gewichtung

Da jedes Plugin seine Suche selbst definiert, liegt auch die Kontrolle über Relevanz und Gewichtung bei den jeweiligen Plugins. Das bedeutet: Jedes Plugin entscheidet eigenständig, welche Felder zum Beispiel besonders wichtig sind und wie stark diese in die Bewertung der Suchergebnisse einfließen.

So kann ein Blog-Beitrag beispielsweise Titel und Beschreibung höher gewichten als den eigentlichen Inhalt, während bei Threads andere Kriterien eine größere Rolle spielen. Diese Gewichtung erfolgt bereits bei der Erstellung der Queries und wird an den Suchindex übergeben. Im Falle von Elasticsearch ist das sogar recht einfach. Eine Gewichtung einzelner Felder in einem Query des Plugins könnte wie folgt aussehen:

function buildBlogSearchQuery(searchTerm) {
  return {
    index: "blog_posts",
    query: {
      multi_match: {
        query: searchTerm,
        fields: [
          "title^3",          // Titel ist besonders wichtig
          "description^2",    // Meta-Beschreibung
          "content^1"         // Inhalt mit geringerer Gewichtung
        ],
        type: "best_fields"
      }
    }
  };
}

Der Vorteil dieses Ansatzes liegt darin, dass es keine globale, starre Relevanzlogik gibt. Stattdessen entsteht ein flexibles Ranking, das sich automatisch an die Struktur und Bedeutung der jeweiligen Inhalte anpasst. Die Suche selbst aggregiert lediglich die Ergebnisse - die Bewertung bleibt ebenfalls bei den Plugins selbst.

Zum Kapitel springen Was passiert, wenn ein neues Plugin hinzukommt?

Wie bereits erwähnt, ist ein zentrales Ziel der Architektur, neue Features bzw. Plugins ohne Anpassungen am bestehenden System integrieren zu können. Und das gilt insbesondere für die Suche.

Kommt ein neues Plugin hinzu, das durchsuchbare Inhalte bereitstellt, registriert es sich einfach an den entsprechenden Such-Hooks. Es liefert eigene Queries, definiert seine Gewichtung und validiert seine Ergebnisse - unabhängig von allen anderen Plugins.

Die Suche selbst muss dafür nicht angepasst werden. Sie „weiß“ weder, welche Plugins existieren, noch welche Inhalte diese bereitstellen. Sie koordiniert lediglich den Ablauf und aggregiert die Ergebnisse.

Auf diese Weise wächst die Suche automatisch mit dem System – ohne zusätzlichen Wartungsaufwand und ohne steigende Komplexität im Core.

Im Grunde kann man das Implementieren einer Suche für ein Plugin mit lediglich zwei Dateien erreichen:

collect-plugin-query.js
validate-search-result.js

Diese beiden Dateien sind im Prinzip einfach nur die Listener der Events, welche durch die Suche ausgelöst werden. Darin wird - wie der Dateiname schon verrät - einmal ein Query mit Relevanz und Gewichtung bereitgestellt und einmal das Suchergebnis an sich validiert.

Zum Kapitel springen Das Such-Plugin als Infrastruktur für Plugins

Da die Suche selbst ein eigenständiges Plugin ist, kann sie nicht nur global genutzt werden, sondern auch gezielt von anderen Plugins angesprochen werden.

Ein Plugin ist dadurch in der Lage, die Suchfunktion kontextuell zu verwenden – etwa um eine blog-spezifische Suche direkt innerhalb des Blog-Bereichs bereitzustellen. Die zugrunde liegende Suchlogik bleibt dabei identisch, die Darstellung und Gewichtung der Ergebnisse kann jedoch vollständig plugin-spezifisch erfolgen.

So kann der Blog beispielsweise ausschließlich Blog-Inhalte durchsuchen und die Ergebnisse im gewohnten Blog-Stil darstellen - indem auf die bekannten Blog-Templates und die vollwertigen Daten zurückgegriffen wird - während die globale Suche weiterhin pluginübergreifend nur mit den Minimaldaten arbeitet. Technisch greifen beide Varianten auf dieselbe Such-Infrastruktur zurück – lediglich der Kontext und die Darstellung unterscheiden sich.

Zum Kapitel springen Performance und Skalierung

Die Sammlung der Queries, die Abfrage des Suchindexes sowie die anschließende Validierung sind klar voneinander getrennt. Dadurch lassen sich einzelne Schritte gezielt optimieren oder parallelisieren.

Der Suchindex übernimmt ausschließlich die Aufgabe, relevante Treffer schnell zu liefern. Die eigentliche Geschäftslogik - etwa Rechteprüfung oder Filterung - bleibt bewusst außerhalb des Indexes. Dadurch bleibt die Suche auch bei wachsenden Datenmengen performant, skalierbar und vor allem sicher.

Mit zunehmender Anzahl an Plugins oder Inhalten lässt sich das System problemlos erweitern, ohne dass sich die Komplexität im Core oder im Such-Plugin erhöht.

Zum Kapitel springen Elasticsearch als Suchindex – nicht als Datenquelle

In makesmart dient Elasticsearch ausschließlich als Suchindex, nicht als Single Source of Truth. Die eigentlichen Daten verbleiben vollständig in den jeweiligen Plugins und deren Datenhaltung.

Dieser Ansatz ist bewusst gewählt. Ein externer Suchindex kennt weder die vollständige Geschäftslogik noch die komplexen Rechte- und Sichtbarkeitsregeln der Anwendung. Würden diese Regeln direkt im Index abgebildet, würde das System schnell unübersichtlich und fehleranfällig werden.

Stattdessen liefert der Suchindex lediglich potenzielle Treffer. Erst im Anschluss entscheiden die Plugins selbst, ob diese Treffer tatsächlich angezeigt werden dürfen. Dadurch bleibt die Datenintegrität gewahrt und sicherheitsrelevante Entscheidungen werden ausschließlich dort getroffen, wo die notwendige Kontextinformation vorhanden ist.

Zum Kapitel springen Die neue und erste Suche

Auch wenn die Architektur von makesmart bereits an vielen Stellen ihre Stärken gezeigt hat, war die Suche für mich noch einmal ein eigenes Kaliber. Gerade bei der Umsetzung hat sich bestätigt, dass das System auch bei komplexeren Anforderungen stabil und durchdacht funktioniert.

Die Suche ist dabei kein Sonderfall geworden, sondern fügt sich nahtlos in die bestehende Architektur ein. Durch die konsequente Trennung von Core, Plugins und Suchindex bleibt das System modular, wartbar und erweiterbar – ohne Sonderlogik oder Abhängigkeiten.

Plugins entscheiden selbst, wie und was sie zur Suche beitragen. Der Suchindex sorgt für Performance, die Validierung für Sicherheit und Datenintegrität.

Das Ergebnis ist eine Suche, die sich selbst trägt und mit dem System wächst – nicht trotz, sondern wegen der zugrunde liegenden Architektur.