- लगभग 1 साल से इस्तेमाल कर रहा हूँ, और जितने भी प्रोजेक्ट संभव थे उन्हें EdgeDB में बदल दिया
- EdgeDB, Postgres के ऊपर बना Graph/Relational DB है
→ मौजूदा इंजन वही है, लेकिन यूज़र के नज़रिए से सब कुछ बदल जाता है। सबसे बड़ा बदलाव है query language और tooling
क्वेरी भाषा
- EdgeDB में SQL नहीं है, बल्कि इसकी अपनी भाषा EdgeQL है, और यही असली game changer है
- एक बार इस्तेमाल करने के बाद, फिर कभी SQL पर वापस जाने का मन नहीं करता
→ strong typing, object-oriented मॉडल, deep query को बेहद आसान बनाता है, और यह इस बात से बहुत अच्छी तरह मेल खाता है कि इंसान डेटा को query करने के बारे में कैसे सोचता है (लोग JOIN के तरीके से नहीं सोचते)
- पहले भी मैं SQL का बड़ा प्रशंसक नहीं था, लेकिन सच में उसका कोई विकल्प नहीं था
- शानदार किताब-जैसे tutorial के साथ कुछ दिन सीखने और अभ्यास करने के बाद समझ आया कि DB schema modeling एक मज़ेदार और हल्का काम हो सकता है
→ SQL की जटिलता गायब हो गई, और यह भी समझ में आया कि query language के रूप में SQL कितना अक्षम और अजीब है
- EdgeQL सीखना आसान है, और सिर्फ quickstart और overview से लगभग 80% सीखा जा सकता है
- मुझे EdgeQL इतना पसंद है कि मैं चाहता हूँ यह एक स्वतंत्र standard बन जाए। इसलिए उदाहरण के लिए ऐसा कुछ EdgeDBLite आए, जहाँ file-based DB में भी EdgeQL इस्तेमाल किया जा सके
टूलिंग
- यह उस आधुनिक pattern का पालन करता है जिसमें एक ही binary से सब कुछ चलाया जा सकता है (जैसे Go या Flutter)
→ server install और update, DB create/delete, REPL, migration, backup और project management आदि
→ और ज़्यादातर मामलों में, "It Just Works"
- EdgeDB ने DB के साथ interaction के तरीके को फिर से गढ़ा है
→ "Project" concept के ज़रिए यह DB से अपने-आप connect हो जाता है, इसलिए DSN या config की चिंता किए बिना बस काम करता है
→ 10 साल से भी ज़्यादा समय तक localhost पर root access देने के लिए सही SQL command ढूँढ़ते रहने की तुलना में यह बेहद ताज़गी भरा है
फीचर्स
- many-to-many relation modeling बेहद आसान
- embedded GraphQL (frontend से सीधे connect किया जा सकता है)
- computed property
rating := math::mean(.ratings.score)
- backlinks : लिंक को उल्टी दिशा से खोजना
→ select User.<author; ऐसे table में खोजता है जहाँ User, author नाम के field से linked है
- uuid, collection, scalar, abstract और कई तरह के type (मेरा पसंदीदा है cal::local_datetime)
- inheritance, constraints और introspection जैसी डरावनी लेकिन शक्तिशाली चीज़ें
अब तक का अनुभव
- लगभग 1 साल पहले से इस्तेमाल कर रहा हूँ। शुरुआत में एक छोटे personal project को migrate किया, बाद में कंपनी के एक project को भी migrate किया
- मेरा ज़्यादातर काम छोटे और व्यावहारिक user-facing services पर होता है, इसलिए अक्सर अकेले ज़िम्मेदारी लेते हुए सबसे उपयुक्त tool चुनने की यह सुखद सुविधा मिल गई
- EdgeDB के साथ ज़्यादातर समय अनुभव यही रहा कि "It Just Works"
- ज़्यादातर चीज़ें आसानी से मिल जाती हैं, और documentation शानदार है, इसलिए ढूँढ़ना भी आसान है (सच में, यह मैंने देखी सबसे बेहतरीन docs sites में से एक है)
क्या यह production के लिए उपयुक्त है
- पिछले शरद ऋतु से "production में उपयोग" कर रहा हूँ
- कुछ लोग "production में उपयोग" को "असल में इस्तेमाल करना" से थोड़ा ज़्यादा भारी अर्थ देते हैं, लेकिन...
- command-line tool के refactor होने पर automation scripts में थोड़ा बदलाव करना पड़ा, लेकिन कोई बड़ी बात नहीं थी
- मन ही मन एक early adopter के रूप में जोखिम की कीमत चुकाने के लिए तैयार था, लेकिन अब तक कोई समस्या नहीं आई
EdgeQL की अभिव्यक्तिशीलता
- अब SQL के बारे में Google करते रहने, ORM की सीमाओं और उनके workaround ढूँढ़ने से मुक्ति मिल गई है
- EdgeQL में मैं ठीक वही व्यक्त कर सकता हूँ जो DB से चाहता हूँ, और उसे पढ़कर सच में समझा भी जा सकता है (दूसरे developers के लिए भी)
- कई बार EdgeQL की वजह से transaction से भी बचा जा सकता है। एक single query के भीतर multiple nested update भी संभव हैं
→ "Simplicity is complicated"
Migrations
- सबसे शानदार चीज़ों में से एक यह है कि migration फीचर built-in है
- schema बदलकर
edgedb migration create चलाने पर migration file बन जाती है,
server पर edgedb migration apply करते ही वह तुरंत लागू हो जाती है
- migrations hash से linked होती हैं, इसलिए कोई एक random migration apply करके सब कुछ तोड़ देने वाली नौबत नहीं आती
- नई migration बनाते समय default interactive mode होता है, इसलिए command line पर हर बदलाव की पुष्टि ली जाती है
प्रदर्शन
- मैं बहुत बड़े data size के साथ काम नहीं करता, इसलिए मुझे ultra-high-performance DB की खास ज़रूरत नहीं है
- लेकिन नीचे Postgres होने की वजह से दूसरे DB की तुलना में performance को लेकर कोई खास समस्या नहीं है
- EdgeDB खुद Python में लिखा गया है (Go में होता तो अच्छा लगता, लेकिन लगता है developers Python में अधिक सहज हैं)
Go client library
- चूँकि मैं Go इस्तेमाल करता हूँ, इसलिए EdgeQL के लिए native Go library होना अच्छा लगा
- Typescript/Javascript, Python, Go के लिए official libraries हैं, और .Net व Elixir के लिए community support है
अपग्रेड
- EdgeDB server version और update की जटिलताओं को abstract कर देता है
- EdgeDB CLI यह सब default रूप से खुद संभाल लेता है। नया update हो तो दिखाता है और upgrade भी कर देता है
→ शक होने लायक हद तक smooth
- अभी 2.0 RC आ चुका है, लेकिन ज़रा भी चिंता नहीं है। अब तक का अनुभव भरोसा दिलाता है कि यह सुरक्षित और आसान होगा
कम्युनिकेशन और सपोर्ट
- एक early adopter के रूप में official EdgeDB channels पर बहुत तेज़ जवाब और मदद मिलने से मैं बेहद संतुष्ट हूँ
EdgeDB 2.0
- कल रिलीज़ होने वाले 2.0 में अच्छे फीचर्स जोड़े गए हैं
- EdgeDB UI : visual schema editor, REPL आदि वाला web app
- group query, global schema variables, object-level security, Direct EdgeQL over HTTP आदि
जो बातें मुझे पसंद नहीं हैं या जिनकी चिंता है
- compatibility को लेकर commitment
- अभी तक सब अच्छा रहा है। minor updates ने compatibility नहीं तोड़ी
- compatibility को लेकर एक स्पष्ट commitment मिले तो अच्छा होगा
- बढ़ता हुआ feature set
- पहले से ही इसमें मेरी ज़रूरत से ज़्यादा फीचर्स हैं, और वे लगातार बढ़ रहे हैं
- EdgeQL जितना अधिक शक्तिशाली होता जाता है, DB और server की सीमा उतनी धुंधली होती जाती है, और सोचना पड़ता है कि "क्या यह backend में होना चाहिए, या किसी smart DB schema में"
- embedded HTTP server का उपयोग करके अधिकांश projects में backend server को पूरी तरह replace करने की दिशा में बढ़ना तार्किक लगता है, लेकिन... मैं इस शानदार query language और engine के साथ एक स्थिर DB भी चाहता हूँ
- कुल मिलाकर, मैं चाहता हूँ कि EdgeDB स्थिर और सुसंगत बना रहे, और फीचर्स बहुत ज़्यादा न बढ़ें। मौजूदा feature set भी शानदार है
निष्कर्ष
- आगे के projects में मैं पारंपरिक RDB को विचार में लाने वाला नहीं हूँ
- SQL पर वापस जाना वैसा ही होगा जैसे Flutter से Ncurses पर जाना, या Go से assembly language पर लौटना
- मेरे लिए, EdgeDB पिछले 20 सालों में DB क्षेत्र की सबसे बड़ी प्रगति है
- आगे और अनुभव मिलने पर राय बदल सकती है, लेकिन 1 साल से ज़्यादा इस्तेमाल में अब तक इस खुशी को कम करने वाली कोई चीज़ नहीं मिली
- जितना ज़्यादा इस्तेमाल करता हूँ, उतना ही EdgeDB पर भरोसा बढ़ता है
- EdgeDB टीम ने EdgeDB, उसकी भाषा, website, tools और community बनाने में जो कुछ किया है, वह बेहद प्रभावशाली है
→ "Mad respect to the team"
- और ऐसा लगता है कि उन्होंने अभी बस शुरुआत ही की है
10 टिप्पणियां
इसकी वजह से मुझे edgedb के बारे में पता चला और मैं इसे अच्छी तरह इस्तेमाल कर रहा हूँ! धन्यवाद~
लगता है यह prisma जैसी ही दिशा में जा रहा है। मैं prisma का अच्छे से इस्तेमाल कर रहा हूँ, लेकिन performance के मामले में कुछ कमी महसूस होती है, इसलिए benchmark का नतीजा थोड़ा आकर्षक लग रहा है?
syntax मेरी पसंद का नहीं है, लेकिन.. (protobuf भी इस्तेमाल कर रहा हूँ, और conversion sample code भी थोड़ा...)
क्या बाकी लोग ऐसी GraphQL जैसी syntax पसंद करते हैं? मेरे लिए तो आखिर में backend RDS ही है, तो बीच में conversion होगा ही, और अगर वह साफ़ तौर पर न दिखे तो मैं थोड़ा हिचकिचाता हूँ..
यह पोस्ट देखकर मेरी रुचि जगी, इसलिए मैं लगातार इसे पढ़ रहा हूँ।
लेकिन शायद अभी यह शुरुआती चरण में है, इसलिए जब कहीं अटक जाता हूँ तो search results बहुत ज़्यादा नहीं मिलते।
Discord चैनल तो है, लेकिन लगा कि अगर देश के डेवलपर्स आराम से सवाल-जवाब कर सकें तो अच्छा होगा, इसलिए मैंने एक open chat room बनाया है।
https://open.kakao.com/o/gtGY0Gve
मैंने भी इसे इस्तेमाल करके देखने के लिए नोट कर लिया है।
इस लेख और ट्यूटोरियल को पूरा करने के बाद मैं और भी ज़्यादा आश्वस्त हो गया हूँ।
दिलचस्प है। SQL के बिना दुनिया में वापस नहीं जा सकते, है ना..
यह दिलचस्प लग रहा है।
प्रभावशाली है!
graphdb की श्रेणी में मैं ArangoDB में दिलचस्पी ले रहा था, लेकिन लगता है EdgeDB को भी एक बार देखना चाहिए।
यह वाकई बहुत बड़ी तारीफ़ है। वे 7/28 सुबह 10 बजे (PT) पर 2.0 की घोषणा करने वाले हैं.
EdgeDB 1.0 रिलीज़
EdgeDB - डेवलपर्स के लिए अगली पीढ़ी का ओपन सोर्स ORDB