2 puan yazan GN⁺ 2024-08-13 | 1 yorum | WhatsApp'ta paylaş
  • Yerel öncelikli uygulamalarda ve tarayıcı tabanlı geliştirme ortamlarında tam Postgres’i WASM ile doğrudan çalıştırarak sunucu bağımlılığını azaltabilir
  • Gzip’e göre 3 MB’tan küçük bir derleme olarak sunulduğu için tarayıcı ve yerel ortamlara gömülmesi kolay bir yapıdadır
  • Dinamik eklenti yükleme sayesinde pgvector ve PostGIS gibi Postgres eklentileri kullanılabilir
  • Veri yükleme, senkronizasyon ve canlı sorgu primitive’lerini yerleşik olarak sunarak reaktif uygulamalara ve gerçek zamanlı kullanım senaryolarına uygundur
  • Supabase’in database.build hizmeti, PGlite temelinde yapay zekadan yararlanarak Postgres veritabanları oluşturma ve yayımlama deneyimi sunar

Tarayıcıda ve yerelde kullanılan Postgres

  • PGlite, WASM üzerinde tam Postgres veritabanını yerelde çalıştıran gömülebilir bir Postgres’tir
  • Tam bir Postgres WASM derlemesidir ve Gzip sıkıştırmasına göre 3 MB’tan küçük olarak sunulur
  • Veri yükleme, senkronizasyon ve canlı sorgu primitive’lerini yerleşik olarak sunarak istemci odaklı reaktif veri akışları oluşturmayı sağlar

Eklentiler ve deneme ortamı

  • Dinamik eklenti yükleme mekanizmasını destekler
    • pgvector dahildir
    • PostGIS de kullanılabilir
  • Playground üzerinden daha fazla eklenti denenebilir
  • Mevcut sayfada tarayıcı içinde çalışan tam PGlite Postgres doğrudan denenebilir; pgvector da dahildir

Belgeler ve dağıtım kanalları

  • Başlangıç belgeleri Get Started üzerinden incelenebilir
  • GitHub 15,5 bin yıldız gösteriyor
  • NPM haftalık 10,1 milyon indirme gösteriyor

Supabase’in database.build hizmeti

  • database.build, Supabase’in PGlite temelinde oluşturduğu bir hizmettir
  • Yapay zeka ile Postgres veritabanı oluşturma ve yayımlama akışı sunar

