𝗧𝘂𝗿𝘀𝗼 𝗹𝗶𝗯𝗦𝗤𝗟 𝘃𝘀 𝗖𝗹𝗼𝘂𝗱𝗳𝗹𝗮𝗿𝗲 𝗗𝟭
Astro monorepo साठी डेटाबेस निवडणे हे तुमच्या वर्कफ्लोवर (workflow) अवलंबून असते.
मी अलीकडेच तीन Astro SSG साइट्ससाठी एक शेअर केलेला डेटाबेस तयार केला. माझ्याकडे दोन पर्याय होते: Turso (libSQL) किंवा Cloudflare D1.
मी Turso निवडले.
व्यावहारिक फरक का महत्त्वाचा ठरला, याची कारणे खालीलप्रमाणे आहेत.
Cloudflare D1 हे Cloudflare Workers साठी बनवले आहे. जर तुम्ही server-side rendering साठी Workers वापरत असाल, तर D1 हा विजेता आहे. तुमचा कोड जिथे चालतो, तिथेच तो उपलब्ध असतो.
माझी सेटअप (setup) वेगळी आहे. माझ्या साइट्स Cloudflare Pages वर static Astro 5 SSG आहेत. मी Workers वापरत नाही. माझी ETL pipeline GitHub Actions मध्ये चालते.
GitHub Actions मधून D1 वापरणे कठीण आहे. तुम्हाला Cloudflare API किंवा Wrangler CLI वापरावे लागते. यापैकी कोणताही पर्याय डेव्हलपमेंट दरम्यान क्वेरी करण्यासाठी तुम्हाला स्थानिक (local) SQLite फाईल देत नाही. परिणामी, तुम्हाला प्रत्येक टेस्टसाठी रिमोट डेटाबेसवर अवलंबून राहावे लागते.
Turso हे @libsql/client पॅकेजद्वारे ही समस्या सोडवते. ते URL स्वीकारते. ती URL एक रिमोट लिंक किंवा स्थानिक फाईल पाथ (local file path) असू शकते.
माझा कोड असा दिसतो:
CI मध्ये URL ही रिमोट Turso लिंक असते. माझ्या लॅपटॉपवर, क्लायंट एक स्थानिक फाईल उघडतो. पॅकेज, क्वेरीज आणि स्कीमा (schema) सारखेच राहतात.
कोड पाथ (code path) अगदी सारखाच असतो.
यामुळे मला खालील गोष्टी करता येतात:
- स्थानिक पातळीवर (locally) ETL स्क्रिप्ट्स चालवणे.
- कोणत्याही SQLite व्ह्यूअरने डेटाबेस तपासणे.
- प्रोडक्शनमध्ये वापरल्या जाणाऱ्या त्याच फंक्शनसह मायग्रेशन्स (migrations) चालवणे.
मला Docker ची गरज नाही. मला विशेष फ्लॅग्सची (flags) गरज नाही. तोच SQL सर्वत्र काम करतो.
मी मायग्रेशन्ससाठी 'idempotent' दृष्टिकोन वापरतो. टेबल तयार करण्यापूर्वी माझा कोड ते टेबल अस्तित्वात आहे का ते तपासतो. यामुळे ते वारंवार चालवणे सुरक्षित होते.
तुम्ही D1 कधी निवडले पाहिजे? जर तुम्ही सर्च किंवा API रूट्ससाठी Cloudflare Workers वापरत असाल, तर D1 अधिक चांगले आहे. कनेक्शन अधिक वेगवान असते कारण ते एकाच डेटासेंटरमध्ये राहते.
माझे आर्किटेक्चर (architecture) पूर्णपणे स्टॅटिक आहे. मी Workers वापरत नसल्यामुळे, D1 चा मुख्य फायदा निघून जातो.
सध्याचे तडजोड (trade-offs):
- Write performance: माझी ETL टास्क एक-एक करून चालवते. मी हाय-स्पीड कॉनकरंट (concurrent) राइट्सची चाचणी घेतलेली नाही.
- Schema changes: कॉलम्स जोडणे सोपे आहे. कॉलम्सचे नाव बदलण्यासाठी अधिक काळजी घ्यावी लागते.
- Pricing: दोन्हीकडे उदार फ्री टियर्स (free tiers) आहेत. तीन साइट्ससाठी माझा खर्च शून्य आहे.
डेटाबेस निवडणे हे मुख्य उद्दिष्ट नव्हते. स्थानिक फाईलचा पर्याय (local file fallback) हे मी Turso का निवडले याचे कारण होते. यामुळे डेव्हलपमेंट सोपे होते.