ऐप बनाना

अंतिम अपडेट: 3 जुलाई 2026

अपने बनाए वेब ऐप को Market App के रूप में मार्केटप्लेस पर डालने के लिए, सबसे पहले ऐप को बिल्ड करके उसका आउटपुट तैयार करना होता है। इस प्रक्रिया में HTML और JavaScript से एक स्टैटिक साइट बिल्ड करना, और कमांड लाइन पर बिल्ड आउटपुट की जाँच करना शामिल है।

Market App वह ऐप है जिसे मार्केटप्लेस पर डालकर दूसरे Space में इंस्टॉल किया जाता है। इसका स्वरूप Web Hosting जैसा ही एक स्टैटिक वेब ऐप होता है। पहले से बिल्ड की हुई स्क्रीन फ़ाइलों का बंडल डाल देने पर, जब कोई विज़िटर आता है तो वही स्क्रीन वैसी की वैसी दिखती है।

सामान्य वेब ऐप से एक अंतर है, और उसी वजह से बिल्ड करते समय एक नियम का पालन करना ज़रूरी हो जाता है। यह पेज उस अंतर, उस नियम, और डालने से पहले की जाँच को कवर करता है।

इंस्टॉल करने पर रिसोर्स इंस्टॉल करने वाले के Space में कॉपी हो जाते हैं

Market App इंस्टॉल करने पर सिर्फ़ ऐप की स्क्रीन ही नहीं, बल्कि पब्लिश करते समय साथ चुने गए रिसोर्स (Content Type, Content, Media आदि) भी इंस्टॉल करने वाले के Space में कॉपी हो जाते हैं। मान लीजिए आपने एक कपड़ों की दुकान का प्रोडक्ट कैटलॉग ऐप बनाकर डाला। जब कोई उस ऐप को इंस्टॉल करता है, तो ऐप की स्क्रीन के साथ-साथ प्रोडक्ट Content Type और प्रोडक्ट Content भी उसके Space में कॉपी होकर चले जाते हैं।

कॉपी हुए रिसोर्स को इंस्टॉल किए गए Space में नया पहचानकर्ता (identifier) मिलता है। कंटेंट पढ़ने के लिए इस्तेमाल होने वाला Delivery Access Token भी इंस्टॉल किए गए Space में नया बन जाता है। इसीलिए इंस्टॉल किया गया ऐप निर्माता के Space को नहीं, बल्कि इंस्टॉल करने वाले के Space में कॉपी हुई अपनी प्रतिलिपि को पढ़ता है। इंस्टॉल पूरा होने के बाद वह ऐप सिर्फ़ इंस्टॉल किए गए Space के रिसोर्स से ही काम करता है।

पहुँच जानकारी को बिल्ड में क्यों गाड़ देते हैं

इंस्टॉल किए गए Market App में कोई सर्वर नहीं होता। यह Web Hosting जैसी ही स्टैटिक होस्टिंग है, इसलिए हर अनुरोध पर स्क्रीन की गणना करके देने वाला कोई सर्वर रनटाइम नहीं होता, और कंटेंट को ब्राउज़र सीधे WEEGLOO डिलीवरी API (CDA, Content Delivery API) को कॉल करके लाता है। इसीलिए बिल्ड आउटपुट (स्क्रीन फ़ाइलों) के अंदर लिखा होना चाहिए कि किस Space से क्या, और किस क्रेडेंशियल मान से पढ़ना है।

समस्या यह है कि, जैसा पहले देखा, इंस्टॉल करने पर रिसोर्स नए पहचानकर्ता के साथ कॉपी हो जाते हैं। बिल्ड फ़ाइल में लिखे मान निर्माता के Space के पहचानकर्ता और टोकन होते हैं, जबकि इंस्टॉल की गई जगह पर जो पढ़ना है वह नई कॉपी हुई प्रतिलिपि है। पुराने मान वैसे ही छोड़ देने पर ऐप गलत जगह की ओर इशारा करता है।

