Solutions

TL;DR

Eine solution ist der gesamte Stack eines ausgelieferten Pipelogic-Produkts: eine component (wiederverwendbare typisierte Fähigkeit) wird in ein backend (typisierter Graph) gepinnt, das als deployment läuft und entweder von direkten Aufrufern oder über eine application (UI, durch stabile Aliase an deployte endpoints gebunden) erreicht wird.
Ein driver ist der benannte, wiederverwendbare Vertrag, den eine application pinnt. Die application referenziert zwei: needs_driver (live-wire-Vertrag — Transport pro UX-Bedarf) und taps_driver (capture- und replay-Vertrag — immer HTTP, beide Richtungen). Ein backend erfüllt einen driver, wenn seine endpoint-Aliase mit jedem erforderlichen endpoint übereinstimmen, den der driver deklariert — keine driver_id lebt auf dem backend, die Übereinstimmung ist implizit.
Die Arbeit beim Bauen einer solution ist meist Komposition, nicht Coding. components im Katalog werden in backends verdrahtet; backends werden zu deployments; deployments legen endpoints frei; applications binden an diese endpoints. custom Code taucht nur dort auf, wo der Katalog die Fähigkeit nicht bereits abdeckt.
endpoint-Aliase halten eine application von vertex-IDs entkoppelt. Ein backend bildet (vertex, endpoint-name) auf einen stabilen Rollen-String ab; die application löst den Alias upload gegen das deployment auf, statt einen bestimmten vertex-endpoint zu pinnen.
Die Reihenfolge der Operationen für die meiste Produktarbeit ist reuse vor swap vor build: von einem veröffentlichten backend oder einer component im Solutions-Katalog ausgehen, einen Anbieter tauschen, wenn die Rolle passt, aber die Implementierung wechseln soll, und custom Code nur schreiben, wenn kein Katalog-Eintrag die Fähigkeit abdeckt.
Eine solution ist fertig, wenn das erwartete Verhalten im live runtime beobachtbar ist — Ausgaben fließen, Container-Logs gesund, generierte Dateien dort, wo sie sein sollten — nicht, wenn der Graph bloß existiert.

Was "solution" hier bedeutet

Eine solution ist die Komposition aller vier Schichten — component, backend, deployment, application (oder direkter Aufrufer) — zu einem Produkt, mit dem ein Endbenutzer interagiert. Der Begriff benennt den gesamten Stack statt einer einzelnen Primitive.

Der Vertrag ist präzise, weil die Schichten many-to-many sind: dieselbe component kann in Dutzenden von solutions sitzen, dasselbe backend kann mehr als eine Produktoberfläche bedienen, und dasselbe deployment kann die endpoint-Bindungen von mehr als einer application hosten. Ein einzelnes Wort für das zusammengesetzte Produkt bedeutet, dass ein Gespräch über "dieses Produkt" nicht aufzählen muss, welche component-Versionen, welche backend-Revision, welches deployment und welcher application-Build gemeint sind. Das Wort meint all jene, verbunden durch die Alias- und Bindungsverträge, die die Plattform erzwingt.

Jede Schicht erledigt eine Aufgabe. components bleiben generisch, backends komponieren sie, deployments führen sie aus, und applications legen sie offen. Die Grenzen sind streng: eine component weiß nicht, welches backend sie verwendet, ein backend weiß nicht, welches deployment es ausführt, und ein deployment weiß nicht, welche application seine endpoints auflöst. Diese Trennung ist das, was dieselben Primitive über viele solutions hinweg wiederverwendbar macht.

Mentales Modell — die vier Schichten

   ┌─────────────────────────────────────────────────────┐
   │  Application        UI; resolves endpoint aliases        │
   ├─────────────────────────────────────────────────────┤
   │  Deployment    the backend running on a runtime     │
   ├─────────────────────────────────────────────────────┤
   │  Backend       typed graph + per-vertex bindings    │
   ├─────────────────────────────────────────────────────┤
   │  Component     reusable typed capability            │
   └─────────────────────────────────────────────────────┘

Von unten nach oben gelesen: eine component ist eine wiederverwendbare typisierte Fähigkeit mit deklarierten input-Slots, output-Slots, Konfigurationsparametern und optionalen Datei-Slots. Ein backend ist der produktspezifische Graph, der component-Releases als vertices pinnt, ihre Parameter und Dateien bindet, ihre typisierten Streams verbindet und den endpoints, die externe Aufrufer erreichen werden, stabile Rollennamen gibt. Ein deployment führt dieses backend auf einem runtime aus, materialisiert den Graphen als Container und veröffentlicht aufgelöste URLs für jeden endpoint-Alias. Eine application ist die UI, die per Alias an das deployment gebunden ist — sie fragt nach upload und events und bekommt die live-URLs zurück, ohne je zu wissen, welcher vertex oder welches Release gerade dahintersteht.

