PostgREST uyumluluğu: neleri kapsar ve alternatifler

PostgREST, mevcut bir PostgreSQL veritabanını doğrudan şemasından bir REST API'ye dönüştüren özerk bir web sunucusudur. Yazılacak uygulama katmanı yok: tablolar, görünümler ve işlevler rota haline gelir ve SQL izinleri (roller, RLS politikaları) yetkilendirme katmanı haline gelir.

Somut olarak PostgREST neredeyse tüm değerlendirmelerde ortaya çıkan beş yeteneği kapsar:

• Yatay filtreleme — yaklaşık otuz operatör (eq, gt, like, ilike, in, is, cs, ov, fts...) doğrudan sorgu dizesinde.
• Dikey filtreleme ve yerleştirme — ?select= yabancı anahtar yoluyla sütunları yansıtır ve ilişkileri katıştırır, örneğin customer:customers(email).
• RPC — bir POST /rpc/{fonction} doğrudan uç nokta haline gelen bir SQL işlevini çağırır.
• JWT tarafından yönlendirilen RLS — PostgREST, etkin Postgres rolünü alınan belirtece (SET LOCAL ROLE) göre değiştirir, böylece ilkeleriniz uygulama tarafında yinelenen yetkilendirme mantığı olmadan olduğu gibi uygulanır.
• Kendi kendine oluşturulan OpenAPI — spesifikasyon, elle bakımı yapılacak bir dosya olmadan, açığa çıkan şemadan çıkarılır.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

Tek bir HTTP isteği, ödenen siparişleri filtreler, müşterinin e-postasını yabancı anahtar aracılığıyla yerleştirir ve tek bir rotanın elle yazılmasına gerek kalmadan tarihe göre sıralar.

RPC de aynı mantığı izler: Zaten veritabanınızda yazılmış bir SQL işlevi, bağımsız değişkenleri JSON'da iletilen bir POST uç noktası haline gelir.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