इसीलिए WEEGLOO इंस्टॉल करते समय इन मानों को आपकी जगह बदलकर लगा देता है। पब्लिश करते समय बिल्ड टेक्स्ट के अंदर निर्माता के Space के पहचानकर्ता, टोकन और रिसोर्स पहचानकर्ता कहाँ लिखे हैं, यह पहले से ढूँढ लेता है, और इंस्टॉल करते समय उस जगह को इंस्टॉल किए गए Space की प्रतिलिपि के नए मान से बदल देता है। इसकी बदौलत इंस्टॉल किया गया ऐप अपने आप इंस्टॉल किए गए Space की ओर इशारा करने लगता है।

यह प्रतिस्थापन सिर्फ़ ऐप के साथ रखे गए रिसोर्स के लिए ही होता है। इसलिए स्क्रीन जो रिसोर्स पढ़कर लाती है (Content Type, Delivery Access Token आदि), उन्हें पब्लिश करते समय बिना छूटे साथ रखना ज़रूरी है। छूट जाने पर उस पहचानकर्ता को बदला नहीं जाता और वह इंस्टॉल की गई जगह पर गलत मान बनकर रह जाता है। क्या-क्या साथ रखना है, यह ऐप पब्लिश करना के रिसोर्स चयन में बताया गया है।

इस स्वचालित प्रतिस्थापन की एक शर्त है। मान बिल्ड टेक्स्ट के अंदर एक अखंड स्ट्रिंग के रूप में, ज्यों का त्यों मौजूद होना चाहिए। पब्लिश चरण उस स्ट्रिंग को अक्षरशः ढूँढकर उसकी जगह दर्ज करता है, इसीलिए। मान को टुकड़ों में बाँट देने पर, चलते समय बनाकर डालने पर, या बाहर से मँगाने पर पब्लिश चरण उसे नहीं ढूँढ पाता, और तब इंस्टॉल करते समय प्रतिस्थापन भी नहीं होता, जिससे इंस्टॉल किया गया ऐप काम नहीं करता।

बिल्ड में गाड़े जाने वाले (और इंस्टॉल करते समय बदले जाने वाले) मान तीन हैं।

  • मूल Space की sys.id (spaceId): किस Space से पढ़ना है।
  • मूल Space का Delivery Access Token: उस Space के पब्लिश किए गए कंटेंट को पढ़ सकने वाला रीड-ओनली क्रेडेंशियल मान।
  • ऐप जिन रिसोर्स को संदर्भित करता है उनकी sys.id: उदाहरण के लिए प्रोडक्ट रखने वाले Content Type की sys.id आदि, यानी क्लाइंट कोड जिस रिसोर्स पहचानकर्ता की ओर इशारा करता है।

मानों को लिटरल के रूप में इनलाइन करना

मुख्य बात यह है कि ऊपर के तीनों मान बिल्ड आउटपुट के अंदर एक अखंड स्ट्रिंग लिटरल (intact literal substring) के रूप में दिखने चाहिए। बिल्ड की गई टेक्स्ट फ़ाइल (JS, HTML, JSON आदि) खोलने पर, मान टुकड़ों में बँटे या बदले बिना ज्यों का त्यों एक टुकड़े में दिखना चाहिए। तभी पब्लिश चरण उस मान को ढूँढकर उसकी जगह दर्ज कर पाता है, और इंस्टॉल चरण उस जगह को नए मान से बदल पाता है।

नीचे क्लाइंट कोड में रखे गए सेटअप का एक उदाहरण है। मान सिर्फ़ प्रारूप दिखाने के लिए हैं, और इन्हें असली क्रेडेंशियल मानों से बदलना ज़रूरी है।

// weegloo.config.js: ये मान बिल्ड आउटपुट में ज्यों के त्यों आते हैं
export const WEEGLOO = {
  spaceId: "spc_xxxxxxxxxxxxxxxx",                 // मूल Space की sys.id
  deliveryAccessToken: "dat_xxxxxxxxxxxxxxxxxxxx",  // मूल Space का Delivery Access Token
  productContentTypeId: "ct_xxxxxxxxxxxx",          // ऐप जिसे पढ़ता है उस Content Type की sys.id
};

ब्राउज़र इन मानों से CDA को सीधे कॉल करता है।

fetch(`https://cda.weegloo.com/v1/spaces/${WEEGLOO.spaceId}/contents`, {
  headers: { Authorization: `Bearer ${WEEGLOO.deliveryAccessToken}` },
});

