Porównanie: PgArachne vs. PostgREST
Porównanie: PgArachne vs. PostgREST
| Funkcja | PgArachne (+ funkcje uniwersalne) | PostgREST |
|---|---|---|
| Szybkość wdrożenia | Wysoka. Funkcje uniwersalne umożliwiają natychmiastowy CRUD podobnie jak PostgREST. | Wysoka. Automatycznie generuje endpointy dla wszystkich tabel. |
| Elastyczność logiki | Nieograniczona. Możliwość łączenia uniwersalnego CRUD z dedykowanymi funkcjami RPC. | Ograniczona. Większość logiki musi znajdować się w filtrach URL lub widokach bazy danych. |
| Obsługa schematów | Natywna. Dostęp przez schema.function. | Płaska/globalna. Wymaga przełączania profili w nagłówkach HTTP, aby zmienić schemat. |
| Abstrakcja | Opcjonalna. Można udostępniać dane bezpośrednio (proxy) albo bezpiecznie je zamknąć w enkapsulacji. | Niska. API jest zasadniczo odwzorowaniem schematu bazy danych. |
| Gotowość na AI i LLM | Ekstremalna. JSON-RPC i możliwość definiowania funkcji „Tool” specjalnie dla agentów AI. | Średnia. AI musi zmagać się ze ścisłą składnią parametrów URL. |
| Pliki statyczne | Tak. Serwuje HTML/JS/CSS bezpośrednio z jednego pliku binarnego. | Nie. Musisz skonfigurować i utrzymywać zewnętrzny Nginx przed nim. |
| Czas rzeczywisty (SSE) | Tak. Wbudowany endpoint SSE dla strumieni PostgreSQL NOTIFY. | Nie. Wymaga niestandardowego okablowania (np. LISTEN/NOTIFY + osobna usługa). |
| Obsługa wielu baz danych | Na poziomie serwera (N:1). Jedna instancja PgArachne łączy się z serwerem (IP:Port) i może obsłużyć wszystkie hostowane na nim bazy danych. | Per baza danych (1:1). Jedna instancja jest przypisana do jednej konkretnej bazy danych. Obsługa wielu baz danych wymaga uruchomienia wielu instancji na różnych portach. |
| Autoryzacja | JWT/tokeny API. Natywnie wspiera oba podejścia. | Głównie JWT. |
| Rate limiting | Tak. Wbudowane ograniczanie logowania (konfigurowalne). | Nie. Wymaga zewnętrznego proxy lub middleware. |
Czemu wygrywa „hybrydowe PgArachne”
Dzięki funkcjom uniwersalnym (działającym jako emulator) otrzymujesz to, co najlepsze z obu światów:
- Faza startowa (MVP): Wdróż PgArachne z kilkoma funkcjami proxy (takimi jak te w
universal_table_access.sql) i w ciągu kilku minut masz funkcjonalne API dla wszystkich tabel. Na tym etapie zachowuje się dokładnie jak PostgREST. - Faza produkcyjna: W miarę rozwoju aplikacji zacznij pisać dedykowane funkcje dla
operacji wymagających szczególnej ochrony (np.
process_payment). To zwiększa bezpieczeństwo i wydajność bez zmiany bazowego stacku technologicznego. - Frontend i AI: Jednocześnie Twoja aplikacja działa na tym samym porcie co API (dzięki serwowaniu plików statycznych), a agenci AI mogą wywoływać Twoje funkcje bezpośrednio przez JSON-RPC.
Uwaga: „Funkcje uniwersalne” to zestaw standardowych funkcji PL/pgSQL, które można dodać do swojej bazy danych, aby umożliwić generyczne operacje odczytu, tworzenia, aktualizacji i usuwania na dowolnej tabeli.