HN पर रिलीज़: Triplit - सर्वर और क्लाइंट पर चलने वाला open source sync database

 (github.com/aspen-cloud)
2 पॉइंट द्वारा GN⁺ 2024-06-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Triplit एक open source database है जो server और browser के बीच data को real-time में sync करता है, और खुद को ऐसा full-stack database बताता है जिसे ऐप में Typescript package के रूप में जोड़कर इस्तेमाल किया जा सकता है
  • यह server storage और client query synchronization दोनों को संभालता है, और incremental updates, attribute-level conflict resolution, local caching, offline mode, और automatic reconnection को support करता है
  • SQLite, IndexedDB, LevelDB, Memory जैसे pluggable storage को support करता है, और server-side persistent storage तथा admin dashboard प्रदान करता है
  • React और vanilla Javascript में query और mutation API इस्तेमाल किए जा सकते हैं, और यह React/Svelte bindings, CLI, Console, Server आदि से बने monorepo के रूप में उपलब्ध है
  • तेज़ interaction के लिए optimistic updates, failed updates का rollback/retry, server-enforced read/write permissions, और CRDT-based collaboration features भी प्रदान करता है

Triplit क्या प्रदान करता है

  • Triplit एक open source database है जो server और browser के बीच data को real-time sync करता है
  • यह ऐप में Typescript package के रूप में जोड़ा जा सकने वाला sync data store प्रदान करता है
  • यह data को server पर store करता है और client की queries को intelligently sync करता है
  • Triplit इस तरह के रूप को full-stack database कहता है
    • Local First community presentation video भी उपलब्ध है: presentation

मुख्य features

  • Real-time sync

    • Incremental updates को support करता है
    • Attribute-level conflict resolution प्रदान करता है

  • Local-first usability

    • पूरी client-side database-आधारित local caching प्रदान करता है
    • Optimistic updates के जरिए सभी interactions को तेज़ महसूस कराता है
    • Offline mode, automatic reconnection, और consistency guarantees को support करता है

  • Server storage और operations

    • Server-side persistent storage प्रदान करता है
    • Admin dashboard शामिल करता है
    • SQLite, IndexedDB, LevelDB, Memory आदि pluggable storage providers को support करता है

  • Data model और API

    • Complex data models के लिए relational queries को support करता है
    • Schema के जरिए data safety और Typescript autocomplete प्रदान करता है
    • vanilla Javascript और React में queries और mutations के लिए simple API प्रदान करता है

  • Collaboration और security

    • Server पर read और write दोनों के लिए permissions enforce करता है
    • CRDTs आधारित collaboration/multiplayer features प्रदान करता है
    • Delta patches का उपयोग करके network traffic घटाता है और low latency को लक्ष्य बनाता है
    • Failed updates के लिए rollback और retry को manage करता है

Monorepo संरचना

  • TriplitDB: Browser, Node, Deno, React Native आदि JS environments में चलने के लिए design किया गया DB, जो network पर multiple writers के साथ consistency बनाए रखते हुए तेज़ और live-updating queries प्रदान करता है
  • Client: Local और remote TriplitDB के साथ interact करने वाली browser library
  • CLI: Project scaffolding, full-stack development environment चलाने, server migrations आदि के लिए command-line tool
  • React: @triplit/client के लिए React bindings
  • Svelte: @triplit/client के लिए Svelte bindings
  • Console: Triplit project data देखने और बदलने, तथा schema manage करने वाला app
  • Server: Triplit clients के बीच data sync करने वाला Node server
  • Server-core: Triplit server बनाने के लिए protocol-independent library
  • Docs: Nextra से बने Triplit docs
  • Types: Triplit projects द्वारा share किए जाने वाले types
  • UI: shadcn आधारित shared UI components

Quick start flow

  • नया project npm create triplit-app@latest my-app से शुरू करें
  • मौजूदा project में @triplit/cli को development dependency के रूप में install करने के बाद npm run triplit init चलाएं
  • my-app/triplit/schema.ts में schema define करें
    • उदाहरण में todos collection में id, text, completed fields define किए गए हैं
    • completed को default value false वाले Boolean field के रूप में set किया गया है
  • npm run triplit dev से development के लिए sync server शुरू करें
  • Development server वे environment variables output करता है जो ऐप को server के साथ sync करने के लिए चाहिए
    • Vite example में VITE_TRIPLIT_SERVER_URL=http://localhost:6543
    • VITE_TRIPLIT_TOKEN=copied-in-from-triplit-dev

React usage example और sync verification

  • React example TriplitClient और useQuery का उपयोग करता है
  • Client schema, server URL, और token लेकर बनाया जाता है
  • useQuery(client.query('todos')) से todos query result को subscribe किया जाता है
  • Checkbox बदलने पर client.update से completed value को invert किया जाता है
  • ऐप शुरू करने के बाद दूसरा browser tab खोलने पर data का real-time sync होना देखा जा सकता है