नीचे दिए तरीके इस्तेमाल नहीं करने चाहिए। ये सभी मान को बिल्ड आउटपुट में अखंड लिटरल के रूप में रहने नहीं देते, जिससे पब्लिश चरण मान को नहीं ढूँढ पाता। तब इंस्टॉल करते समय प्रतिस्थापन नहीं होता, और इंस्टॉल किया गया ऐप अपने Space की प्रतिलिपि नहीं पढ़ पाता।

  • रनटाइम पर्यावरण चर (environment variable) खोजना। इंस्टॉल किए गए ऐप में मान डालने वाला कोई सर्वर या रनटाइम पर्यावरण नहीं होता, और बिल्ड टेक्स्ट में भी मान अक्षरों के रूप में नहीं रहता।

    // नहीं चलेगा: इंस्टॉल की गई जगह पर यह पर्यावरण चर मौजूद नहीं होता
deliveryAccessToken: process.env.DELIVERY_ACCESS_TOKEN

  • रनटाइम fetch से लाना। मान को कहीं से मँगाने पर, बिल्ड टेक्स्ट में मान नहीं रहता और मँगाने की जगह भी नहीं होती।

  • स्ट्रिंग जोड़कर टुकड़ों में बाँटना। मान एक टुकड़े में नहीं दिखता, इसलिए पब्लिश चरण उसे नहीं ढूँढ पाता।

    // नहीं चलेगा: आउटपुट में "dat_xxxxxxxxxxxxxxxxxxxx" एक substring के रूप में नहीं रहता
deliveryAccessToken: "dat_" + "xxxxxxxxxxxxxxxxxxxx"

  • प्लेसहोल्डर या खाली जगह छोड़ना। मान भरने का काम इंस्टॉल करते समय WEEGLOO कर देता है। पर वह प्रतिस्थापन बिल्ड में गाड़े गए असली मान को ढूँढकर उसकी जगह बदलने का काम है, इसलिए खाली जगह या अस्थायी संकेत छोड़ने पर ढूँढने को कोई मान नहीं होता और वह प्रतिस्थापन का लक्ष्य नहीं बन पाता। बिल्ड आउटपुट बनाते समय असली मान अक्षरशः मौजूद होना चाहिए।

मान हमेशा टेक्स्ट फ़ाइल (JS, HTML, JSON आदि) में रखें। इमेज या फ़ॉन्ट जैसी बाइनरी फ़ाइलों में नहीं डालना चाहिए। मान ढूँढकर बदलने का काम सिर्फ़ टेक्स्ट फ़ाइलों में ही होता है।

बंडलर भी जाँच का विषय है। कुछ बंडलर अनुकूलन (optimization) की प्रक्रिया में स्ट्रिंग लिटरल को टुकड़ों में बाँट देते हैं या बदल देते हैं। सिर्फ़ सोर्स कोड देखकर निश्चिंत न हों, बल्कि असली बिल्ड आउटपुट खोलकर जाँचें कि मान अखंड लिटरल के रूप में बना हुआ है या नहीं (अगला सेक्शन)।

टोकन को न्यूनतम अधिकार के साथ जारी करें

बिल्ड में गाड़ा जाने वाला Delivery Access Token ब्राउज़र में ज्यों का त्यों उजागर होता है। इंस्टॉल करने वाला कोई भी ऐप की बिल्ड फ़ाइल में यह मान देख सकता है (इंस्टॉल के बाद उस Space में नया बनने वाला टोकन भी इसी तरह उजागर होता है)। इसलिए यह टोकन केवल उन्हीं Content Type को पढ़ सकने वाले न्यूनतम-अधिकार SpaceRole के साथ जारी करना चाहिए, जिन्हें ऐप को वास्तव में पढ़ना है। Administrator भूमिका से जारी न करें। एडमिन-अधिकार वाला टोकन ब्राउज़र में उजागर होने पर पूरा मूल Space ख़तरे में पड़ जाता है।

न्यूनतम-अधिकार SpaceRole बनाकर उस भूमिका से Delivery Access Token जारी करने का तरीका टोकन में बताया गया है।

पब्लिश से पहले की जाँच

डालने से पहले, दिमाग़ में नहीं बल्कि असली बिल्ड आउटपुट में जाँचें कि मान सही तरह से गए हैं या नहीं। बिल्ड किए गए फ़ोल्डर में मूल spaceId, टोकन, और रिसोर्स sys.id को अलग-अलग grep करके देखें कि वे अखंड लिटरल के रूप में निकलते हैं या नहीं।

