Vercel'in Workflow SDK'sı ve Polign'in tipli bellek veritabanı, ikisi de stateful sunucuları devre dışı bırakıyor

Birkaç gün arayla yayımlanan iki mühendislik yazısı — Vercel'in dayanıklı iş akışı orkestrasyonu hakkındaki blog yazısı ve Hacker News'in ana sayfasına çıkan Polign tasarım notu — zıt yönlerden aynı sonuca varıyor: dayanıklılık, işletmeniz gereken başka bir stateful sistemde değil, kütüphanelerde ve düz depolamada olmalı.

Sıradan async kod olarak iş akışları

Vercel bloguna göre yazar, Temporal'a serverless bir geliştirici deneyimi kazandırmak için hafta sonları yaklaşık altı ay boyunca fork üzerinde çalıştı, sonra fork'u bıraktı, Vercel'e katıldı ve Nathan Rajlich ile birlikte yeni bir framework olan Workflow SDK'yı geliştirdi. Temel argüman şu: bir iş akışı yönlü çevrimsiz bir graftır ve kaynak kodu zaten öyle bir şeydir; soyut sözdizimi ağacı sıralamayı, dallanmayı ve paralelliği kodlar; bu yüzden grafiği elle çizmenizi gerektiren framework'ler — tipik örnek Apache Airflow — mantığınızı düğümlerin içine gömer.

Yazı, Temporal'ı çalıştırmanın gerçekte ne gerektirdiği konusunda açık sözlü: frontend, history, matching ve worker servislerini Cassandra, Postgres veya MySQL üzerinde ayağa kaldırmak; kendi polling worker filonuzu işletmek — pratikte bir Kubernetes kümesi — mutual TLS ve payload şifrelemesini yapılandırmak; ve devam eden çalıştırmalar sırasında kodu patching API'si (patched() ve GetVersion) aracılığıyla evrimleştirmek; yazarın işe yarar ama sürüm bayrakları biriktikçe yıpratıcı bulduğu bir süreç. Sinyaller, sorgular ve güncellemeler — canlı bir çalıştırmayla etkileşim için üç ayrı primitive — yazarın kendi ifadesiyle, bir tahta olmadan açıklanması imkânsızdı.

Workflow SDK'nın cevabı sıradan TypeScript'ten tek bir dosya. "use workflow" direktifi orkestratörü işaret eder, "use step" tam Node.js erişimine sahip yan etkili bir iş birimini işaret eder ve aradaki her şey await, try/catch, Promise.all ve döngülerdir. Adımlardaki yakalanmayan hatalar varsayılan olarak yeniden denenir; FatalError bir çalıştırmayı durdurur, RetryableError geri çekilmeyi özelleştirir ve maxRetries ayarı sayıyı ayarlar. Üç Temporal primitive'i tek bir şeye, hook'a daralır: createHook() veri gelene kadar çalıştırmayı askıya alır ve createWebhook() bunu gerçekten çağrılabilir bir URL olarak ortaya çıkarır — bir onay iş akışını saniyelerce veya haftalarca duraklatmak için, dağıtılacak ek bir şey olmadan yeterli.

Mimari açıdan framework, sunucu tarafındaki tek bağımlılığı Postgres olan açık kaynaklı bir dayanıklı yürütme kütüphanesi olan DBOS'u modele kaynak gösteriyor. Workflow SDK bir platform değil kütüphanedir: runtime, depolama, kuyruklama, kimlik doğrulama ve akışı kapsayan tek bir arayüzle, World ile konuşur; böylece Postgres, Redis, Kafka, SQS, Cloudflare Queues, Turso veya Durable Objects, iş akışı koduna dokunmadan farklı katmanları destekleyebilir. Yazıya göre Vercel'in kendi Workflow Server'ı bile hiçbir orkestrasyon yapmayan, herhangi bir Vercel uygulaması gibi dağıtılan stateless bir CRUD API'si.

Object storage'da yaşayan tipli bir bellek deposu

Polign'den Anup Talwalkar tarafından yazılan ve Show HN gönderisi olarak paylaşılan ikinci yazı, agent belleğini iki açıdan ele alıyor: nasıl temsil edildiği ve nerede yaşadığı. Eski bir Google Cloud Storage çalışanı olan Talwalkar, tanıdık hata biçimlerine dikkat çekiyor — bir bilgiyi düzeltiyorsunuz ve agent bir hafta sonra eski sürümü alıntılıyor; bir tercihi değiştiriyorsunuz ve retrieval her iki kopyayı da geri getiriyor. Bugün model bu çatışmaları eski metni yeniden okuyarak çözüyor; bu da token ve doğruluk maliyeti demek. Onun çözümü kararı şemaya taşımak: modelin bir bilgiyi çıkardığı ve veritabanının, supersession kuralları aracılığıyla, o bilginin ne anlama geldiğini belirlediği tipli bir depo.

Claude modellerine varsayılanlanan ve OpenAI modellerini de kabul eden açık kaynaklı CLI demosunda, günlük adım hedefinin 8.000'i aşıp aşmadığını sormak, depolanmış 9.000 değerini geri getiren filtrelenmiş bir recall'a dönüşüyor. Karşılaştırma veritabanında çalışıyor; model sayıları karşılaştırmak için paragraf ayrıştırmıyor. Yerel bir embedding modeli üzerinden anlamsal recall, yapılandırılmış filtrelerin yanında duruyor.

Konum argümanı, bulut ölçeğinde sıcak, çoğaltılmış vektör indekslerinin operasyonel maliyetini izlemekten geliyor. polign_db, dayanıklı durumu tamamen bir object store'da yaşayan, hibrit vektör artı BM25 motoru üzerinde tipli bir veritabanı; sunucu hiçbir şey tutmuyor, bu yüzden süreçler ölebilir ve bellek sağlamken yeniden başlayabilir; yazar sorgu maliyetlerinin corpus büyüklüğüyle artmadığını iddia ediyor. Bir Wikipedia demosu 12,5 milyon pasajı S3'ten sunuyor ve sunucu yaklaşık 37 MiB RSS ile boşta bekliyor; 2 GB'lık bir ARM makinesine sığıyor. Benimseyenler için bir uyarı: demo açık kaynaklı ama polign_db'nin kendisi kapalı kaynaklı; indirilmesi ücretsiz ama incelenemiyor.

Neden önemli

Her iki yazı da aynı gizli vergiye saldırıyor: stateful middleware. Vercel'in bahsi, dayanıklı yürütmenin bir derleyici artı bir kütüphane olabileceği ve alt katmanın ekiplerin zaten işlettiği depolama ve kuyruklara indirilebileceği yönünde — Temporal'ın operasyonel kapsamını fazla ağır bulan herkes için anlamlı bir sadeleşme, ancak framework yeni ve ölçekte henüz kanıtlanmış değil. Polign'in bahsi, agent belleğinin deterministik, tipli ve soğuk-öncelikli olabileceği yönünde; bu, agent'lar edge donanımına doğru ilerledikçe ve modellerin kendi recall'larını gözle görülür biçimde kötü yönettikleri ortaya çıktıkça önem taşıyor. İkisi de henüz doğrulanmış değil ve Polign yığınının yarısı tescilli, ama birlikte bir yön çiziyorlar: işletilecek daha az orkestratör ve sıkıcı, değiştirilebilir depolamaya itilen daha fazla zekâ.