PostgREST ve Hasura ve özel bir API karşılaştırması

“PostgREST mi Hasura mı yoksa özel API” sorusu daha faydalı bir soruyu gizliyor: İş mantığınızı kim, hangi araçla yazıyor ve bu kodu üretimde kim kullanıyor? Üç mimari farklı tepki veriyor ve bu fark diğer her şeyi (güvenlik, uygulama hızı, uzun vadede teknik borç) yapılandırıyor.

Üç sütundan hiçbiri kesinlikle daha iyi değil: her biri işi başka bir yere kaydırıyor. PostgREST bunu SQL'e, Hasura'yı yapılandırmaya ve özel bir API olan web kancalarına, klasik uygulama koduna taşır.

PostgREST, Postgres şemanızı yazılacak arka uç olmadan filtreler, ilişki yerleştirme, RPC, JWT tarafından yönlendirilen RLS'den oluşan bir REST API'sine dönüştürür. Bu kapsamı, gerçek uyumluluğu ve alternatifleri hakkındaki makalemizde derinlemesine detaylandırıyoruz; Bu karşılaştırma için önemli olan PostgREST'in nerede durduğudur.

PostgREST'in keyfi iş mantığı kavramı yoktur. Her kuralın SQL'de ifade edilmesi gerekir: bir RPC işlevi, bir tetikleyici, bir kısıtlama, bir RLS ilkesi. Bu, bir gözden kaçırma değil, kabul edilmiş bir kısıtlamadır; diyagram, bir uygulama katmanı ile hizmet ettiği taban arasındaki herhangi bir sapmayı ortadan kaldıran tek gerçek kaynak olmaya devam etmektedir.

Somut olarak, üçüncü taraf bir ödeme hizmetini aramak, onay e-postası göndermek veya doğrudan PostgREST isteğinden JavaScript'te bir puan hesaplamak imkansızdır. Bu mantık ya SQL'de yaşamalı (pl/pgsql işlevi) ya da dışarıda tetiklenmelidir - artık PostgREST olmayan harici bir hizmet tarafından dinlenen bir NOTIFYolayı yayınlayan bir tetikleyici.

Our article on GraphQL layers on Postgres details where the Hasura engine runs and how its permissions differ from the Postgres RLS. Here, the angle is that of business logic: how to plug custom code into a database managed by Hasura, and where.

Bir Eylemi Hasura, seçtiğiniz dilde yazdığınız bir HTTP web kancası tarafından desteklenen özel bir GraphQL mutasyonunu veya sorgusunu ortaya çıkarır. Hasura, girişleri bildirilen şemaya göre doğrular, web kancanızı çağırır ve ardından yanıtını istemciye geri gönderir. CRUD'un ötesine geçen her türlü mantığa açılan kapıdır: ödeme sağlayıcısına çağrı, karmaşık hesaplama, çok adımlı orkestrasyon.

Olay Tetikleyicileri ters yönü takip eder: tablodaki bir ekleme, güncelleme veya silme işlemi, eşzamansız olarak ve başarısızlık durumunda otomatik yeniden başlatmayla bir web kancasını tetikler. Bu, çoğu Hasura entegrasyonunun, bu kodu ilk müşteri isteğine bağlamadan bir üçüncü taraf hizmetini (faturalandırma, işlemsel e-posta, arama motoru) senkronize etmek için kullandığı mekanizmadır.

Hasura ayrıca önceden yazılmış bir GraphQL sorgusunu, adlandırılmış bir yol ve parametrelerle (kendi belgelerinin terminolojisinde RESTifieduç noktaları) tipik bir REST rotası olarak ortaya çıkarabilir. Ön uç ekibiniz temel GraphQL izin motorundan vazgeçmeden REST kullanmayı tercih ediyorsa kullanışlıdır.

Özel makalemizde geliştirilen bağlam hatırlatıcısı: Hasura, Haziran 2025'ten bu yana, resmi web sitesinde hala "savaşta test edilmiş" olarak sunulan GraphQL motorunu kaldırmadan, iletişimini AI aracıları için tasarlanmış bir katman olan PromptQL'e yeniden odakladı.

Elle yazılan bir API'nin tanımı gereği hiçbir sınırı yoktur: herhangi bir dilde, herhangi bir bağımlılıkla herhangi bir iş mantığı. Aynı zamanda sizin için hiçbir şeyin üretilmediği üç seçenekten sadece biridir; her rota, her doğrulama, veritabanına olan her bağlantı, sahip olduğunuz ve sürdürmeniz gereken koddur.

// Filtreleme, sıralama ve ilişki yerleştirme elle yazılır,
// yalnızca bu rota için — her API kaynağı için tekrarlayın
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

Bu model, manuel çalışma karşılığında şunları sunar: hatalar ve döndürülen HTTP kodları üzerinde tam kontrol, klasik test edilebilirlik (bildirimsel yapılandırma değil işleyiciler) ve kendi diline zaten hakim olan bir ekip için öğrenilecek yeni DSL yok.