grep -r "DATxxxxxxxxxxxxxxxx" dist/

जो मान ढूँढना है वह बिल्ड आउटपुट के अंदर एक टुकड़े में (बिना टुकड़ों में बँटे या बदले) निकले, बस यही काफ़ी है। गाड़े गए तीनों मानों (spaceId, Delivery Access Token, संदर्भित रिसोर्स sys.id) के लिए जाँचें। इनमें से एक भी grep में न पकड़ में आए, तो पब्लिश चरण भी उस मान को नहीं ढूँढ पाएगा और इंस्टॉल करते समय वह बदला नहीं जाएगा (या तो बंडलर ने मान बदल दिया है या रनटाइम खोज की वजह से वह छूट गया है)। ऐसी स्थिति में, पहले बताए "मानों को लिटरल के रूप में इनलाइन करना" को देखकर मान को अखंड लिटरल के रूप में बने रहने के लिए ठीक करें।

स्टैटिक बिल्ड की सीमाएँ

Market App का बिल्ड आउटपुट Web Hosting जैसी ही स्टैटिक सीमाओं का पालन करता है।

  • सर्वर रनटाइम नहीं होता। स्टैटिक export के रूप में बिल्ड करना ज़रूरी है (SSR नहीं)।
  • कंप्रेशन खोलने पर फ़ाइलें 100 या उससे कम होनी चाहिए।
  • बंडल के सबसे ऊपर (रूट में) index.html होना चाहिए।
  • WEEGLOO API (CDA आदि) की कॉल ब्राउज़र से सीधे की जाती है।

विस्तृत स्टैटिक सीमाएँ और फ़ाइल बंडल के नियम वेबसाइट परिनियोजन में बताए गए हैं।

बिल्ड की हुई स्क्रीन App Bundle में रखी जाती है

जाँच पूरी हुआ बिल्ड आउटपुट पब्लिश करते समय App Bundle (ऐप को संस्करण-वार बाँधा गया बंडल) में रखा जाता है। पब्लिश स्क्रीन पर साथ चुने गए रिसोर्स भी उसी बंडल में रखे जाते हैं, और इंस्टॉल करते समय इंस्टॉल किए गए Space में कॉपी हो जाते हैं। पब्लिश करके संस्करण बढ़ाने की प्रक्रिया ऐप पब्लिश करना में बताई गई है।

अगर ऐप अपने सदस्य लेता है

यहाँ तक की बात उस स्थिति की है जब कोई भी पढ़ सकने वाला सार्वजनिक कंटेंट CDA से पढ़कर लाया जाता है। अगर ऐप अपना सदस्य पंजीकरण और लॉगिन लेता है, तो ServiceLogin और आधिकारिक क्लाइंट SDK का इस्तेमाल होता है। इस स्थिति में ब्राउज़र CDA नहीं, बल्कि ACDA (App Content Delivery API) को सदस्य के टोकन से कॉल करता है। सेटअप और जोड़ने का तरीका सेवा सदस्य लॉगिन में बताया गया है।

इंस्टॉल किए गए Market App की प्रमाणीकरण विधि को App Auth संभालता है, और इंस्टॉल किए गए ऐप तक पहुँच अधिकार रखने वाले उपयोगकर्ता को App Member संभालता है।

आगे क्या करें

  • ऐप पब्लिश करना: बनाए गए ऐप (App Bundle) को मार्केटप्लेस पर डालने की कंटेंट स्टूडियो प्रक्रिया बताता है।
  • वेबसाइट परिनियोजन: स्टैटिक बिल्ड, 100 फ़ाइलों की सीमा, index.html रूट जैसी Web Hosting की बुनियादी बातें बताता है।
  • टोकन: बिल्ड में इनलाइन करने वाले Delivery Access Token को न्यूनतम-अधिकार SpaceRole से जारी करने का तरीका बताता है।
  • API रेफरेंस: ऐप स्क्रीन कंटेंट लाते समय जिस CDA (डिलीवरी API) को कॉल करती है, और अपने सदस्य लेने वाले ऐप के लिए ACDA के अनुरोध प्रारूप जैसी तकनीकी विशिष्टियाँ बताता है।