Ein backend hostet zu einem Zeitpunkt höchstens ein deployment — die Verknüpfung ist 1:1 by design, sodass eindeutig ist, was gerade läuft. Um zwei Umgebungen parallel zu betreiben (Staging und Produktion, A und B, Blue und Green), forke zuerst das backend und deploye jeden Fork unabhängig. Jede Umgebung ist dann ihr eigenes Objekt mit eigener Operationshistorie, was das Verhalten pro Umgebung unkompliziert auditierbar hält.

Siehe Components, Backends, Deployments, Applications für jede Schicht im Detail.

endpoint-Aliase — die Entkopplung zwischen Graph und Oberfläche

Verwende diese Rahmung immer dann, wenn eine UI oder ein externer Aufrufer eine stabile URL benötigt.

Eine component deklariert die endpoints, die ihr vertex freilegt, wenn er läuft. Die input_image_http-component deklariert einen Ingress-endpoint, der Bild-Uploads akzeptiert; output_json_http deklariert einen Egress-endpoint, der jeden typisierten Wert als JSON emittiert; eine LLM-component deklariert einen Egress-endpoint, der generierte Tokens über einen Server-Sent-Events-Transport streamt. Jeder endpoint hat einen component-lokalen Namen, einen Port, eine Art (Ingress oder Egress) und einen oder mehrere Transporte (HTTP, WebSocket, SSE, WebRTC, multipart), die ihn tragen.

Der component-lokale Name ist über eine solution hinweg nicht stabil. vertex 1 in einem backend könnte vertex 7 in einem anderen sein. Der endpoint-Name, den eine component intern verwendet, könnte der application nichts bedeuten. Die backend-Schicht behebt das, indem sie (vertex, endpoint-name) auf einen stabilen Rollen-String abbildet über ppl backend change-endpoint-alias. Die application spricht mit Rollen, nicht mit vertices.

   ┌─────────────────────┐                       ┌────────────────────┐
   │ vertex 1  (ingress) │                       │ application POSTs       │
   │ "image_input"       │───────────── upload ─▶│ the image here     │
   └─────────────────────┘                       └────────────────────┘

   ┌─────────────────────┐                       ┌────────────────────┐
   │ vertex 3  (egress)  │                       │ application subscribes  │
   │ "output_json_http"  │───────────── events ─▶│ to events here     │
   └─────────────────────┘                       └────────────────────┘

Wenn das deployment hochkommt, veröffentlicht es die aufgelöste URL für jeden Alias. Die application löst upload und events gegen das deployment auf und bleibt von vertex-IDs, component-Releases und runtime-Platzierung entkoppelt. Das zugrundeliegende component-Release zu tauschen, den vertex umzunummerieren oder die Implementierung komplett zu ändern, lässt die application weiterarbeiten, solange der Alias noch existiert.

Diese Indirektion ist das, was eine application backend-Änderungen überleben lässt: der Alias ist der Vertrag, und der vertex dahinter ist ein Implementierungsdetail. Eine backend-Mutation, die einen vertex berührt, bricht die UI nicht, solange der Alias, den sie auflöst, bestehen bleibt.

Reuse, swap, build — in dieser Reihenfolge

Verwende diese Rahmung beim Planen einer neuen solution.

Reuse zuerst. Öffne den Solutions-Katalog und suche nach einem veröffentlichten backend, das zu dem Ergebnis passt, das die solution benötigt. Wenn eines passt, forke es in den Workspace und iteriere von dort — die Graph-Zusammensetzung ist bereits erledigt; was bleibt, sind Parameter-Tuning, Dateibindung und vielleicht eine application.

Swap, wenn die Rolle stimmt, aber der Anbieter wechseln soll. Ein backend, das um eine bestimmte Rolle herum verdrahtet ist — eine OCR-component, ein Bildklassifizierer oder ein LLM — kann üblicherweise auf einen anderen Anbieter in derselben Rolle umgestellt werden, indem das component-Release auf diesem einen vertex getauscht wird. Das Typsystem treibt das an: die Plattform bewahrt jeden Parameter, jede Dateibindung und jede Kante, die gegen das neue Release noch typcheckt, und verwirft alles, was nicht mehr passt. Führe den swap zuerst im Plan-Modus aus, um genau zu sehen, was verworfen würde; der apply-Schritt verweigert standardmäßig, sobald etwas verloren ginge, sodass ein brechender swap nie stillschweigend landet — du bestätigst die Verwerfungen explizit, bevor sie committen.

Build zuletzt. Schreibe eine custom component nur dann, wenn kein Katalog-Eintrag die Fähigkeit abdeckt, die die solution benötigt, oder wenn die Logik produktspezifisch genug ist, dass eine generische component die falsche Abstraktion wäre. Der Katalog ist nach Kategorie und Modalität indiziert, sodass "ist das, was ich brauche, schon hier" eine Suche entfernt ist; build füllt die Lücken, die die Suche offenlegt.

