Comparaison : PgArachne vs PostgREST
| Fonctionnalité | PgArachne (+ Fonctions universelles) | PostgREST |
|---|---|---|
| Vitesse d’installation | Élevée. Les fonctions universelles permettent un CRUD instantané similaire à PostgREST. | Élevée. Génère automatiquement des points de terminaison pour toutes les tables. |
| Flexibilité logique | Illimitée. Capacité à combiner un CRUD universel avec des fonctions RPC spécifiques. | Limitée. La plupart de la logique doit résider dans les filtres d’URL ou les vues de base de données. |
| Gestion des schémas | Native. Accès via schéma.fonction. | Plat/Global. Nécessite de changer de profil dans les en-têtes HTTP pour changer de schéma. |
| Abstraction | Optionnelle. Vous pouvez soit exposer les données directement (proxy), soit les encapsuler de manière sécurisée. | Faible. L’API est essentiellement un miroir du schéma de la base de données. |
| Prêt pour l’IA et les LLM | Extrême. JSON-RPC et capacité à définir des fonctions « Outil » spécifiquement pour les agents IA. | Moyenne. L’IA doit lutter avec la syntaxe stricte des paramètres d’URL. |
| Fichiers statiques | Oui. Sert le HTML/JS/CSS directement depuis un binaire unique. | Non. Vous devez configurer et gérer un Nginx externe devant lui. |
| Temps réel (SSE) | Oui. Endpoint SSE intégré pour PostgreSQL NOTIFY. | Non. Nécessite un wiring dédié (LISTEN/NOTIFY + service séparé). |
| Support multi-bases de données | À l’échelle du serveur (N : 1). Une seule instance PgArachne se connecte au serveur (IP : Port) et peut servir toutes les bases de données qui y sont hébergées. | Par base de données (1 : 1). Une instance est liée à une base de données spécifique. Servir plusieurs bases de données nécessite d’exécuter plusieurs instances sur des ports différents. |
| Authentification | JWT et clés API. Prend en charge nativement les deux mondes. | Principalement JWT. |
| Rate limiting | Oui. Limitation de login intégrée (configurable). | Non. Nécessite un proxy ou middleware externe. |
Pourquoi « PgArachne Hybride » est-il le gagnant ?
Grâce aux Fonctions universelles (agissant comme un émulateur), vous obtenez le meilleur des deux mondes :
- Phase de démarrage (MVP): Déployez PgArachne avec quelques fonctions proxy (comme
celles dans
universal_table_access.sql) et en quelques minutes, vous avez une API fonctionnelle pour toutes les tables. À ce stade, il se comporte exactement comme PostgREST. - Phase de production : Au fur et à mesure que l’application grandit, commencez
à écrire des fonctions dédiées pour les opérations sensibles (par ex.
process_payment). Cela augmente la sécurité et les performances sans changer la pile technologique sous-jacente. - Frontend et IA : En même temps, votre application tourne sur le même port que l’API (grâce au service de fichiers statiques), et les agents IA peuvent appeler vos fonctions directement via JSON-RPC.
Note : Les « Fonctions universelles » sont un ensemble de fonctions PL/pgSQL standard que vous pouvez ajouter à votre base de données pour permettre des opérations génériques de Lecture, Création, Mise à jour et Suppression sur n’importe quelle table.