Vergleich: PgArachne vs. PostgREST
| Merkmal | PgArachne (+ Universelle Funktionen) | PostgREST |
|---|---|---|
| Einrichtungsgeschwindigkeit | Hoch. Universelle Funktionen ermöglichen sofortiges CRUD ähnlich wie PostgREST. | Hoch. Generiert automatisch Endpunkte für alle Tabellen. |
| Logik-Flexibilität | Unbegrenzt. Fähigkeit, universelles CRUD mit spezifischen RPC-Funktionen zu kombinieren. | Begrenzt. Die meiste Logik muss in URL-Filtern oder Datenbank-Views liegen. |
| Schema-Handhabung | Nativ. Zugriff über schema.funktion. | Flach/Global. Erfordert das Wechseln von Profilen in HTTP-Headern, um Schemata zu ändern. |
| Abstraktion | Optional. Sie können Daten entweder direkt offenlegen (Proxy) oder sicher kapseln. | Gering. Die API ist im Wesentlichen ein Spiegelbild des Datenbankschemas. |
| KI & LLM Bereit | Extrem. JSON-RPC und die Fähigkeit, „Tool“-Funktionen speziell für KI-Agenten zu definieren. | Mittel. KI muss mit strikter URL-Parametersyntax kämpfen. |
| Statische Dateien | Ja. Liefert HTML/JS/CSS direkt aus einer einzigen Binärdatei aus. | Nein. Sie müssen einen externen Nginx davor konfigurieren und verwalten. |
| Realtime (SSE) | Ja. Eingebauter SSE-Endpunkt für PostgreSQL NOTIFY. | Nein. Erfordert eigenes Wiring (LISTEN/NOTIFY + separater Dienst). |
| Multi-Datenbank-Support | Serverweit (N:1). Eine einzelne PgArachne-Instanz verbindet sich mit dem Server (IP:Port) und kann alle dort gehosteten Datenbanken bedienen. | Pro Datenbank (1:1). Eine Instanz ist an eine spezifische Datenbank gebunden. Das Bedienen mehrerer Datenbanken erfordert das Ausführen mehrerer Instanzen auf verschiedenen Ports. |
| Authentifizierung | JWT & API-Schlüssel. Unterstützt nativ beide Welten. | Hauptsächlich JWT. |
| Rate Limiting | Ja. Integriertes Login-Limit (konfigurierbar). | Nein. Erfordert externen Proxy oder Middleware. |
Warum ist „Hybrides PgArachne“ der Gewinner?
Dank der Universellen Funktionen (die als Emulator fungieren), erhalten Sie das Beste aus beiden Welten:
- Startphase (MVP): Stellen Sie PgArachne mit wenigen Proxy-Funktionen bereit (wie die
in
universal_table_access.sql) und in Minuten haben Sie eine funktionierende API für alle Tabellen. In diesem Stadium verhält es sich exakt wie PostgREST. - Produktionsphase: Wenn die Anwendung wächst, beginnen Sie, dedizierte Funktionen
für sensible Operationen zu schreiben (z. B.
process_payment). Dies erhöht Sicherheit und Leistung, ohne den zugrunde liegenden Technologie-Stack zu ändern. - Frontend & KI: Gleichzeitig läuft Ihre Anwendung auf demselben Port wie die API (dank der Bereitstellung statischer Dateien), und KI-Agenten können Ihre Funktionen direkt über JSON-RPC aufrufen.
Hinweis: Die „Universellen Funktionen“ sind eine Reihe von Standard-PL/pgSQL-Funktionen, die Sie Ihrer Datenbank hinzufügen können, um generische Lese-, Erstellungs-, Aktualisierungs- und Löschvorgänge auf jeder Tabelle zu ermöglichen.