gm-libs, पैकेज जिनसे Webanion का हर फ़्रंटएंड और बैकएंड शुरू होता है
वर्ज़न किए गए, फ़्रेमवर्क-न्यूट्रल पैकेजों का एक परिवार, जिससे Webanion का हर फ़्रंटएंड और बैकएंड शुरू होता है, सर्वर पर एक NestJS परत और क्लाइंट में React, Vue और Expo बाइंडिंग के साथ: पासकी और सिंगल साइन-ऑन के साथ ऑथेंटिकेशन, फ़ीचर फ़्लैग, ऑडिट ट्रेल, मल्टी-टेनेंट डेटा, एन्क्रिप्शन, फ़ाइलें, दस्तावेज़, मैसेजिंग, रियल-टाइम और ऑफ़लाइन, वेबहुक, वर्कर और एक UI किट। हर पैकेज अपनी निजी रिपॉज़िटरी में अपनी रिलीज़ के साथ रहता है और स्टूडियो की निजी npm रजिस्ट्री से इंस्टॉल होता है, और स्टूडियो का कंसोल दिखाता है कि कौन सा कंज़्यूमर किस रिलीज़ में पीछे है।
Md Moniruzzaman
पूरी कहानी
जब ऑथेंटिकेशन, ऑडिट और फ़ीचर फ़्लैग एक बार हल होकर, वर्ज़न के साथ, हर जगह दोबारा इस्तेमाल होते हैं, तो किसी स्टूडियो के क्लाइंट्स को फ़ायदा क्यों होता है।
हर बैकएंड शून्य से शुरू हो रहा था
क्लाइंट जिस भी बैकएंड के लिए भुगतान करता है, उसे क्लाइंट के काम की कोई भी चीज़ करने से पहले वही बुनियादी हिस्से चाहिए: साइन इन, सेशन, परमिशन, कॉन्फ़िगरेशन, फ़ाइल स्टोरेज, ईमेल, PDF, बैकग्राउंड जॉब और एक ऑडिट ट्रेल। हर प्रोजेक्ट के लिए नए सिरे से लिखे जाएँ तो इन हिस्सों में हफ़्ते लगते हैं, ये हर प्रोजेक्ट में अलग होते हैं, और इनके अपने बग होते हैं।
gm-libs इसका जवाब है: वह बुनियादी ढांचा जो पहले के काम में खुद को साबित कर चुका था, वहाँ से निकालकर वर्ज़न, डॉक्यूमेंटेशन और चेंजलॉग वाले पैकेजों के रूप में मज़बूत किया गया, और स्टूडियो जो फ़्रंटएंड और बैकएंड बनाता है उनमें बार-बार इस्तेमाल होता है।
साइन इन और परमिशन, एक ही बार में हल
ऑथ पैकेज में Argon2id पासवर्ड हैशिंग, रोटेट होने वाले रिफ़्रेश सेशन के साथ कम समय तक चलने वाले एक्सेस टोकन, और OpenFGA पर रिलेशनशिप-आधारित परमिशन शामिल हैं, ताकि “शाखा के कर्मचारी सिर्फ़ अपनी शाखा देखें” जैसा नियम कोड में बिखरे चेक नहीं, बल्कि एक घोषित मॉडल हो। इसमें अकाउंट लिंकिंग के साथ सोशल और OIDC साइन इन, पासवर्ड के बिना साइन इन, मल्टी-फ़ैक्टर ऑथेंटिकेशन, पासकी और सिंगल साइन-ऑन भी शामिल हैं। नया बैकएंड एक मॉड्यूल इंपोर्ट करके यह सब पा लेता है।
क्लाइंट के लिए इसका मतलब है ऐसी सुरक्षा जो पहले ही एक फ़ाइनेंस प्लेटफ़ॉर्म पर मज़बूत और टेस्ट की जा चुकी है, डेडलाइन के दबाव में दोबारा ईजाद नहीं की गई।
फ़ीचर, सुरक्षित तरीके से चालू
फ़्लैग पैकेज तय करता है कि हर टेनेंट, शाखा, रोल या व्यक्ति के लिए क्या दिखेगा और क्या चलेगा, और यह कभी किसी रिक्वेस्ट को नहीं रोकता: फ़्लैग मेमोरी से पढ़े जाते हैं, और फ़्लैग सर्वर तक न पहुँचा जा सके तो हर फ़्लैग एक सुरक्षित डिफ़ॉल्ट पर लौट आता है, जो बंद रहता है जब तक टीम ने कुछ और न चुना हो। यह ऑथराइज़ेशन की जगह नहीं लेता, उसके साथ मिलकर काम करता है, इसलिए जब तक फ़्लैग और परमिशन दोनों हाँ न कहें, कुछ भी नहीं दिखता।
क्लाइंट किसी फ़ीचर को पहले एक शाखा या एक व्यक्ति के लिए रिलीज़ कर सकते हैं, उस पर नज़र रख सकते हैं, और बिना डिप्लॉय के उसका दायरा बढ़ा सकते हैं, और Al-Insaf टीम अपने फ़ीचर इसी तरह चलाती है।
एक ऑडिट ट्रेल जो किसी को धीमा नहीं करता
ऑडिट पैकेज हर राइट पर दर्ज करता है कि किसने क्या, कहाँ और कब किया, उसे कैटेगरी और गंभीरता के हिसाब से वर्गीकृत करता है, और हर एंट्री को रिक्वेस्ट के रास्ते से हटाकर बैच में लिखने के लिए सौंप देता है। धीमा या फ़ेल होता ऑडिट स्टोर लॉग होता है और सिस्टम इस्तेमाल कर रहे व्यक्ति को कभी नहीं रोकता, और इसी वजह से हर ज़रूरी चीज़ का ऑडिट करना सुरक्षित है।
हर पैकेज, एक काम
ऑथ, फ़्लैग और ऑडिट के साथ-साथ यह परिवार उन बाकी ज़रूरतों को भी पूरा करता है जो एक फ़्रंटएंड और एक बैकएंड को चाहिए, हर पैकेज एक ही काम करता है और एक ही तरीके से जुड़ता है: नीचे फ़्रेमवर्क-न्यूट्रल कोड, सर्वर के लिए एक NestJS परत, और जहाँ कोई पैकेज क्लाइंट तक पहुँचता है वहाँ React, Vue और Expo बाइंडिंग।
- नींव और डेटा: core (एरर, रिक्वेस्ट कॉन्टेक्स्ट, क्रेडेंशियल छिपाने वाला लॉगर, किसी सीक्रेट के न होने पर तुरंत रुक जाने वाला टाइप्ड कॉन्फ़िगरेशन, पैसा, पेजिनेशन, रेट लिमिटिंग, आइडेम्पोटेंसी, हेल्थ) और db (मल्टी-टेनेंट Postgres, हर टेनेंट के लिए अलग डेटाबेस, माइग्रेशन और मॉडल के साथ)।
- पहचान और एक्सेस: auth, flags, audit, और बदलती रहने वाली कुंजियों के साथ फ़ील्ड और सीक्रेट के एनवेलप एन्क्रिप्शन के लिए crypto।
- फ़ाइलें, दस्तावेज़ और संदेश: स्टोरेज और साइन किए गए अपलोड के लिए media, pdf, स्ट्रीम किए गए CSV और XLSX एक्सपोर्ट और जाँचे गए इंपोर्ट के लिए tabular, ईमेल, SMS, पुश और टीम चैट के लिए notifications, और रियल-टाइम बातचीत के लिए chat।
- रियल टाइम और ऑफ़लाइन: प्रमाणित प्रति-चैनल इवेंट के लिए realtime, React, Vue और Expo के लिए दोबारा जुड़ जाने वाले क्लाइंट के साथ, और offline, हर यूज़र के कैश और ठीक एक बार भेजने वाली राइट कतार के लिए, ब्राउज़र में और Expo ऐप में।
- इंटीग्रेशन और रनटाइम: Standard Webhooks स्पेक के अनुसार साइन किए गए webhooks, Temporal के लिए worker, मज़बूत हेडलेस ब्राउज़र और अंदरूनी पतों को ठुकराने वाले आउटबाउंड फ़ेच के लिए web, स्ट्रीम किए गए, एन्क्रिप्टेड डेटाबेस बैकअप के लिए datavault, और MCP सर्वर बनाने के लिए mcp।
- इंटरफ़ेस: ui, डिज़ाइन टोकन से लेकर React, Vue, Next.js और Expo कंपोनेंट तक।
इनके साथ devkit वह जाँच है जो हर लाइब्रेरी रिलीज़ से पहले चलाती है। हर पैकेज अपनी निजी रिपॉज़िटरी में अपनी रिलीज़ के साथ रहता है, इसलिए किसी क्लाइंट का सिस्टम तभी बदलता है जब उसकी टीम नया वर्ज़न लेती है।
एक फ़िक्स, हर सिस्टम
क्योंकि स्टूडियो के सभी फ़्रंटएंड और बैकएंड एक ही नींव पर टिके हैं, एक बार किया गया सिक्योरिटी फ़िक्स या सुधार वर्ज़न बम्प के ज़रिए उन सब तक पहुँचता है, साथ में एक चेंजलॉग होता है जो बताता है कि क्या बदला और क्यों। हर रिलीज़ में सिमेंटिक वर्ज़निंग का पालन होता है, इसलिए किसी दूसरे क्लाइंट को कुछ नया चाहिए था, सिर्फ़ इस वजह से किसी क्लाइंट का सिस्टम नहीं टूटता, और कंसोल उसी दिन दिखा देता है कि किस कंज़्यूमर ने अभी तक कोई रिलीज़ नहीं ली है।
क्लाइंट्स के लिए नतीजा है तेज़ डिलीवरी, कम अप्रत्याशित झटके, और ऐसे हिस्सों पर बना प्रोडक्ट जो कहीं और प्रोडक्शन से गुज़र चुके हैं, जिनमें Al-Insaf की कहानी वाला लेजर-स्तर का फ़ाइनेंस प्लेटफ़ॉर्म भी शामिल है।
हर पैकेज, प्रकाशित और निगरानी में
हर पैकेज स्टूडियो की निजी npm रजिस्ट्री से इंस्टॉल होता है, और स्टूडियो का कंसोल उस रजिस्ट्री को वैसे ही पढ़ता है जैसे कोई कंज़्यूमर पढ़ेगा। यह रजिस्ट्री को पिंग करता है, हर पैकेज का हर वर्ज़न उसके प्रकाशन समय, पैक किए गए आकार और इंटीग्रिटी के साथ पढ़ता है, और कंज़्यूमरों के अपने मैनिफ़ेस्ट उनकी डिफ़ॉल्ट ब्रांच से पढ़कर परखता है कि हर डिपेंडेंसी नवीनतम रिलीज़ पर पहुँचती है या नहीं। कोई लाइब्रेरी परिवार उतना ही उपयोगी है जितना यह सबूत कि उसे इस्तेमाल करने वाला हर सिस्टम अद्यतन है, और वह सबूत यहीं रहता है।
कैप्चर के दिन, 30 सितंबर 2026 को, व्यू में रजिस्ट्री चालू थी, हर पैकेज प्रकाशित था, रजिस्ट्री का अपना एक हालिया बैकअप था, और स्टूडियो के अपने टूल को छोड़कर हर कंज़्यूमर नवीनतम रिलीज़ पर था, वे टूल तब भी core और pdf की पुरानी रिलीज़ पर थे।
GitHub Release से npm install तक, स्टूडियो की रजिस्ट्री से होकर
किसी लाइब्रेरी पर लगाया गया टैग GitHub पर उसकी रिलीज़ चलाता है और रिलीज़ के साथ एक पैक की गई फ़ाइल जोड़ता है। क्लस्टर के अंदर एक सिंक हर पाँच मिनट में ठीक वही फ़ाइल प्रकाशित करता है, इसलिए रिलीज़ और रजिस्ट्री में वही बाइट रहते हैं, जिन्हें हर रात फिर से जाँचा जाता है। पढ़ने के लिए लॉगिन चाहिए, और सार्वजनिक नाम कोई राइट स्वीकार नहीं करता। GitHub Packages को इसलिए छोड़ा गया क्योंकि लाइब्रेरी और उनके कंज़्यूमर अलग-अलग ऑर्गनाइज़ेशन में रहते हैं।
आपको ये भी पसंद आ सकते हैं
Fully Booked - प्रचार और ट्यूटोरियल वीडियो निर्माण
एक प्रमोशनल वीडियो जो ब्रिटेन के एक मिनीबस ऑपरेटर को Fully Booked के फ़ायदे उसी क्रम में दिखाता है जिसमें वे उसके लिए मायने रखते हैं, स्टॉक फ़ुटेज से नहीं, असली ऐप से बना। यह ऑपरेटर की अपनी समस्या से शुरू होता है, हर फ़ायदे को एक असली स्क्रीन पर एक पल देता है, और कई लंबाइयों में काटा गया, सोशल फ़ीड के लिए कुछ सेकंड के हुक से लेकर लैंडिंग पेज और स्टोर लिस्टिंग के पूरे संस्करण तक।
Md Moniruzzaman
जून 24, 2025
Fully Booked - Photoshop के साथ विज़ुअल एसेट डिज़ाइन
स्टोर स्क्रीनशॉट, एक फ़ीचर ग्राफ़िक, एक ऐप आइकन और ईमेल आर्ट, असली स्क्रीन से Photoshop में बनाए गए, ताकि एक नया प्लेटफ़ॉर्म भी ऑपरेटरों को जमा-जमाया लगे। स्क्रीनशॉट Apple और Google के माँगे हर साइज़ में पाँच स्वाइप में पूरी बात कहते हैं, हर ईमेल ब्रांड के रंगों में अपने एक चित्र से खुलता है, और आइकन व स्प्लैश स्क्रीन पर दो मिलते हाथों वाला लोगो है।
Md Moniruzzaman
जून 24, 2025
Fully Booked - मोबाइल ऐप और एडमिन पैनल के लिए UI/UX डिज़ाइन
Fully Booked की हर स्क्रीन एक स्केच के रूप में शुरू हुई, जिसे किसी कोड पर पैसा खर्च होने से पहले संस्थापक ने मंज़ूर किया, और हर एक किसी ऑपरेटर या ग्राहक की समस्या का जवाब है। ऑपरेटर की होम स्क्रीन कमाई का एक मेन्यू बन गई, Get Covered ने अपने हाथ से बने फ़्लो का क्रम बनाए रखा, कोट और रद्दीकरण पत्र संस्थापक के अपने शब्दों से आए, और एडमिन पाँच वायरफ़्रेम टैब से बढ़कर नेटवर्क का कंट्रोल रूम बन गया। MVP की स्क्रीन Webanion के एक अन्य डिज़ाइनर ने डिज़ाइन की थीं; चरण 2, 3 और 4 को मैंने खुद Figma में इन्हीं फ़्लो के आधार पर रीडिज़ाइन किया।
Md Moniruzzaman
जून 24, 2025
ब्लॉग प्रोडक्शन से लिखे फ़ील्ड नोट्स हैं: आर्किटेक्चर के फ़ैसले, असली उपयोगकर्ताओं के सामने टिके AI सिस्टम, और अपनी लागत खुद निकालने वाला इन्फ्रास्ट्रक्चर। काम से लिखा गया, काम के बारे में नहीं।