बहुत समय पहले, लगभग 10 साल पहले, मैंने एक डेटाबेस ऑब्जेक्ट मैपिंग और डिज़ाइन, वेब + एपीआई को मिलाकर, "डेटाबेस एज़ ए सर्विस" (DBaaS) बनाने की कोशिश की थी। उस समय, सेवा के डेटाबेस एक्सेस भाग को स्वयं उसी सेवा के आउटपुट से बनाया गया था। अनिवार्य रूप से, मैं अपने स्वयं के डेटाबेस + एपीआई से संबंधित कोड को अपने स्वयं के आउटपुट के साथ चला रहा था। यह सभी एसक्यूएल नहीं था, लेकिन कुछ हद तक, डेटा प्रारूप JSON और डेटाबेस के बीच एक-से-एक पत्राचार में थे।
प्रक्रिया
- डेटाबेस डिज़ाइन (विकास के लिए वेब यूआई के साथ)
- एसक्यूएल डिज़ाइन (विकास के लिए वेब यूआई के साथ)। यह एपीआई के साथ संगत था।
- क्लाइंट स्निपेट (कॉपी-पेस्ट के लिए) तक आउटपुट।
- वास्तविक क्लाइंट दायरे से बाहर है (अलग से बनाने की आवश्यकता है)।
उस समय कोई एआई नहीं था, लेकिन हाल ही में, एआई के आगमन के साथ, मुझे इस विचार के विस्तार की संभावना महसूस होने लगी है। इसलिए, सबसे पहले, बाजार अनुसंधान के रूप में, मैंने एआई से पूछा कि क्या वर्तमान में इसी तरह की अवधारणा वाले कोई उत्पाद मौजूद हैं।
ChatGPT उत्तर:
हाँ, यह मौजूद है। वास्तव में, आजकल इस दिशा में सेवाएं काफी विकसित हो गई हैं, और न केवल "उन चीजों के काफी करीब" जो पहले करने की कोशिश की जा रही थी, बल्कि कुछ तो लगभग पूर्ण रूप में हैं।
DB as a Service के विचार की वर्तमान स्थिति का सारांश
अवलोकन
लगभग 10 साल पहले, निम्नलिखित अवधारणाओं पर विचार किया गया था:
- ORM द्वारा अमूर्तता (SQL को सीधे न लिखना)
- JSON और DB का 1:1 मैपिंग
- DB एक्सेस को भी एक सेवा के रूप में प्रदान करना (DBaaS)
- वेब/API के रूप में सीधे उपयोग करने के लिए डिज़ाइन
यह वर्तमान में "हेडलेस बैकएंड / बैकएंड एज़ ए सर्विस / API-फर्स्ट DB" के रूप में स्थापित है।
प्रमुख दृष्टिकोणों का वर्गीकरण
1. DB → API स्वचालित पीढ़ी
यह दृष्टिकोण DB स्कीमा से सीधे API उत्पन्न करता है।
-
Supabase
- PostgreSQL पर आधारित
- REST / GraphQL API स्वचालित पीढ़ी
- JSON के साथ उच्च अनुकूलता
-
Hasura
- GraphQL API स्वचालित पीढ़ी
- रीयल-टाइम समर्थन
- मजबूत प्राधिकरण प्रबंधन
-
PostgREST
- DB से सीधे REST API उत्पन्न करता है
- API परत को लगभग अनावश्यक बनाता है
👉 "DB = API" का विचार
2. ORM विकास (JSON अनुकूल)
यह डिज़ाइन ORM का उपयोग करते हुए JSON के साथ मजबूत संबंध स्थापित करता है।
-
Prisma
- टाइप-सुरक्षित क्वेरी
- JSON फ़ील्ड समर्थन
- JS ऑब्जेक्ट के साथ लगभग 1:1
👉 "ORM, लेकिन वास्तव में JSON मैपिंग"
3. JSON मूल DB प्रकार
यह DB शुरू से ही JSON को आधार बनाता है।
-
Firebase
- Firestore पूरी तरह से JSON है
- क्लाइंट से सीधे एक्सेस किया जा सकता है
-
MongoDB Atlas
- BSON (JSON एक्सटेंशन) पर आधारित
- स्कीमा रहित
👉 "ORM की आवश्यकता नहीं" दृष्टिकोण
4. प्रकार और API एकीकरण (हाल की प्रवृत्ति)
-
tRPC
- API और क्लाइंट को प्रकार से सीधे जोड़ता है
- JSON संचार पर आधारित
- Prisma के साथ संगत
👉 "API = प्रकार परिभाषा"
वैचारिक संबंध
| उस समय की अवधारणा | वर्तमान अवधारणा |
|---|---|
| ORM अमूर्तता | Prisma आदि |
| JSON और DB का 1:1 संबंध | Firestore / MongoDB / JSON कॉलम |
| DB एक्सेस को सेवा में बदलना | Supabase / Hasura |
| API को शामिल करना | PostgREST |
मुख्य समानताएं
विशेष रूप से महत्वपूर्ण बिंदु:
DB एक्सेस लेयर को स्वयं समान तंत्र का उपयोग करके बनाना।
यह वर्तमान में:
- स्कीमा-संचालित विकास
- स्व-वर्णनात्मक API
- API-फर्स्ट डिज़ाइन
के रूप में सामान्यीकृत है।
निष्कर्ष
उस समय की अवधारणा आधुनिक समय में:
"एक ऐसी दुनिया जहां DB सीधे API बन जाता है"
यह कई कार्यान्वयन रूपों में विभाजित होकर साकार हो रहा है।
- DB-संचालित → Supabase / Hasura
- ORM-संचालित → Prisma
- JSON-संचालित → Firestore
पूरक (मूल्यांकन)
यह विचार वर्तमान रुझानों के साथ लगभग मेल खाता है, और विशेष रूप से निम्नलिखित बिंदुओं में उन्नत है:
- API लेयर को हटाना (या स्वचालित करना)
- डेटा संरचना = इंटरफ़ेस
- JSON-केंद्रित डिज़ाइन
विकासात्मक विषय (यदि आवश्यक हो)
- Flutter के साथ संयोजन में इष्टतम कॉन्फ़िगरेशन
- स्वयं बनाने की स्थिति में विभेदन बिंदु
- GraphQL vs REST vs tRPC का डिज़ाइन चयन
... विचार के रूप में, वह भी अच्छा है, लेकिन उससे भी महत्वपूर्ण बात यह है कि आप अपनी डिज़ाइन के साथ विस्तार कर सकते हैं। यदि आप कुछ करना चाहते हैं। यदि आपको लगता है कि कार्यक्षमता पर्याप्त नहीं है। तो, आपको न केवल फ़ंक्शन बदलने की आवश्यकता होगी, बल्कि डेटा प्रारूप को भी बदलने की आवश्यकता होगी। उस पुनरावर्ती लूप में, सबसे पहले यह तय करना कि आप क्या करना चाहते हैं, यानी फ़ंक्शन से डेटा प्रारूप और फिर JSON संगतता और API तक, एक साथ डिज़ाइन और विकसित करने की क्षमता ही महत्वपूर्ण है।
ChatGPT उत्तर: ठीक है, उस बारीकियों का महत्व बहुत अधिक है। सिर्फ "DB→API स्वचालित पीढ़ी" नहीं, बल्कि,
"चाहने योग्य कार्य → डेटा संरचना → JSON → API → निष्पादन" एक ही डिज़ाइन प्रणाली के भीतर स्वयं को विस्तारित करता है।
यह वर्तमान सेवाओं से थोड़ा अलग है, और यह अधिक "अधूरे क्षेत्र" के करीब है।
स्व-विकसित बैकएंड (Self-evolving Backend) की अवधारणा
अवलोकन
यह केवल "DB as a Service" या "ORM" नहीं है, बल्कि निम्नलिखित लूप को एकल तंत्र के साथ पूरा करने का डिज़ाइन सिद्धांत है:
चाहने योग्य कार्य → डेटा संरचना → JSON → API → निष्पादन → पुनः डिज़ाइन
यह लूप बाहरी (मानव डिज़ाइन) पर निर्भर नहीं करता है, और आंतरिक रूप से बंद है, यही इसका सार है।
समस्या की चेतना
पारंपरिक विकास प्रवाह:
चाहने योग्य कार्य → डिज़ाइन (मानव) → DB डिज़ाइन → API डिज़ाइन → कार्यान्वयनसमस्याएं:
- डेटा संरचना में परिवर्तन भारी होता है।
- API और DB अलग हैं।
- डिज़ाइन और निष्पादन अलग हैं।
प्रस्तावित संरचना
चाहने योग्य कार्य → (एक ही सिस्टम के भीतर) → डेटा संरचना निर्माण → JSON में रूपांतरण → API निर्माण → निष्पादन → अपर्याप्त → पुनः डिज़ाइन (लूप)मुख्य विशेषताएं
1. फंक्शन-आधारित
- शुरुआती बिंदु हमेशा "चाहने योग्य कार्य" होता है।
- यह DB से नहीं, बल्कि फंक्शन से शुरू होता है।
2. स्कीमा स्थिर नहीं है
- फंक्शन की कमी → डेटा संरचना में परिवर्तन
- स्कीमा का विकास एक पूर्व शर्त है।
3. JSON के साथ 1:1 संबंध
- डेटा संरचना = JSON
- API के साथ कोई विचलन नहीं है।
4. स्व-विस्तारणीय
- समान तंत्र का उपयोग करके स्वयं को विस्तारित करें।
- इसमें मेटा-संरचना शामिल है।
मौजूदा तकनीकों के साथ तुलना
स्कीमा → API स्वचालित निर्माण
- Hasura
- PostgREST
→ यह DB-आधारित है, फंक्शन-आधारित नहीं।
ORM / टाइप-संचालित
- Prisma
- tRPC
→ स्कीमा परिवर्तन मैन्युअल रूप से किए जाते हैं।
JSON-मूल
- Firebase
→ संरचना लचीली है, लेकिन डिज़ाइन में स्थिरता कमजोर है।
निर्णायक अंतर
मौजूदा:
डिज़ाइन → कार्यान्वयन (एक दिशा)
यह अवधारणा:
डिज़ाइन ⇄ कार्यान्वयन (द्विदिश, पुनरावर्ती)
संबंधित अवधारणाएं
स्व-वर्णनात्मक प्रणालियाँ
- स्कीमा को स्वयं डेटा के रूप में संग्रहीत करना।
मेटा-वृत्तीय वास्तुकला
- एक ऐसी संरचना जो स्वयं को परिभाषित कर सकती है।
स्कीमा-एज़-डेटा
- स्कीमा को रनटाइम पर बदलने की क्षमता।
नॉलेज ग्राफ / ऑन्टोलॉजी
- अर्थ से संरचना का निर्माण।
सिस्टम संरचना (न्यूनतम मॉडल)
1. स्कीमा परिभाषा (JSON)
2. स्वचालित रूप से उत्पन्न होने वाले तत्व
- DB टेबल / JSON स्टोरेज
- REST / GraphQL API
- निष्पादन लॉजिक (एक्शन)
3. मेटा ऑपरेशन
- स्कीमा को बदलने के लिए API
- गतिशील पुनर्निर्माण
- संस्करण नियंत्रण (अनिवार्य)
कार्यान्वयन के लिए आवश्यक तत्व
- स्कीमा का JSON प्रतिनिधित्व
- स्कीमा → DB निर्माण
- स्कीमा → API निर्माण
- स्कीमा परिवर्तन API
- फंक्शन (व्यवहार) का एकीकरण
तकनीकी पहलू
- JSONB (PostgreSQL) जैसे लचीले स्टोरेज
- गतिशील कोड पीढ़ी या इंटरप्रेटर
- प्राधिकरण प्रबंधन (स्कीमा स्तर पर)
- माइग्रेशन का अमूर्तता
सार
यह अवधारणा BaaS नहीं है:
डिजाइन को ही रनटाइम में ले जाना।
एक शब्द में परिभाषा
प्रोग्रामेबल स्कीमा सिस्टम (स्कीमा स्वयं एक प्रोग्राम है)
निष्कर्ष
यह मौजूदा सेवाओं का विस्तार नहीं है:
- DB
- API
- लॉजिक
- डिजाइन
को एकीकृत किया गया है
स्व-विकसित बैकएंड
भविष्य के विकास विषय
- Flutter के साथ एकीकरण
- स्कीमा परिवर्तन की सुरक्षा (लेन-देन)
- UI स्वचालित पीढ़ी के साथ कनेक्शन
- LLM द्वारा "जो करना है → स्कीमा" रूपांतरण
・・・पहले जो चीजें बनाई गई थीं, उनमें से लगभग सभी स्वतंत्र कोड का उपयोग करके बनाई गई थीं, और वे मानक इंटरफेस का पालन नहीं करती थीं। लेकिन अब, AI का उपयोग करके इसे किया जा सकता है। उदाहरण के लिए, मैं उन चीजों को Codex का उपयोग करके फिर से बनाने के बारे में सोच रहा हूं।
ChatGPT का उत्तर:
यह बहुत अच्छा समय है। वर्तमान में, Codex आपके विचार के अनुरूप विकसित हो रहा है।
निष्कर्ष में
👉 "यह विचार, Codex के साथ करने पर, एक बेहतर परिणाम देगा।"
Codex और स्व-विस्तारणीय बैकएंड अवधारणा की अनुकूलता
1. अवलोकन
आपका विचार (स्व-विस्तारणीय बैकएंड) और वर्तमान Codex में बहुत अधिक अनुकूलता है।
विशेष रूप से महत्वपूर्ण यह है:
"Codex डिज़ाइन प्रक्रिया को ही चला सकता है।"
2. Codex में मौलिक परिवर्तन
पारंपरिक कोड जनरेशन AI:
- फ़ंक्शन आउटपुट करता है
- स्निपेट पूर्ण करता है
- केवल स्थानीय सहायता प्रदान करता है
वर्तमान Codex:
- पूरी रिपॉजिटरी को समझता है
- कई फ़ाइलों को संपादित करता है
- परीक्षण निष्पादन सहित पुनरावृत्ति संशोधन करता है
- कार्यान्वयन और रिफैक्टरिंग को लगातार करता है
3. मौलिक अर्थ
यह केवल विकास नहीं है, बल्कि एक संरचनात्मक परिवर्तन है।
"सिर्फ एक कोड जनरेशन टूल" से "विकास लूप निष्पादन एजेंट" तक
4. आपके विचार के साथ संगतता
आपका लूप
जो करना है → डेटा संरचना डिज़ाइन → JSON में रूपांतरण → API जनरेशन → निष्पादन → अपर्याप्त → पुनः डिज़ाइनCodex के साथ एकीकरण के बाद
जो करना है → Codex (डिज़ाइन जनरेशन) → स्कीमा जनरेशन → DB/API जनरेशन → निष्पादन + परीक्षण → अपर्याप्त का पता लगाना → पुनः डिज़ाइन → लूप जारी5. निर्णायक परिवर्तन
पहले
- स्कीमा परिवर्तन मानव द्वारा किया जाता था
- API संशोधन भी मानव द्वारा किए जाते थे
- लूप बाहरी निर्भरता पर था
बाद में
- Codex स्कीमा परिवर्तन का प्रस्ताव और कार्यान्वयन करता है
- API अपडेट भी स्वचालित हो जाते हैं
- लूप सिस्टम के भीतर पूरा हो जाता है
6. महत्वपूर्ण संरचनात्मक परिवर्तन
विकास लूप मानव से बाहर निकल जाता है
इसके द्वारा:
- मनुष्य केवल "इरादे" के लिए जिम्मेदार होता है
- कार्यान्वयन और संशोधन सिस्टम पर स्थानांतरित हो जाते हैं
- प्रतिक्रिया की गति में तेजी आती है
7. लूप क्लोजर का अर्थ
यहाँ महत्वपूर्ण बात यह है:
विकास प्रक्रिया स्वयं एक बंद प्रणाली बन जाती है
अर्थात:
- इनपुट: इरादा (क्या/क्यों)
- आंतरिक: डिजाइन, कार्यान्वयन, मूल्यांकन लूप
- आउटपुट: कार्यशील प्रणाली
8. महत्वपूर्ण बिंदु
इस संरचना में:
- डिजाइन स्थिर नहीं रहता
- स्कीमा हमेशा अपडेट करने योग्य होता है
- एपीआई और डेटा संरचना की सीमाएं गायब हो जाती हैं
9. क्रमिक विकास
लेवल 1 (वर्तमान)
- कोडेक्स कोड सहायता प्रदान करता है
- मनुष्य नेतृत्व करते हैं
लेवल 2 (संकल्पना चरण)
- विकास लूप बंद हो जाता है
- स्कीमा का विकास स्वचालित हो जाता है
10. मूलभूत परिवर्तन
पारंपरिक रूप से:
डिजाइन = एक निश्चित परिणाम
वर्तमान में:
डिजाइन = एक लगातार विकसित होने वाली प्रक्रिया
11. महत्वपूर्ण परिणाम
इस संरचना में:
- विकास की गति प्रयास की संख्या पर निर्भर करती है
- प्रतिक्रिया में देरी समाप्त हो जाती है
- सुधार निरंतर होता है
12. सारांश
कोडेक्स के विकास के साथ:
विकास लूप मानव-केंद्रित संरचना से एक आत्मनिर्भर प्रणाली में बदल सकता है
13. अगला चरण (परिचय की पूर्व शर्त)
इस क्रम में:
- स्कीमा का स्वचालित पुन: डिजाइन
- मूल्यांकन फ़ंक्शन का समावेश
- आवश्यकताओं के निर्माण का स्वचालन
जैसे विकास हैं, लेकिन वे आगे की चर्चा का विषय हैं।
・・・・थोड़ा और गहराई से जानने की कोशिश की गई।
ChatGPT का उत्तर:
Codex और "विकास लूप का समापन" के बारे में
1. अवलोकन
इस विचार का मूल सरल है।
विकास का लूप (इरादा → डिज़ाइन → कार्यान्वयन → निष्पादन → सुधार) सिस्टम के भीतर बंद होने लगा है।
इसके कारण, पारंपरिक "मानव-केंद्रित विकास प्रक्रिया" धीरे-धीरे बदल रही है।
2. Codex की भूमिका में परिवर्तन
Codex जैसी प्रणालियाँ अब केवल कोड उत्पन्न करने तक ही सीमित नहीं हैं।
- कोड लिखना
- कई फ़ाइलों को संपादित करना
- परीक्षण और सुधारों को दोहराना
- कुछ हद तक डिज़ाइन परिवर्तन करना
मतलब:
यह विकास कार्य का एक हिस्सा होने के बजाय, "विकास लूप के निष्पादक" बनने की ओर बढ़ रहा है।
3. आपके विचार के साथ संबंध
इस परिवर्तन को ध्यान में रखते हुए, निम्नलिखित लूप यथार्थवादी हो सकता है:
जो करना है → Codex द्वारा संरचनाकरण (स्कीमा-डिज़ाइन) → API-DB-कार्यान्वयन का सृजन → निष्पादन → कमियों का पता लगाना → पुन: डिज़ाइनयहाँ महत्वपूर्ण बात यह है:
डिज़ाइन और कार्यान्वयन की सीमाएँ कम हो रही हैं, और उन्हें एक ही लूप के भीतर संभाला जा सकता है।
4. हो रहे मूल परिवर्तन
पारंपरिक रूप से:
- डिज़ाइन एक स्थिर परिणाम होता था।
- कार्यान्वयन एक अलग प्रक्रिया थी।
- सुधार एक मैनुअल प्रक्रिया थी।
वर्तमान में:
- डिज़ाइन एक परिवर्तनीय संरचना है।
- कार्यान्वयन स्वचालित रूप से उत्पन्न किया जा सकता है।
- सुधार लूप का एक हिस्सा है।
मतलब:
विकास "प्रक्रिया" से "लगातार प्रक्रिया" में बदल रहा है।
5. स्थानीय त्वरित संरचना
इस प्रणाली में, कुछ क्षेत्रों में:
- प्रयासों की संख्या बढ़ जाती है।
- प्रतिक्रिया तेज़ होती है।
- सुधार चक्र छोटा हो जाता है।
परिणामस्वरूप:
स्थानीय रूप से, "एक ऐसी संरचना जो तेजी से विकसित होती है" उत्पन्न होती है।
6. सिंगुलैरिटी से दूरी
यह प्रवृत्ति सामान्य अर्थों में सिंगुलैरिटी से अलग है।
हालांकि, वैचारिक रूप से:
"सिंगुलैरिटी जैसी प्रकृति (स्व-सुधार लूप)" का एक हिस्सा, सीमित क्षेत्रों में दिखाई देने लगा है।"
इसे कहा जा सकता है।
महत्वपूर्ण अंतर:
- यह सामान्य कृत्रिम बुद्धिमत्ता का विस्फोट नहीं है।
- हालांकि, विकास प्रक्रिया का स्व-त्वरण हो रहा है।
7. सारांश
Codex जैसे तंत्र के कारण:
- विकास चक्र धीरे-धीरे बंद होने लगे हैं।
- डिजाइन और कार्यान्वयन की सीमाएं अस्पष्ट हो रही हैं।
- सुधार की गति तेज हो रही है।
इसके परिणामस्वरूप:
सॉफ्टवेयर विकास "क्रमिक प्रक्रियाओं" से "स्व-अद्यतन लूप" की ओर बढ़ रहा है।
इस प्रवृत्ति के विस्तार में, धीरे-धीरे, "सिंगुलैरिटी" जैसी विशेषताएं आंशिक रूप से दिखाई देने लगती हैं।
・・・・मैं इस क्षेत्र में, फिलहाल, केवल शौक के तौर पर (ऐसा लगता है कि इससे पैसे नहीं मिलेंगे) कुछ करने की सोच रहा हूँ।
...और, इसके अलावा, हमने एआई (AI) के साथ चर्चा करके एक सेवा पर विचार किया, लेकिन अन्य विभिन्न सेवाओं के कारण, इसकी स्थिति निर्धारित करना मुश्किल है। यह न केवल एक OR मैपिंग है और न ही RDB का APIकरण है, तो यह क्या है? उदाहरण के लिए, यह एक डेटा डिज़ाइन टूल हो सकता है, या डेटा डिज़ाइन के लिए एक उच्च-स्तरीय टूल हो सकता है। यह एक अवधारणा के रूप में बहुत व्यापक है, लेकिन वास्तव में, पहले बनाया गया एक फ्रेमवर्क वास्तव में RDB में "डेटा को परिभाषित करने के लिए डेटा" रखता था, इसलिए यह कहना गलत नहीं होगा कि यह एक ऐसा टूल है जो डेटा संरचना को परिभाषित करता है और इसे लागू भी कर सकता है। यदि यह डेटा संरचना की परिभाषा से लेकर RDB डिज़ाइन, API और क्लाइंट कॉल स्निपेट तक सब कुछ कवर करता है, तो यह एक ऐसा क्षेत्र है जहां Microsoft के DB टूल और Oracle जैसे कई दिग्गज मौजूद हैं, और मुझे नहीं लगता कि किसी स्टार्टअप के लिए अभी प्रतिस्पर्धा करना संभव है। ऐसे क्षेत्रों में, यदि कोई अच्छा विचार मिलता है, तो वह तुरंत नकल कर लिया जाता है, और चूंकि उनका प्रचार बेहतर होता है, इसलिए ऐसा लगता है कि हमने उन्हें एक प्रोटोटाइप प्रदान किया है, और हम इसे पसंद नहीं करते हैं।
यह काफी मुश्किल है, लेकिन शायद, फिलहाल, पहले आंशिक रूप से तैयार किए गए किसी चीज़ को शौक के तौर पर रिफैक्टर करना सबसे अच्छा हो सकता है।