Docs और contact channels

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-27
Hacker News की राय

  • मैंने Triplit को अपने प्रोजेक्ट https://github.com/thanhnguyen2187/cryptaa में इस्तेमाल करके देखा, और यह उम्मीद के मुताबिक काम किया
    इसका डेटा मॉडल किसी एक central DB को source of truth मानने के बजाय ज़्यादा distributed/P2P जैसे विचारों के साथ अच्छी तरह फिट बैठता है, लेकिन self-hosting और query language में कमी महसूस हुई
    server auth token बनाने का तरीका docs में साफ़ नहीं था, इसलिए मैंने CLI के dev command से token बनाया, और system service में token का plain-text logs में रह जाना security के लिहाज़ से अच्छा नहीं है, हालांकि मुझे लगता है कि इसके लिए पहले से ज़्यादा बड़े access-permission issue का होना ज़रूरी है
    custom query DSL में SQL की तरह UNIQUE, COUNT जैसी expressiveness नहीं है, इसलिए कुछ aggregations खुद करने पड़ते हैं
    हाल ही में Evolu https://www.evolu.dev/docs देखा, और scope व features काफ़ी मिलते-जुलते लगते हैं; Triplit में .subscribe() है और Evolu में नहीं, Evolu Kysely-based typed SQL है इसलिए queries ज़्यादा परिचित और advanced लगती हैं, और browser में Evolu OPFS पर SQLite इस्तेमाल करता है जबकि Triplit शायद IndexedDB इस्तेमाल करता है
    Reddit पर डाली गई पोस्ट: https://www.reddit.com/r/sveltejs/comments/1dndpj8/cryptaa_a...

    • self-hosting docs को setup और साफ़ बनाने के लिए व्यवस्थित किया जा रहा है, और आपकी बताई बात मददगार है
      query वाले हिस्से में अभी aggregation नहीं है, लेकिन यह roadmap में है, और मुझे लगता है कि incremental query engine का लाभ उठाकर इसे बढ़िया दिशा में ले जाया जा सकता है
      उदाहरण के लिए, हर घंटे refresh होने वाले data dashboard में मौजूदा systems (Postgres, MongoDB आदि) में हर बार query को शुरुआत से फिर चलाना पड़ता है, लेकिन Materialize जैसी approach से सिर्फ़ नया data process किया जाए तो यह लगातार update होने में कहीं ज़्यादा efficient हो सकता है
      Evolu को अभी खुद इस्तेमाल करके नहीं देखा है, लेकिन Discord पर तुलना कर चुके लोग हो सकते हैं: https://triplit.dev/discord
    • Evolu बताने के लिए धन्यवाद, और Triplit और Evolu दोनों दिलचस्प लगते हैं, इसलिए दोनों की तुलना देखना चाहूंगा
    • Evolu भी useQuery या अलग तरीके से subscribe support करता है

  • ऐसे शानदार offline sync protocol वाले DB का इस्तेमाल करते समय, जब अलग-अलग client versions को एक साथ upgrade नहीं किया जा सकता, तो schema evolution कैसे handle किया जाता है, यह जानना चाहूंगा
    पहले एक mobile health app में इसी समस्या से जूझने का संदर्भ है

    • बेहतर है कि सिर्फ़ नए tables बनाए जाएं और मौजूदा tables में compatibility तोड़ने वाले बदलाव न किए जाएं
      ज़रूरत पड़ने पर दोनों versions में साथ-साथ लिखने के लिए dual write करना पड़ता है
      यह SQL DB में compatibility तोड़ने वाले बदलाव को zero-downtime live migration करने जैसा है, लेकिन cutover का समय customer के हाथ में होने से वह logic ज़्यादा लंबे समय तक बनाए रखना पड़ता है
      latest version coordinate करने वाली table भी अहम है, और अगर breaking change हो तो पीछे रह गए clients को user से upgrade करने के लिए कहना चाहिए
      सभी clients में supported minimum version से जोड़कर यह भी तय किया जा सकता है कि dual read/write कितने समय तक बनाए रखना है
    • संक्षेप में कहें तो schema की backward compatibility बनाए रखना compatibility सुनिश्चित करने का सबसे आसान तरीका है
      Triplit backward-compatible न होने वाला बदलाव करने पर warning दिखाता है, और इसे docs में देखा जा सकता है: https://www.triplit.dev/docs/schemas/updating#pushing-the-sc...
      हालांकि समय के साथ भ्रमित करने वाले नामों वाली messy schema definition स्वाभाविक रूप से बन सकती है
      इसे ठीक करने वाला solution अभी release नहीं किया है, लेकिन इसे कम painful बनाने के लिए कुछ चीज़ों पर काम चल रहा है, और कई approaches की background के लिए Cambria doc शानदार है: https://www.inkandswitch.com/cambria/
    • मुझे लगता है कि कुछ clients, जैसे server, को बहुत पुराने schema के साथ भी sync कर पाना चाहिए
      हो सकता है user ने phone को 2 साल तक drawer में रखा हो, इसलिए हर client को जितनी जल्दी हो सके खुद को migrate कर लेना चाहिए
    • अगर past migrations को define और support करने का built-in तरीका हो, तो यह killer feature हो सकता है
      इससे हर किसी को अपना migration management तरीका नए सिरे से बनाने की ज़रूरत नहीं पड़ेगी

  • मुझे समझ नहीं आता कि client का सीधे DB में लिख पाना किन apps में ठीक है, और backend logic के बिना यह कैसे टिक सकता है
    Supabase और Firestore को लेकर भी यही सवाल है, शायद मैं कुछ miss कर रहा हूं

    • real world में बनने वाली ज़्यादातर चीज़ों में business logic बहुत कम होता है और वे बस CRUD जैसी होती हैं
      enterprise environment में जाहिर है उल्टा होता है, और इसे नज़रअंदाज़ करने वाली चर्चा देखकर झुंझलाहट होती है
      खासकर tech Twitter पर जब किसी खास stack या काम करने के तरीके के पक्ष में बातें दिखती हैं, तो यह बहुत साफ़ होता है कि उन्होंने business systems बनाए ही नहीं, सिर्फ़ CRUD बनाया है, और उन्हें समझ नहीं आता कि experienced developers सहमत क्यों नहीं होते
    • मैंने Firebase से collaborative app बनाया था, और अगर हर व्यक्ति को अपने comments या cards पर किए जा सकने वाले कामों पर कड़ी सीमा लगाई जाए और सिर्फ़ खास operation permissions दी जाएं, तो यह किसी तरह काम कर जाता है
      backend logic ज़्यादा होने वाली चीज़ों के लिए यह अच्छा fit नहीं लगता
    • दोनों में backend द्वारा enforce किया गया access control होता है, इसलिए ऐसा नहीं है कि backend logic बिल्कुल नहीं है
      Supabase में, उदाहरण के लिए, row-level security नाम का feature है
      client Supabase को request भेज सकता है, लेकिन Supabase backend पर additional query चलाकर तय करता है कि आई हुई request allowed है या नहीं
      एक सरल उदाहरण के तौर पर, सिर्फ़ तभी उस row को read, write और update करने दिया जा सकता है जब UserID column की value request करने वाले authenticated user के समान हो

  • यूज़र settings को Triplit में सेव किया जा रहा था, और इन्हें admin द्वारा manage किया जा सकना ज़रूरी था
    यूज़र को यह महसूस होना चाहिए था कि app हमेशा local पर ही चल रहा है, और internet quality भी अक्सर अच्छी नहीं होती थी, लेकिन कई devices के बीच switch करके इस्तेमाल करना था और admins को दूसरे users की settings देखनी और manage करनी थी, इसलिए sync की ज़रूरत थी
    कुल मिलाकर Triplit का frontend developer experience और support दोनों शानदार थे, और issue या feature request आने पर team उसे बहुत तेज़ी से handle करती है
    high-availability deployment पर जवाब मिलते ही, Postgres की जगह और ज़्यादा important data भी migrate करने का plan है

  • उत्सुकता है कि AGPL license क्यों चुना गया

    • वे चाहते थे कि AGPL license के साथ Triplit को आसानी से self-host किया जा सके, और जिसने भी modifications किए हों वह उन changes को community में वापस contribute करे, यह सुनिश्चित हो
    • अगर इस्तेमाल किए जाने वाले DB की वजह से product को भी AGPL बनाना पड़े, तो उससे बचना चाहेंगे

  • Local First Discord server https://localfirstweb.dev/ में YouTube presentations https://www.youtube.com/playlist?list=PLTbD2QA-VMnXFsLbuPGz1... देखी थीं शायद, इसलिए Show HN में इसे देखकर अच्छा लगा
    TypeScript न इस्तेमाल करने की वजह से शायद मैं इसका main target नहीं हूं, और web के उलट unstable connectivity वाले mobile apps में मुख्य रूप से local-first approach इस्तेमाल करता हूं, Flutter और Rust backend के साथ
    ElectricSQL और PowerSync जैसे दूसरे local-first solutions client और server DB को सीधे sync करते हैं, इसलिए वे client/server से ज़्यादा independent हैं
    CRDT-based solutions भी FFI के जरिए client और server पर इस्तेमाल किए जा सकते हैं; उदाहरण के लिए automerge Rust में है, इसलिए Flutter side पर flutter_rust_bridge के जरिए FFI, web पर WASM, और backend पर Rust के रूप में इस्तेमाल किया जा सकता है
    Triplit अलग-अलग clients के बीच conflict-free resolution की बजाय server को source of truth मानने वाले ज़्यादा traditional client-server sync जैसा लगता है
    उत्सुकता है कि client और server से ज़्यादा independent DB-layer approach के बजाय language-level solution क्यों चुना गया, और आगे JS-based languages/frameworks के अलावा support देना मुश्किल दिखता है
    साथ ही ऐसा लगता है कि यह Supabase से compete करना चाहता है, लेकिन Supabase भी Postgres के DB-level sync और CRDTs पर experiment कर रहा है, इसलिए https://news.ycombinator.com/item?id=33931971 वह catch up भी कर सकता है

    • Flutter और दूसरे native support पर काफ़ी सोच-विचार किया है, खासकर Flutter की बात अक्सर आती है
      हालांकि शुरुआत में pure TypeScript पर focus करने का फैसला किया, क्योंकि market काफी बड़ा है, PWA के future पर भरोसा है, और लगता है कि best experience बनाने के लिए उसी पर focus करना होगा
      किसी दिन शायद ज़्यादा platform-independent कुछ बनाएंगे, लेकिन timing तय नहीं है
      ElectricSQL और Supabase teams दोनों ही बेहतरीन और thoughtful हैं, और SQL space में आगे भी grow करती दिखती हैं; यही approach का सबसे fundamental difference है
      Triplit का मानना है कि SQL से बचकर developers को best experience दिया जा सकता है, और दोनों philosophies के coexist करने के लिए काफी जगह है

  • अगर LWW है, तो उत्सुकता है कि क्या client की information amount operations की संख्या के साथ linearly बढ़ती है
    यानी user जितना ज़्यादा DB modify करता है, क्या operation log लगातार बढ़ता रहता है, या checkpoints रखे जाते हैं, और अगर user एक दिन में लाखों operations करे तो space के लिहाज़ से यह कैसे scale करता है

    • Triplit किसी specific attribute की modification history store करता है, लेकिन latest-value index की वजह से queries fast रहती हैं
      हालांकि LWW register खुद history storage की मांग नहीं करता; यह सिर्फ current implementation है ताकि लंबे समय तक offline रहे clients भी efficiently sync कर सकें
      अभी यह कहना मुश्किल है कि दिन में दस लाख operations तक पूरी तरह पहुंच चुके हैं, लेकिन server-authoritative होने का फायदा है
      भविष्य में Triplit server हर client का last-sync timestamp track कर सकता है और history को incremental रूप से prune कर सकता है, कुछ उसी तरह जैसे Postgres dead tuples को VACUUM करता है

  • Tauri में इस्तेमाल करने के लिए Rust bindings हों तो अच्छा होगा
    Tauri की growth, जल्द आने वाला mobile device support, और हाल में SQLite की popularity मिलकर offline-first apps की gap भर सकते हैं और कई dev teams के लिए default choice बन सकते हैं

    • ElectricSQL नाम के similar sync solution में Rust bindings add करने की कोशिश कर रहा हूं
      ElectricSQL DB layer पर काम करता है इसलिए language-independent है, और server पर Rust इस्तेमाल करता है, इसलिए Rust bindings client और server दोनों तरफ काम कर सकती हैं
      अगर साथ में develop करना चाहें तो बताएं
    • लगता है Tauri native web renderer इस्तेमाल करता है
      अगर ऐसा है, तो Triplit शायद सीधे काम करना चाहिए

  • React Native app में कुछ समय से Triplit इस्तेमाल कर रहा हूं और यह बहुत अच्छी तरह काम करता है
    strongly recommend करता हूं; मेरी ज़रूरत की सभी conditions पूरी करने वाला यह इकलौता local-first DB था
    सही और sane query language (SQL नहीं), शानदार TypeScript support, offline support, React Native support है, और open source तथा self-hostable होना भी अच्छा है

  • उत्सुकता है कि इसे existing PostgreSQL DB के साथ इस्तेमाल करना संभव नहीं है क्या

    • अभी नहीं, लेकिन Postgres के replication protocol और WAL2JSON का इस्तेमाल करके bidirectional sync करने वाला internal tool है
      अभी public करने के लिए पूरी तरह ready नहीं है, लेकिन जल्द लोगों को try करने देने की कोशिश है
    • existing Postgres के साथ काम करने वाले ElectricSQL को देखना अच्छा रहेगा
      मैं भी उसी का इस्तेमाल करने की तरफ झुक रहा हूं