Bu prensip (Postgres şeması, API'nin tek gerçek kaynağıdır) PostgREST'i öngörülebilir kılan şeydir: her davranış değişikliği bir SQL geçişinden geçer, asla gerçek şemadan türetilebilecek ayrı bir uygulama katmanından geçmez. Proje açık kaynak olup, herhangi bir BaaS sağlayıcısından bağımsız olarak GitHubüzerinde geliştirilmiştir.

PostgREST CRUD katmanını çözer. Bir uygulamanın arka ucunun geri kalanını çözmez. Bunu tek başına benimseyen ekipler arasında sistematik olarak dört eksiklik ortaya çıkıyor.

• Kimlik Doğrulaması — JWT düzenlemesi veya entegre kullanıcı yönetimi yok. Bunu SQL'de oluşturmanız veya harici bir hizmete devretmeniz gerekir.
• Dosya depolama — yok. Ayrı olarak bağlanmak için bir S3 kovası veya eşdeğeri kalır.
• Gerçek zamanlı — PostgREST tek seferlik HTTP isteklerine yanıt verir, herhangi bir olayı iletmez.
• Bağlantı Havuzlayıcısı — PostgREST'in kendisi Postgres'e bağlanır, ancak herhangi bir gelişmiş havuz oluşturucuyu entegre etmez. Büyük ölçekte, bunu yönetmek başlı başına bir işletim kararı haline gelir: klasik işlem modundaki bir havuzlayıcı, PostgREST şema yeniden yükleme mekanizmasıyla çelişir (Aurabase'in bu uzlaşmayı nasıl çözdüğüne aşağıda bakın).

Pratik bir sonucun açıkça belirtilmesi gerekir: Kimlik doğrulama olmadan RLS politikalarınız, anonim bir müşteri ile verileriniz arasındaki tek güvenlik sınırı haline gelir. anon rolüne ilişkin kötü yazılmış bir politika, ek bir uygulama katmanı tarafından üstlenilmez; yoktur.

Bir Aurabase Postgres motor projesinde (varsayılan motor) ağ geçidi, her CRUD isteğini doğrudan bu projeye ayrılmış bir PostgREST v12.2.8 örneğine, kiracının Postgres kümesiyle aynı konumda bulunan iki kopyaya yönlendirir. Bu yaklaşık bir uyumluluk değildir: aynı operatörlere, aynı yerleştirmeye, aynı RPC'ye, JWT tarafından sürülen aynı RLS'ye sahip PostgREST yukarı akış ikili dosyasının kendisidir.

MongoDB motoru projesinde hikaye farklıdır. MongoDB'nin PostgREST'e eşdeğeri yoktur: bu istekler aynı kuralların bir alt kümesini yeniden uygulayan dahili bir Aurabase hizmetine yönlendirilir (aynı operatör adları, gömmeli ?select= sözdizimi, Prefer ve Content-Range başlıkları) ancak ilişkisel bir motor değil bir belge motoru üzerinde. Bu katmanın kendi sınırlamaları vardır: bir mutasyon tarafından döndürülen gösterimde talep edilen bir yerleştirme sessizce göz ardı edilmek yerine açıkça reddedilir ve SQL işlevlerine eşdeğer bir RPC yolu yoktur.

Teknik bir ayrıntı, sezgiyle çelişiyor: her tahsis edilmiş PostgREST örneği, bu kiracı için dağıtılan PgBouncer havuzlayıcısından geçmeden doğrudan birincil Postgres'e bağlı kalır. Varsayılan neden: işlem havuzu modu, her işlem için bağlantıyı geri dönüştüren bir havuzla uyumlu olmayan kalıcı bir bağlantı olan LISTEN/NOTIFY'ye dayanan PostgREST şemasının yeniden yüklenmesini bozacaktır.

Üretimdeki bir başka yararlı ayrıntı: Etkin olmayan bir proje, kaynaklardan tasarruf etmek için duraklatılabilir. Uyuyan bir projedeki ilk istek, projenin uyanmasını tetikler ve yeniden deneme gecikmesiyle bir 503 alır; bu, özel PostgREST örneğinin geri gelme zamanıdır; bu, gizli bir olay değil, maliyet ile soğuk gecikme süresi arasında varsayılan bir uzlaşmadır.

PostgREST'in net bir kullanımı var: Postgres şeması gerçeğin kaynağıdır ve ekip, CRUD katmanını elle yazmaktan kaçınmak istiyor. Bu özel durumun dışında, ne eklemek istediğinize bağlı olarak, hiçbir şeyden (kendi kendine barındırılan) tamamen kullanıma hazır bir arka uca kadar çeşitli alternatif ailesi mevcuttur.

Aşağıdaki tablo, her bir proje tarafından seçilen mimariye ilişkin değer yargısı olmaksızın, her seçeneğin doğal olarak neyi kapsadığını ve açıkça size neyi bıraktığını karşılaştırmaktadır.

"Kendi kendine barındırılan" seçeneğini seçerken sıklıkla göz ardı edilen bir nokta: PostgREST'in çalıştırılması hafif kalır, ancak üretim operasyonu (sürüm güncellemesi, yüksek kullanılabilirlik, bir havuz oluşturucuyla ilişkilendirme, izleme) tamamen sizin sorumluluğunuzda kalır - yönetilen platformların özümsediği şey yazılım değil, bu operasyon çalışmasıdır.

GraphQL yaklaşımları (pg_graphql, Hasura ve PostGraphile) arasında ayrıntılı bir karşılaştırma için Postgres'teki GraphQL API'sine adanmış makalemize bakın.

En sık dört durum ortaya çıkar. Doğru seçim esas olarak neyi bir araya getirmek ve kendiniz korumak istediğinize bağlıdır.

• Sadece mevcut bir Postgres şeması üzerinde bir REST API istiyorsunuz, başka bir şey değil. Kendi kendine barındırılan PostgREST yeterlidir: tam olarak ne yapıyorsa onu yapar ve başka hiçbir şeyin kurulmasına gerek yoktur.
• Ek yetkilendirmeye, depolamaya ve gerçek zamanlıya ihtiyacınız var ve çeşitli hizmetleri birleştirmeye hazırsınız. Supabase veya PostgREST, kendi uygulama yığınınızla birlikte bu ihtiyacı karşılar.
• GraphQL'i REST'e tercih edersiniz. Hasura veya PostGraphile bu zemini kapsıyor — farklı bir mimari seçim, PostgREST'in doğrudan yerine geçmiyor.
• Birden fazla ayrı hizmeti bir araya getirmeden eksiksiz bir Postgres arka ucu istiyorsunuz. Bu, birleştirilmiş Rust mimarimizin belgelediği açıdır: doğal olarak kimlik doğrulama, depolama, gerçek zamanlı ve uç işlevlerle çevrelenmiş CRUD katmanı için gerçek PostgREST.