Порівняння: PgArachne проти PostgREST
Порівняння: PgArachne проти PostgREST
| Характеристика | PgArachne (+ універсальні функції) | PostgREST |
|---|---|---|
| Швидкість налаштування | Висока. Універсальні функції забезпечують миттєвий CRUD, подібний до PostgREST. | Висока. Автоматично генерує ендпоінти для всіх таблиць. |
| Гнучкість логіки | Необмежена. Можливість комбінувати універсальний CRUD зі специфічними RPC-функціями. | Обмежена. Більшість логіки має розміщуватися у фільтрах URL або представленнях бази даних (Views). |
| Робота зі схемами | Нативна. Доступ через schema.function. | Плоска/глобальна. Вимагає перемикання профілів у заголовках HTTP для зміни схем. |
| Абстракція | Опціональна. Ви можете або надавати дані безпосередньо (проксі), або безпечно їх інкапсулювати. | Низька. API — це, по суті, віддзеркалення схеми бази даних. |
| Готовність до AI та LLM | Надзвичайна. JSON-RPC та можливість визначати функції-«інструменти» («Tool») спеціально для AI-агентів. | Середня. AI змушений долати сувору синтаксичну структуру параметрів URL. |
| Статичні файли | Так. Надає HTML/JS/CSS безпосередньо з одного бінарного файлу. | Ні. Потрібно налаштовувати та підтримувати зовнішній Nginx перед ним. |
| Реальний час (SSE) | Так. Вбудований ендпоінт SSE для потоків PostgreSQL NOTIFY. | Ні. Вимагає окремого налаштування (наприклад, LISTEN/NOTIFY + окремий сервіс). |
| Підтримка декількох баз даних | На рівні сервера (N:1). Один екземпляр PgArachne підключається до сервера (IP:Port) і може обслуговувати всі бази даних, розміщені на ньому. | На кожну базу даних (1:1). Один екземпляр прив’язаний до однієї конкретної бази даних. Для обслуговування декількох баз даних потрібно запускати кілька екземплярів на різних портах. |
| Автентифікація | JWT/API-токени. Нативно підтримує обидва підходи. | Переважно JWT. |
| Обмеження частоти запитів (Rate Limiting) | Так. Вбудоване обмеження частоти спроб входу (налаштовується). | Ні. Вимагає зовнішнього проксі або middleware. |
Чому переможе «гібридний PgArachne»
Завдяки універсальним функціям (що діють як емулятор) ви отримуєте найкраще з обох світів:
- Етап запуску (MVP): Розгорніть PgArachne з кількома проксі-функціями (як ті, що в
universal_table_access.sql), і за кілька хвилин у вас буде функціональний API для всіх таблиць. На цьому етапі він поводиться точно так само, як PostgREST. - Продакшн-етап: У міру зростання застосунку почніть писати спеціалізовані функції для
чутливих операцій (наприклад,
process_payment). Це підвищує безпеку та продуктивність без зміни базового технологічного стеку. - Frontend та AI: Водночас ваш застосунок працює на тому самому порті, що й API (завдяки обслуговуванню статичних файлів), а AI-агенти можуть викликати ваші функції безпосередньо через JSON-RPC.
Примітка: «Універсальні функції» — це набір стандартних функцій PL/pgSQL, які можна додати до вашої бази даних, щоб увімкнути загальні операції читання, створення, оновлення та видалення для будь-якої таблиці.