1 yorum

 
GN⁺ 2024-08-13
Hacker News yorumları
  • Daha önce tarayıcıda çalıştığını görmüştüm ve bunun yaklaşık 3MB indirmeyle mümkün olması etkileyiciydi; ancak Node.js ve Bun’ın sunucu tarafında da çalıştığını kaçırmışım: https://pglite.dev/docs/
    Gerçek bir ağ sunucusu başlatmadığı için SQLite’a bir alternatif gibi hissettiriyor; mevcut bir Node.js/Bun uygulamasının içinde, diske kalıcı yazabilen işlem içi PostgreSQL uygulamasını doğrudan başlatabilmek ilginç
    Python’da da https://github.com/wasmerio/wasmer-python veya https://github.com/bytecodealliance/wasmtime-py gibi sarmalayıcılarla denemek isterdim; PGlite’ı bu şekilde çalıştırmayı deneyen biri var mı merak ediyorum

    • PGlite’ın diğer dillerde iyi çalışmasını sağlamak çok yüksek öncelikli
      Üzerinde çalışılan iki yaklaşım var: biri kullanıcıların yüksek seviyeli bir API ile sarabileceği düşük seviyeli API’nin WASI derlemesi, diğeri ise yerel dillerden linklenebilecek libpglite
      Çoğu dilde zaten Postgres wire protocol uygulaması bulunduğundan, bunu okuyup yazan düşük seviyeli API’yi sarmak nispeten kolay; PGlite’ın JS tarafı da aynı şekilde çalışıyor
    • Geçici bir çözüm olarak Python’da subprocess ile bir Node.js betiği çağırıp @electric-sql/pglite içindeki exec ve query’yi çalıştırmak, sonuçları da JSON olarak alıp vermek mümkün görünüyor
      Yapı şu şekilde: db.js içinde bir PGlite örneği oluşturuluyor, komut satırı argümanlarıyla SQL ve parametreler alınıp işleniyor; main.py içinden de node db.js exec ... veya node db.js query ... çağrılıyor
    • Python’da da PGlite kullanmak istiyorum; bu başlığı okurken Pyodide üzerinden zaten erişilebildiğini fark ettim
      Pyodide, CPython’ın Wasm portu ve proxy’ler aracılığıyla JavaScript nesneleriyle etkileşime girebiliyor
      Örnek olarak globalThis.db = new PGlite() oluşturulmuş, ardından Python kodunda js.db.query() için await edilerek SELECT 'Hello, world!' AS "greeting"; çalıştırılmış; şu anda Node.js 18, Deno 1, Bun 1 üzerinde çalışmış
    • Lisanslara daha aşina biri bunun ticari projeler veya çözümler üzerinde nasıl bir etkisi olacağını, embedded FirebirdSQL gibi şeylerle nasıl karşılaştırıldığını açıklarsa iyi olur
      Örneğin kaynak kodu açmadan ticari bir projede kullanılıp kullanılamayacağını, gömülü kullanıldığında lisansı pg/fb’ye uyacak şekilde değiştirmek gerekip gerekmediğini merak ediyorum
      Hemen ihtiyaç duysam kendim incelerdim; ama SQLite’ın sadeliğinde hoşuma gitmeyen noktalar MySQL/MariaDB’de sevmediğim noktalarla epey benzeştiği için meraklandım
    • Gerçekte ne kadar iyi çalışacağı ilginç
      PostgreSQL’in kalıcılık katmanını nasıl değiştirdiler bilmiyorum; ancak Docker konteynerinde PostgreSQL çalıştırmakla karşılaştırıldığında bazı sınırlamaları olabilir gibi görünüyor
      SQLite’ta böyle sınırlamalar yok
  • PGlite’ı gerçekten seviyorum
    Docker olmadan Postgres sahibi olmak için mükemmel bir çözüm; yalnızca npm install ile yerel bilgisayarda bir Postgres örneği oluşturulabildiği için yeni geliştiricileri ekibe dahil etmek çok kolaylaşıyor
    Next.js ile de iyi çalışıyor; yerel ve geliştirme ortamlarında Next.js Boilerplate ile birlikte kullanıyorum: https://github.com/ixartz/Next-js-Boilerplate
    Tek bir npm install ile veritabanı dahil tam yığın bir uygulama, yani çalışan bir Postgres hazır oluyor ve harici araç kurulumu gerekmiyor

    • Geliştirme bağımlılıklarını genelde docker compose ile yönetirim, ama bu kesinlikle harika bir alternatif gibi görünüyor
  • Sonraki kişinin bizzat aramasına veya sormasına gerek kalmasın diye bırakayım: tarayıcı tarafı kalıcılık IndexedDB ve OPFS destekliyor: <https://pglite.dev/docs/filesystems>

    • WASM SQLite VFS üzerindeki senin ve Roy’un çalışması bu çalışmayı doğrudan etkiledi
  • Başlığı görür görmez “bu ElectricSQL ile gerçekten çok iyi gider” diye düşündüm; gerçekten ElectricSQL tarafından çıkmış olduğunu görmek güzel
    Anında sunduğu geliştirici deneyimi harika; PGlite ve ElectricSQL’i prodüksiyon projelerinde denemek istiyorum
    Şu anda yaşadığım birçok sıkıntıyı azaltacak gibi görünüyor; kişisel olarak CRDT ile çalışmayı da seviyorum

  • Show HN için tebrikler
    ElectricSQL Discord sunucusunu takip ediyordum ve özellikle TypeScript dışındaki dillerde kullanımına ilgi duyuyordum; dil bağımsızlığını önceliklendirdiğinizi duymak sevindirici
    ElectricSQL’in mimari değişiklik nedeniyle yeniden yazıldığını görmüştüm; bunun PGlite’ı etkileyip etkilemediğini, yoksa artık ayrı bir proje mi olduğunu merak ediyorum
    Ayrıca SQLite aslında SQL-ite, yani urbanite gibi -ite ailesinden; ama yeniden ayrıştırma ve libfixing nedeniyle insanlar artık bunu -lite son eki gibi kullanıyor gibi görünüyor
    Bunun nedeni liteın anlamının daha belirgin, iteın ise öyle olmaması olabilir; helicopter’ın aslında helic + opter iken insanların bunu heli + copter olarak algılayıp helipad veya quadcopter gibi kelimelerin ortaya çıkmasına benziyor
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite ve Electric sync ayrı projeler, ancak PGlite’ı Electric’in senkronizasyon hedeflerinden biri hâline getiriyoruz
      Electric tarafındaki değişiklik, önceki sıkı entegre yığından daha gevşek bağlı bir yığına geçiş yönünde
      PGlite, Electric sync’in olası istemci depolarından biri; istemcide tam bir SQL veritabanı bulundurma ve istemci ile sunucuda aynı şemayı kullanabilme gibi kullanım senaryolarını karşılıyor
      İsim doğal olarak SQLite’a bir saygı duruşu; küçük l ise biraz farklılaşma ve “light”a bir gönderme için eklendi, ayrıca hafif Postgres anlamını da taşıyor
  • Normalde PostgreSQL ile SQLite arasındaki temel farkın SQLite’ın in-process olması olduğunu söylerdim; ama artık ikisi de in-process olabiliyorsa, ikisini daha ayrıntılı karşılaştıran bir kaynak var mı merak ediyorum
    Hangi durumlarda birini diğerine tercih etmek gerekir?

    • SQLite gerçekten çok uzun süredir kendini kanıtlamış durumda; ama PGlite’ı 3 dakika bile kurcalamadan memory access out of bounds hatasıyla karşılaştım
      Ağabeyi PostgreSQL en sağlam veritabanlarından biri olsa da, bunun henüz üretime hazır olduğunu söylemek zor olabilir
      Elbette SQLite’ta da sorunlar gördüm ve yaşadım; hatasız yazılım yok
    • Bu karşılaştırmayı gerçekten öğrenmek istiyorum
  • Yakın zamanda bir yan projede API entegrasyon testleri için pglite kullandım ve oldukça iyi çalıştı
    Docker’da postgres ayağa kaldırmak için testcontainers[0] gibi bir şey kullanmaya kıyasla geliştirici deneyimi çok daha iyiydi
    [0]: https://testcontainers.com

    • Birim testleri ve entegrasyon testleri PGlite için çok büyük bir fırsat bence
      Drizzle ORM gibi projeler bunu şimdiden iyi kullanıyor
      Supabase ekibi pg-gateway’i (https://github.com/supabase-community/pg-gateway) geliştirdi; bu sayede herhangi bir Postgres istemcisinden PGlite’a bağlanmak mümkün, CI’da kullanım için bir yol olabilir
      Keşfetmek istediğim şey PGlite için yazarken kopyala sayfa düzeyi VFS
      İçinde veri kümesi bulunan bir PGlite başlatıp her test için veritabanını anında fork edebilseydik, devcontainers veya Postgres şablon veritabanlarının karmaşıklığı olmadan test başına milisaniyenin altında fork mümkün olurdu gibi geliyor
    • Bunu Go’da da bu şekilde kullanmak isterim
      Şu anda üretimde postgres kullanıyoruz, ancak SQLite tabanlı entegrasyon testleri için SQLite uyumlu bir şema döküyoruz
      Bu sayede gerçek veritabanını kullanırken bile bağımlılıksız, 1 saniyenin altında entegrasyon testleri mümkün oluyor
      Postgres’i olduğu gibi kullanabilsek, tam metin arama gibi PG’ye özgü özellikler gerektiren işlevleri de test edebileceğimiz için daha iyi olurdu
  • PGlite / ElectricSQL, gelecekteki bir iş yerinde mutlaka denemek istediğim bir teknoloji
    Tarayıcı içinde değişiklikleri çoğaltma ve bunlara abone olma yeteneği son derece güçlü görünüyor
    Eskiden 2 milyondan fazla hastanın iş yükünü yöneten, kemoterapi/HIV/bağışıklıkla ilgili ilaç yenilemeleri yapan sağlık yazılımı geliştirmiştim; sigorta işlemleri veya hasta görüşmeleri sırasında insanların birbirinin yaptığı işi ezmesi yaygındı
    IE7 yüzünden interval fonksiyonlarına ve WebSocket’lere dayanan kendi kilitleme sistemimizi yapmak zorunda kalmıştık; biri hastayı ararken mali destek sorumlusu aynı profil üzerinde çalışamıyordu
    Büyük ölçekte çok maliyetli olan tam metin arama veya vektör aramayı da yerelde kullanmak mümkün olabilir gibi görünüyor

    • Bu, 2 milyon hastanın verisini tüm cihazlara koymak anlamına gelir
      Sağlık yazılımı için çok kötü bir tercih
  • Buna benzer bir native sürüm olup olmadığını merak ediyorum
    İleride native uygulama yapmak istediğimde mimariyi tamamen çöpe atıp baştan başlamamayı sağlayacak bir biçimde olmasını isterdim
    Web sitesinde ve belgelerde yalnızca WASM sürümü görünüyor

    • Planlanıyor
      Postgres’e uygulamamız gereken çekirdek değişiklikleri çıkarıp, herhangi bir dil/platformdan linklenebilecek bir libpglite C kütüphanesi yapmak istiyoruz
      React Native’de WASM desteği olmadığı için bu destek önemli
  • Reaktif live query API olması çok güzel
    Reaktif sorgu örneklerinin çoğu tek tablo gibi oldukça temel; live query’nin join veya aggregation destekleyip desteklemediğini merak ediyorum

    • Hepsinin çalışması gerekir
      Sorguyu bir view olarak kaydedip hangi tablolara bağımlı olduğunu içeriden inceliyoruz
      Ardından değişiklikleri izlemek için pg_notify kullanıyoruz
      Daha verimli hâle getirmek için pg_ivm’yi (https://github.com/sraoss/pg_ivm) entegre etmeyi planlıyoruz