Karşılığında maliyeti nedir: Her kaynak için elle yazmak ve sürdürmek için CRUD, sayfalandırma ve filtreler; otomatik olarak devralınan RLS olmadan kendinizin uygulayıp denetlemesi için kimlik doğrulama ve yetkilendirme; her iç içe ilişkinin disiplin olmadan kendi Postgres sorgusunu tetiklemesi durumunda N+1 sorgu riski; ve API belgelerinin manuel olarak veya entegre edilecek bir üçüncü taraf oluşturucu aracılığıyla tutulması.

Ham performansla ilgili olarak, "Node.js Rust'tan daha mı yavaş?" sorusu başlı başına bir konudur - Rust ve Node.js gecikmesi hakkındaki makalemiz bu konuyu ayrıntılı olarak ele alır ve metodoloji kıyaslama metodolojisi sayfamızdayukarıda açıklanmıştır. Özel bir API, halihazırda kullanmakta olduğunuz herhangi bir HTTP hizmetiyle aynı performans profiline sahiptir; yapısı gereği ne daha iyi ne de daha kötüdür. PostgREST'in tam olarak nerede doyduğunu ve hangi noktada özel bir katmanın gerekli hale geldiğini bilmek için PostgREST'in üretimdeki gerçek sınırlarıhakkındaki makalemize bakın.

Mimarinin ötesinde, seçim yaparken sıklıkla dört kriter ortaya çıkıyor: uygulama hızı, gerçek iş esnekliği, uzun vadeli teknik borç ve her seçeneğin en rahat olduğu tipik kullanım durumu.

Bir Aurabase Postgres motoru projesinde CRUD katmanı, yaklaşık bir yeniden uygulama değil, gerçek bir PostgREST örneği tarafından zaten kapsanmaktadır. Bu karşılaştırma için açık kalan soru şu: CRUD'un ötesine geçenler nereye yazılmalı?

İki yol vardır ve bunlar birbirini dışlamaz. Birincisi: SQL'de ifade edilmesi makul olan herhangi bir mantık için RPC'de kullanıma sunulan bir SQL işlevi - toplamın hesaplanması, birkaç tablo arasında çapraz doğrulama, tek bir işlemde güncellemelerin basamaklandırılması.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

İkinci yol: SQL alanının ötesine geçen her şey için Edge İşlevleri - ödeme API'sinin çağrılması, e-posta gönderilmesi, yerleştirmenin hesaplanması. Aurabase'de iki yol var: Deno (TypeScript) kodunu tam olarak Supabase'de çalıştıran Studio editörü ve Rust'ta yazılan ve WASM'de derlenen işlevler için ayrı bir yol hedefleyen aura functions deployCLI — birleşik Rust mimarimizdeayrıntılı olarak açıklanmıştır. Bu makaledeki sunucunun tamamen sizin sorumluluğunuzda olduğu saf "özel API" seçeneğinin aksine, her iki yol da ayrı bir Node sunucusunun barındırılmasını gerektirmez.

Bu dağıtım, burada karşılaştırılan üç model arasında sallantılı bir uzlaşma değildir: Kelimenin tam anlamıyla CRUD için PostgREST, RPC ve tetikleyiciler aracılığıyla olay mantığı için Hasura Eylemlerine yakın bir tuğla ve "tümü PostgREST" ve "tümü özel" arasında ikili bir seçim yapmaya zorlamadan tam bir uygulama sunucusunun çalışmasını önleyen Edge İşlevleridir.

En sık dört durum ortaya çıkar. Doğru seçim çoğunlukla bir aracın popülerliğine değil, iş mantığınızın neye ihtiyaç duyduğuna bağlıdır.

• Şemanız kararlı ve iş mantığınız SQL'de. Kendi kendine barındırılan PostgREST veya yerel olarak entegre edilmiş (Aurabase, Supabase) yeterlidir: barındırılacak başka bir şey yoktur ve şema gerçeğin tek kaynağı olmaya devam eder.
• Birkaç veri kaynağını bir araya getirmek istiyorsunuz veya yol haritanız, verilerinizi tüketen yapay zeka aracılarına yönelik. Hasura, PromptQL katmanıyla bu duruma daha iyi uyum sağlıyor.
• Ürününüz zengin iş mantığına, çok sayıda üçüncü taraf entegrasyonuna ve halihazırda bir uygulama diliyle donatılmış bir ekibe sahiptir. Özel bir API, yazılması ve zaman içinde bakımının yapılması pahasına en doğrudan seçim olmaya devam etmektedir.
• İş mantığı (RPC, Edge Functions) için gerçek alandan vazgeçmeden, istismar edilecek bir uygulama hizmeti daha istiflemeden, kendi kendine oluşturulan CRUD istiyorsunuz. Bu, önceki bölümde Aurabase'e uygulanan bu karşılaştırmada belgelenen açıdır.