Die Reihenfolge spiegelt wider, wie viel Arbeit jeder Schritt kostet. Ein backend wiederzuverwenden verwendet einen zusammengesetzten Graphen wieder; eine component zu tauschen ändert einen vertex; eine component zu bauen fügt neuen Code zum Verfassen, Releasen und Pinnen hinzu. Vor build nach reuse und swap zu greifen, hält eine solution so lange auf der getesteten Oberfläche des Katalogs, wie die Rolle es erlaubt.

Wie externe APIs hineinpassen

Verwende diese Rahmung immer dann, wenn die solution mit einem model-Server, einer Datenbank, einem Webhook, einem Hardware-Gerät oder einem Drittanbieter-Dienst sprechen muss.

Externe APIs sind auf Pipelogic keine besondere Kategorie. Sie tauchen als normale components mit ihren typisierten Eingaben und Ausgaben auf, und ihre Behandlung von Authentifizierung, Retry, Transport und Rate-Limits lebt innerhalb der component. Aus der Sicht des backend-Graphen sehen ein vertex, der mit einer gehosteten model-API spricht, und ein vertex, der ein lokales ONNX-Modell ausführt, gleich aus: typisiert rein, typisiert raus, Parameter und secrets gebunden, als Container deployt.

Diese Einheitlichkeit bedeutet, dass es keine separate Plugin-API gibt. Pipelogic hat kein separates model-provider-SDK, kein Datenbank-Connector-Framework und keine Message-Broker-Integrationsschicht — alles ist eine component, jede component hat denselben Vertrag, und jede solution komponiert sie auf dieselbe Weise. Integrationsautoren schreiben kleine components, statt Anbieter zu registrieren, und solution-Autoren komponieren sie durch eine einzige Abstraktion, unabhängig davon, womit jede component spricht.

Referenz-Schnappschuss — Schichtgrenzen

Schicht	Besitzt	Besitzt nicht
Component	typisierte I/O, Code, Parameter, Defaults, Release-Metadaten	das backend, in dem sie läuft, die Bindungen auf einem gegebenen vertex
Backend	den Graphen, Parameter- und Dateibindungen pro vertex, endpoint-Aliase, runtime-Overrides	die component-Implementierung, das runtime, die application
Deployment	das live runtime für ein backend, aufgelöste URLs pro Alias	die backend-Graph-Definition, die application-UI
Application	die UI, driver-Pins (`needs_driver`, `taps_driver`), Alias-Auflösung gegen ein deployment	den backend-Graphen, den deployment-Lebenszyklus, den component-Code
Driver	den benannten Vertrag (erforderliche endpoints, erforderliche worker-Promises, erforderliche Fills), an dem sich jedes backend und jede application ausrichtet	die Implementierung hinter einem Alias, den Transport zur Laufzeit

component-Releases sind unveränderlich. Ein neueres Release einer component stört ein backend nicht, das ein älteres gepinnt hat — Rebinding ist eine explizite backend-Änderung, nie ein Nebeneffekt einer Promotion.

Wann ist eine solution "fertig"

Dass der Graph existiert, ist nicht die Messlatte. Eine solution ist fertig, wenn das erwartete Verhalten im live runtime beobachtbar ist: repräsentative Eingaben erzeugen die richtigen Ausgaben, Container-Logs sind sauber, generierte Dateien landen, wo sie sollen, und die application (wenn es eine gibt) rendert ohne manuelle Wiederherstellung. Diese Beobachtung ist die Nachweis-Schleife, und es ist dieselbe Schleife, die in Verhalten nachweisen beschrieben wird.

Der Nachweis-Schritt ist das, was die Belege hinter einer Promotion-Entscheidung liefert. Produktionsreif bedeutet, dass diese Belege existieren, nicht, dass der Graph zusammengesetzt wurde.

Wo das hineinpasst

Solutions sind das Vokabular der Plattform für das ausgelieferte Produkt als Ganzes. Die Vier-Schichten-Trennung ist das, was dieses Produkt zusammensetzbar, modifizierbar, redeploybar und wiederverwendbar macht. Die Primitive — typisierte components, event-sourced backends, getrennte deployments, alias-gebundene applications — geben jeder dieser Eigenschaften ein konkretes Objekt, an dem sie haftet.

Verwandt

Components — wiederverwendbare typisierte Bausteine.
Backends — typisierter Graph + Bindungen.
Deployments — laufende backends + aufgelöste URLs pro Alias.
Applications — UIs, die Aliase gegen deployments auflösen.
Types — der Vertrag, der über alle Schichten hinweg erzwungen wird.
Solution-Publishing — eine solution öffentlich teilen.
Quickstart — Routen-Auswahl für deine erste Aufgabe.