सभी को नमस्कार, देव परिवार संपर्क में है। हम आपको एक दिलचस्प परियोजना के बारे में बताना चाहते हैं जिस पर हम लगभग छह महीने से काम कर रहे हैं और अभी भी जारी हैं। इस दौरान इसमें बहुत कुछ हुआ है, बहुत कुछ बदला है. हमने अपने लिए कुछ दिलचस्प खोजा, धक्कों को भरने में कामयाब रहे। हमारी कहानी कैसी होगी? हमने क्या किया हमने कैसे शुरुआत की यह हमें कहां ले गया हमें किन-किन समस्याओं का सामना करना पड़ा मोनोरेपो क्यों पीएनपीएम क्यों क्यों टीएस अब यह कैसे काम करता है हमने अपने जीवन को कितना आसान बना लिया है परियोजना के बारे में थोड़ा तो, हम अभी भी किस पर काम कर रहे हैं? वास्तव में, यह प्रश्न किसी समय बहुत प्रासंगिक हो गया था, उदाहरण के लिए, एक समय में मैकडॉनल्ड्स कॉर्पोरेशन के मालिक के लिए। हमने प्रोजेक्ट को एक क्रिप्टो-लॉयल्टी प्रोग्राम के रूप में शुरू किया था जो अंतिम-उपयोगकर्ताओं को कुछ कार्यों के लिए पुरस्कार प्रदान करता है, और ग्राहक इन्हीं उपयोगकर्ताओं पर विश्लेषण प्राप्त करते हैं। हाँ, यह बहुत सतही है, लेकिन इससे कोई फर्क नहीं पड़ता। काम की शुरुआत शॉपिफाई स्टोर्स, ब्रांडों के लिए एक पोर्टल, Google क्रोम के लिए एक एक्सटेंशन, एक मोबाइल एप्लिकेशन + डेटाबेस के साथ एक सर्वर (ठीक है, वास्तव में, उनके बिना कहीं नहीं) से जुड़ने के लिए शॉपिफाई मॉड्यूल विकसित करना आवश्यक था। सामान्य तौर पर, हमें जो चाहिए, हमने फैसला किया और काम करना शुरू कर दिया। चूंकि परियोजना को तुरंत बड़ा मान लिया गया था, हर कोई समझ गया था कि यह विलंबित कार्रवाई की जादुई फलियों की तरह बढ़ सकता है। सब कुछ "सही ढंग से" और "सभी मानकों के अनुसार" करने का निर्णय लिया गया। यानी सब कुछ एक भाषा में लिखा गया है - टाइपस्क्रिप्ट। ताकि हर कोई एक ही तरह से लिखे, और फाइलों, लिंटर्स (बहुत सारे लिंटर्स) में कोई अनावश्यक बदलाव न हो, ताकि सब कुछ पुन: उपयोग करने के लिए "आसान" हो, सब कुछ अलग-अलग मॉड्यूल में डालें, और ताकि वे चोरी न करें जीथब एक्सेस टोकन। तो हमने शुरू किया: लिंटर्स और टीएस कॉन्फिग के लिए रिपॉजिटरी अलग (स्टाइल गाइड) एक मोबाइल एप्लिकेशन के लिए रिपॉजिटरी (प्रतिक्रिया मूल) और एक क्रोम एक्सटेंशन (react.js) (एक साथ, चूंकि वे समान कार्यक्षमता को दोहराते हैं, केवल विभिन्न उपयोगकर्ताओं के लिए लक्षित हैं) पोर्टल के लिए एक और भंडार Shopify मॉड्यूल के लिए दो रिपॉजिटरी ब्लॉकचेन स्टफ एपीआई रिपॉजिटरी के लिए रिपॉजिटरी (एक्सप्रेस.जेएस) इंफ्रास्ट्रक्चर के लिए रिपॉजिटरी हुह ... लगता है कि मैंने सब कुछ सूचीबद्ध किया है। यह थोड़ा अधिक हो गया, लेकिन ठीक है, चलो रोल करना जारी रखें। अरे हाँ, Shopify मॉड्यूल के लिए दो रिपॉजिटरी क्यों आवंटित की गईं? क्योंकि पहला रिपॉजिटरी UI-मॉड्यूल है। हमारे शिशुओं और उनकी सेटिंग्स की सारी सुंदरता है। और दूसरा है इंटीग्रेशन-शॉपिफाई। यह वास्तव में इसका 'कार्यान्वयन Shopify में ही सभी तरल फ़ाइलों के साथ है। कुल मिलाकर, हमारे पास 8 रिपॉजिटरी हैं, जहां कुछ को एक दूसरे के साथ संवाद करना चाहिए। चूंकि हम टाइपस्क्रिप्ट में विकास के बारे में बात कर रहे हैं, हमें मॉड्यूल, लाइब्रेरी स्थापित करने के लिए पैकेज मैनेजर की भी आवश्यकता है। लेकिन हम सभी ने अपने रिपॉजिटरी में स्वतंत्र रूप से काम किया, और किसी के लिए यह मायने नहीं रखता था कि क्या उपयोग किया जाए। उदाहरण के लिए, रिएक्ट नेटिव पर एक मोबाइल एप्लिकेशन विकसित करते समय, मैंने बहुत लंबे समय तक नहीं सोचा और YARN1 रखा। किसी को अच्छे पुराने एनपीएम का उपयोग करने की अधिक आदत हो सकती है, जबकि अन्य सब कुछ नया पसंद करते हैं और ताजा YARN3 का उपयोग करते हैं। इस प्रकार, कहीं NPM था, कहीं YARN1, और कहीं YARN3। इसलिए हम सभी ने अपने आवेदन करना शुरू कर दिया। और लगभग तुरंत ही मज़ा शुरू हो गया, लेकिन वह पूरा नहीं हुआ। सबसे पहले, कुछ लोगों ने टाइपस्क्रिप्ट के बारे में नहीं सोचा था, और जहां भी वे बहुत आलसी थे, या जहां वे "नहीं समझ पाए" कि वे इसे कैसे नहीं लिख सकते थे, "किसी भी" का उपयोग किया। किसी को सभी टाइपस्क्रिप्ट शक्ति और इस तथ्य का एहसास नहीं था कि कुछ जगहों पर सब कुछ बहुत आसान बनाया जा सकता है। इसलिए, प्रकार लौकिक आयामों से निकले। हां, मैं कहना भूल गया, हमने हसुरा ग्राफक्यूएल को एक डेटाबेस के रूप में उपयोग करने का निर्णय लिया। इसमें से सभी उत्तरों का मैनुअल टंकण कभी-कभी कुछ और जैसा दिखता था। और एक मामले में, कुछ ने अच्छी पुरानी Javascript में भी लिखा। हां, स्थिति शांत हो गई: पहले व्यक्ति ने "कोई भी" एक बार फिर से तनाव न करने के लिए रखा, दूसरा अपने हाथों से कैनवस लिखता है, और तीसरा अभी भी टाइप नहीं लिखता है। बाद में यह पता चला कि ऐसे मामलों में जहां हमने तर्क दोहराया, और, एक अच्छे तरीके से, इसे एक अलग पैकेज में निकाला जाना चाहिए - कोई भी ऐसा करने वाला नहीं था। हर कोई अपने लिए कोड लिखता और लिखता है, बाकी सब चीजों के लिए - एक ऊंचे बेल टॉवर से थूकना। यह हमें कहाँ ले गया? हमारे पास क्या है? हमारे पास विभिन्न अनुप्रयोगों के साथ 8 रिपॉजिटरी हैं। कुछ की हर जगह जरूरत होती है, दूसरे एक दूसरे से संवाद करते हैं। इसलिए, हम सभी .NPMrc फाइलें बनाते हैं, क्रेडिट निर्धारित करते हैं, एक जीथब टोकन बनाते हैं, फिर पैकेज मैनेजर-मॉड्यूल के माध्यम से। सामान्य तौर पर थोड़ी परेशानी, हालांकि अप्रिय, लेकिन असामान्य कुछ भी नहीं। केवल पैकेज में कुछ अपडेट करने के मामले में, आपको इसके संस्करण को अपग्रेड करने की आवश्यकता है, फिर इसे अपलोड करें, फिर इसे अपने एप्लिकेशन/मॉड्यूल में अपडेट करें, और उसके बाद ही आप देखेंगे कि क्या बदल गया है। लेकिन यह सर्वथा अनुचित है! खासकर यदि आप कहीं रंग बदल सकते हैं। इसके अलावा, कुछ कोड दोहराए जाते हैं और पुन: उपयोग नहीं किए जाते हैं, लेकिन चुपचाप फिर से लिखे जाते हैं। यदि हम एक मोबाइल एप्लिकेशन और एक ब्राउज़र एक्सटेंशन के बारे में बात कर रहे हैं, तो रेडक्स स्टोर और एपीआई के साथ सभी काम पूरी तरह से दोहराए जाते हैं, कुछ को पूरी तरह से फिर से लिखा जाता है या थोड़ा संशोधित किया जाता है। कुल मिलाकर, हमारे पास क्या बचा है: रिपॉजिटरी का एक गुच्छा, अनुप्रयोगों / मॉड्यूलों का एक लंबा लॉन्च, समान लोगों द्वारा लिखी गई बहुत सी चीजें, परियोजना में नए लोगों को परीक्षण और पेश करने में बहुत समय लगता है, और ऊपर से उत्पन्न होने वाली अन्य समस्याएं। संक्षेप में, इसने हमें इस तथ्य तक पहुँचाया कि कार्य बहुत लंबे समय तक किए गए थे। बेशक, इससे समय सीमा समाप्त हो गई, परियोजना के लिए किसी नए को पेश करना काफी कठिन था, जिसने एक बार फिर विकास की गति को प्रभावित किया। सब कुछ काफी नीरस और लंबा होने वाला था, कुछ मामलों में, इसके लिए वेबपैक को धन्यवाद। तब यह स्पष्ट हो गया कि हम जहां प्रयास कर रहे थे, उससे बहुत दूर जा रहे थे, लेकिन कौन जानता है कि कहां। तमाम गलतियों का विश्लेषण करने के बाद हमने कई फैसले लिए, जिनकी चर्चा अब की जाएगी। मोनोरेपो क्यों? संभवतः, सबसे महत्वपूर्ण बात जो भविष्य में बहुत प्रभावित हुई, वह यह अहसास था कि हम एक विशिष्ट एप्लिकेशन नहीं, बल्कि एक प्लेटफॉर्म बना रहे हैं। हमारे पास कई प्रकार के उपयोगकर्ता हैं, उनके लिए अलग-अलग एप्लिकेशन हैं, लेकिन वे एक ही प्लेटफॉर्म के भीतर काम करते हैं। इसलिए हमने बड़ी संख्या में रिपॉजिटरी के साथ समस्या को तुरंत बंद कर दिया: यदि हम एक प्लेटफॉर्म पर काम कर रहे हैं, तो इसे रिपॉजिटरी में क्यों विभाजित करें जब एक में काम करना आसान हो। मैं कहना चाहता हूं कि मोनोरेपो में काम करने से हमारा जीवन काफी आसान हो गया है। कुछ एप्लिकेशन या मॉड्यूल का एक दूसरे के साथ सीधा संबंध था, और अब आप एक ही रिपॉजिटरी में एक ही शाखा पर मन की शांति के साथ उन पर काम कर सकते हैं। लेकिन यह मुख्य लाभ से दूर है। आगे है। हमने सब कुछ एक रिपॉजिटरी में स्थानांतरित कर दिया है। ठंडा! पुन: प्रयोज्य होने तक हम उसी गति से काम करते रहे। वास्तव में, यह हमारे काम में "अच्छे स्वाद का नियम" है। यह महसूस करते हुए कि कुछ स्थानों पर हम समान एल्गोरिदम, फ़ंक्शंस, कोड और कुछ स्थानों पर अलग-अलग पैकेजों का उपयोग करते हैं जिन्हें हमने जीथब के माध्यम से स्थापित किया है, हमने तय किया कि यह सब "बहुत अच्छी गंध नहीं करता है" और एक मोनोरेपो के भीतर सब कुछ अलग-अलग पैकेजों में डालना शुरू कर दिया कार्यक्षेत्रों का उपयोग करना। वर्कस्पेस (वर्कस्पेस) एनपीएम क्लि में फ़ंक्शंस के सेट हैं, जिसके साथ आप एक ही शीर्ष-स्तरीय रूट पैकेज से कई पैकेजों का प्रबंधन कर सकते हैं। वास्तव में, ये एक पैकेज के भीतर के पैकेज हैं जो एक विशिष्ट पैकेज मैनेजर (कोई भी YARN / NPM / PNPM) के माध्यम से जुड़े होते हैं, और फिर दूसरे पैकेज में उपयोग किए जाते हैं। सच कहूँ तो, हमने कार्यक्षेत्रों पर तुरंत सब कुछ फिर से नहीं लिखा, बल्कि आवश्यकतानुसार किया। यहाँ यह कैसा दिखता है: एक फ़ाइल से { "type": "module", "name": "package-name-1", ... "types": "./src/index.ts", "exports": { ".": "./src/index.ts" }, }, किसी अन्य फ़ाइल के लिए { "type": "module", "name": "package-name-2", ... "dependencies": { "package-name-1": "workspace:*", }, }, पीएनपीएम का उपयोग करने वाला एक उदाहरण कुछ भी जटिल नहीं है, वास्तव में यदि आप इसके बारे में सोचते हैं: कुछ आदेश और पंक्तियां लिखें, और फिर जो चाहें और जहां चाहें उपयोग करें। लेकिन "एक चेतावनी है, कामरेड"। पहले मैंने लिखा था कि हर कोई अपने इच्छित पैकेज मैनेजर का उपयोग करता है। संक्षेप में, हमारे पास विभिन्न प्रबंधकों के साथ एक रिपॉजिटरी है। कुछ जगहों पर यह हास्यास्पद था जब किसी ने लिखा कि वह इस या उस पैकेज को लिंक नहीं कर सका, इस तथ्य को ध्यान में रखते हुए कि वह एनपीएम का उपयोग करता है, और यार्न है। मैं जोड़ूंगा कि समस्या अलग-अलग प्रबंधकों के कारण नहीं थी, बल्कि इसलिए कि लोगों ने गलत कमांड का इस्तेमाल किया या कुछ गलत कॉन्फ़िगर किया। उदाहरण के लिए, YARN 3 के माध्यम से कुछ लोगों ने सिर्फ YARN लिंक किया और बस इतना ही, लेकिन YARN 1 के लिए पिछड़े अनुकूलता की कमी के कारण यह उस तरह से काम नहीं कर पाया जैसा वे चाहते थे। मोनोरेपो पर स्विच करने के बाद पीएनपीएम क्यों? इस बिंदु तक, यह स्पष्ट हो गया कि समान पैकेज मैनेजर का उपयोग करना बेहतर है। लेकिन आपको कौन सा चुनना है, इसलिए उस समय हमने केवल 2 विकल्पों पर विचार किया - और । हमने एनपीएम को तुरंत त्याग दिया, क्योंकि यह दूसरों की तुलना में धीमा और बदसूरत था। पीएनपीएम और यार्न के बीच एक विकल्प था। YARN PNPM YARN ने शुरू में अच्छा काम किया - यह तेज़, सरल और अधिक समझने योग्य था, यही वजह है कि तब सभी ने इसका इस्तेमाल किया। लेकिन जिस व्यक्ति ने YARN बनाया उसने फेसबुक छोड़ दिया, और अगले संस्करणों का विकास और इसे दूसरों को स्थानांतरित कर दिया गया। इस प्रकार YARN 2 और YARN 3 पूर्व के साथ पिछड़े संगतता के बिना प्रकट हुए। इसके अलावा, यार्न.लॉक फ़ाइल के अलावा, वे एक यार्न फ़ोल्डर उत्पन्न करते हैं, जो कभी-कभी नोड_मॉड्यूल के रूप में वजन करता है और कैश को अपने आप में संग्रहीत करता है। इसलिए, हमने कई अन्य डेवलपर्स की तरह अपना ध्यान PNPM की ओर लगाया। यह अपने समय के पहले YARN जितना सुविधाजनक निकला। वर्कस्पेस का उपयोग यहां आसानी से किया जा सकता है, कुछ कमांड पहले YARN की तरह ही दिखते हैं। इसके अलावा, शर्मनाक-फहराना एक अच्छा अतिरिक्त विकल्प निकला - हर बार किसी फ़ोल्डर में जाने और पीएनपीएम स्थापित करने की तुलना में हर जगह नोड_मॉड्यूल स्थापित करना अधिक सुविधाजनक है। Turborepo और कोड पुन: उपयोग इसके अलावा, हमने टर्बोरेपो को आजमाने का फैसला किया। Turborepo एक CI/CD टूल है जिसके पास Turbo.json फ़ाइल के माध्यम से विकल्पों, cli और कॉन्फ़िगरेशन का अपना सेट है। जितना संभव हो सके स्थापित और कॉन्फ़िगर किया गया। हम टर्बो क्लि की एक वैश्विक प्रति डालते हैं PNPM add turbo --global. प्रोजेक्ट में Turbo.json जोड़ना टर्बो.जेसन { "$schema": "https://turbo.build/schema.json", "pipeline": { "build": { "dependsOn": ["^build"] } } } उसके बाद हम टर्बोरेपो के सभी उपलब्ध कार्यों का उपयोग कर सकते हैं। हम इसकी विशेषताओं और मोनोरेपो में इसके उपयोग की संभावना से सबसे अधिक आकर्षित हुए। हमें क्या फंसाया: इंक्रीमेंटल बिल्ड्स (इंक्रीमेंटल बिल्ड्स - बिल्ड्स को इकट्ठा करना काफी दर्दनाक है, टर्बोरेपो याद रखेगा कि क्या बनाया गया था और जो पहले से ही गणना की जा चुकी है उसे छोड़ दें); सामग्री-जागरूक हैशिंग (सामग्री-जागरूक हैशिंग - टर्बोरेपो फाइलों की सामग्री को देखता है, टाइमस्टैम्प पर नहीं, यह पता लगाने के लिए कि क्या बनाया जाना चाहिए); रिमोट कैशिंग (रिमोट हैशिंग - टीम और सीआई / सीडी के साथ और भी तेज बिल्ड के लिए रिमोट बिल्ड कैश साझा करें।); कार्य पाइपलाइन (एक कार्य पाइपलाइन जो कार्यों के बीच संबंधों को परिभाषित करती है और फिर अनुकूलित करती है कि क्या और कब बनाना है।) समानांतर निष्पादन (निष्क्रिय सीपीयू बर्बाद किए बिना, अधिकतम समांतरता के साथ प्रत्येक कोर का उपयोग करके बनाता है)। हमने प्रलेखन से एक मोनोरेपो आयोजित करने की सिफारिश भी ली और इसे अपने मंच पर लागू किया। यानी, हम अपने सभी पैकेजों को ऐप्स और पैकेज में विभाजित करते हैं। ऐसा करने के लिए, हम PNPM-workspace.yaml फ़ाइल भी बनाते हैं और लिखते हैं: पीएनपीएम-वर्कस्पेस.यामल packages: 'apps/**/*' 'packages/**/*' यहाँ आप पहले और बाद में हमारी संरचना का एक उदाहरण देख सकते हैं: अब हमारे पास अनुकूलित कार्यक्षेत्र और सुविधाजनक कोड पुन: उपयोग के साथ एक मोनोरेप है। मैं कुछ और बिंदु जोड़ूंगा जो हमने समानांतर में किए। मैंने पहले दो चीजों का उल्लेख किया था: हमारे पास क्रोम एक्सटेंशन था, और हमने फैसला किया - हम एक मंच बना रहे थे। चूँकि हमारे प्लेटफ़ॉर्म ने प्राथमिकता के रूप में Shopify के साथ काम किया, इसलिए हमने तय किया कि Chrome के लिए एक्सटेंशन या इसके अलावा, Shopify के लिए एक और मॉड्यूल बनाना अच्छा होगा, जिसे बस साइट पर इंस्टॉल किया जा सकता है, ताकि एक बार नहीं फिर से लोगों को मोबाइल एप्लिकेशन या क्रोम एक्सटेंशन डाउनलोड करने के लिए मजबूर करें। लेकिन इसे विस्तार को पूरी तरह से दोहराना होगा। प्रारंभ में, हमने उन्हें समानांतर में किया, लेकिन हमने महसूस किया कि हम कुछ गलत कर रहे थे, क्योंकि हमने केवल कोड को डुप्लिकेट किया था। हर मायने में हम एक ही बात को अलग-अलग जगहों पर लिखते हैं। लेकिन चूंकि अब हमारे पास सभी कार्यक्षेत्र और पुन: उपयोग कॉन्फ़िगर किए गए हैं, इसलिए हमने सब कुछ आसानी से एक पैकेज में स्थानांतरित कर दिया, जिसे हमने शोपिफाई मॉड्यूल और क्रोम एक्सटेंशन कहा। इस प्रकार, हमने अपना बहुत समय बचाया। दूसरी चीज़ जिसने हमारा बहुत समय बचाया, वह थी वेबपैक का खात्मा और कुछ जगहों पर सामान्य रूप से निर्माण। वेबपैक में क्या गलत है? वास्तव में, दो महत्वपूर्ण बिंदु हैं: जटिलता और गति। हमने जो चुना है वह विटे है। क्यों? इसे स्थापित करना आसान है, यह जल्दी से लोकप्रियता प्राप्त कर रहा है और पहले से ही बड़ी संख्या में काम करने वाले प्लगइन्स हैं, और स्थापना के लिए डॉक से एक उदाहरण पर्याप्त है। इसकी तुलना में, हमारे क्रोम वेब एक्सटेंशन के वेबपैक के निर्माण में vite.js पर लगभग 15 सेकंड का समय लगा लगभग 7 सेकंड (डीटीएस फ़ाइल जनरेशन के साथ)। फर्क महसूस करो। बिल्ड की अस्वीकृति के साथ क्या है? सब कुछ सरल है, जैसा कि यह निकला, हमें वास्तव में उनकी आवश्यकता नहीं थी, क्योंकि ये पुन: प्रयोज्य मॉड्यूल हैं और package.json में, निर्यात में, आप बस dist/index.js को src/index.ts से बदल सकते हैं। यह कैसे था {... "exports": { "import": "./dist/built-index.js" }, ... } अब कैसा है { ... "types": "./src/index.ts", "exports": { ".": "./src/index.ts" }, ... } इस प्रकार, हमने उन मॉड्यूल से संबंधित एप्लिकेशन अपडेट को ट्रैक करने के लिए पीएनपीएम वॉच चलाने की आवश्यकता से छुटकारा पा लिया, और अपडेट को खींचने के लिए पीएनपीएम बिल्ड करते हैं। मुझे नहीं लगता कि यह बताने लायक है कि इसने हमारा कितना समय बचाया। वास्तव में, हमने बिल्ड एकत्र करने के कारणों में से एक टाइपस्क्रिप्ट था, अधिक सटीक रूप से index.d.ts फ़ाइलें। ताकि हमारे मॉड्यूल / पैकेज आयात करते समय, हम जान सकें कि कुछ कार्यों में किस प्रकार की अपेक्षा की जाती है या किस प्रकार के अन्य हमारे पास लौट आएंगे, जैसे कि यहां: लेकिन यह देखते हुए कि आप केवल index.tsx से निर्यात कर सकते हैं, बिल्ड को छोड़ने का एक और कारण था। टाइपस्क्रिप्ट + ग्राफक्यूएल लेकिन फिर भी, टाइपस्क्रिप्ट क्यों? मुझे लगता है कि अब टीएस के सभी फायदों का वर्णन करने का कोई मतलब नहीं है: टाइप सुरक्षा, टाइपिंग के कारण विकास प्रक्रिया को सुविधाजनक बनाना, इंटरफेस और कक्षाओं की उपस्थिति, ओपन सोर्स कोड, कोड संशोधन के दौरान की गई त्रुटियां तुरंत दिखाई देती हैं, और रनटाइम पर नहीं , और इसी तरह। जैसा कि मैंने शुरुआत में ही कहा था, हमने सब कुछ एक भाषा में लिखने का फैसला किया ताकि अगर कोई काम करना बंद कर देता है या छोड़ देता है, तो हम समर्थन या बीमा कर सकते हैं। पहले हमने JS को चुना। लेकिन जेएस बहुत सुरक्षित नहीं है, और बड़ी परियोजनाओं पर परीक्षण के बिना यह काफी दर्दनाक है। इसलिए हमने टीएस के पक्ष में फैसला किया। जैसा कि अभ्यास ने दिखाया है, यह मोनोरेपो में बहुत सुविधाजनक है, इस तथ्य के कारण कि आप केवल * .ts फ़ाइलों को निर्यात कर सकते हैं, और घटकों का उपयोग करते समय, अपेक्षित डेटा और उनके प्रकार तुरंत स्पष्ट होते हैं। लेकिन मुख्य उपयोगी विशेषताओं में से एक ग्राफक्यूएल क्वेरी और म्यूटेशन के लिए ऑटो-जेनरेशन प्रकार था। उन सभी के लिए जो बहुत जानकार नहीं हैं, ग्राफ़िकल एक ऐसी तकनीक है जो आपको एक ही क्वेरी (डेटा प्राप्त करने के लिए) और म्यूटेशन (डेटा बदलने के लिए) के माध्यम से डेटाबेस में जाने की अनुमति देती है, और कुछ इस तरह दिखती है: query getShop {shop { shopName shopLocation } } REST API के विपरीत, जहाँ जब तक आप इसे प्राप्त नहीं कर लेते, आपको पता नहीं चलेगा कि आपके पास क्या आएगा, यहाँ आप स्वयं निर्धारित करते हैं कि आपको किस डेटा की आवश्यकता है। आइए हमारे राष्ट्रपति-चुनाव पर वापस जाएं। हमने हसुरा का उपयोग किया, जो पोस्टग्रेएसक्यूएल के शीर्ष पर एक ग्राफक्यूएल आवरण है। चूंकि हम टीएस के साथ काम कर रहे हैं, इसलिए एक अच्छे तरीके से हमें दोनों अनुरोधों और पेलोड को भेजे जाने वाले डेटा को टाइप करना होगा। यदि हम उपरोक्त उदाहरण से कोड के बारे में बात कर रहे हैं, तो कोई समस्या नहीं होनी चाहिए। लेकिन व्यवहार में, एक क्वेरी सौ पंक्तियों तक पहुंच सकती है, साथ ही कुछ फ़ील्ड आ भी सकते हैं और नहीं भी, या अलग-अलग डेटा प्रकार हो सकते हैं। और इस तरह के कैनवस को टाइप करना बहुत लंबा और कृतघ्न काम है। विकल्प? बेशक मैं! आदेशों के माध्यम से प्रकार उत्पन्न होने दें। हमारी परियोजना में, हमने निम्नलिखित किया: हमने निम्नलिखित पुस्तकालयों का उपयोग किया: ग्राफ़कल और ग्राफ़कल-अनुरोध सबसे पहले *.graphql रेजोल्यूशन वाली फाइलें बनाई गईं, जिनमें क्वेश्चन और म्यूटेशन लिखे गए। उदाहरण के लिए: test.graphql query getAllShops {test_shops { identifier name location owner_id url domain type owner { name owner_id } } } आगे हमने codegen.yaml बनाया codegen.yaml schema: ${HASURA_URL}:headers: x-hasura-admin-secret: ${HASURA_SECRET} emitLegacyCommonJSImports: false config: gqlImport: graphql-tag#gql scalars: numeric: string uuid: string bigint: string timestamptz: string smallint: number generates: src/infrastructure/api/graphQl/operations.ts: documents: 'src/**/*.graphql' plugins: - TypeScript - TypeScript-operations - TypeScript-graphql-request वहां हमने संकेत दिया कि हम कहां जा रहे थे, और अंत में - जहां हम जेनरेट की गई एपीआई (src/infrastructure/api/graphQl/operations.ts) के साथ फाइल को सेव करते हैं और जहां से हमें (src/**/*. ग्राफक्यूएल)। उसके बाद, package.json में एक स्क्रिप्ट जोड़ी गई जिसने हमारे लिए समान प्रकार उत्पन्न किए: पैकेज.जेसन {... "scripts": { "generate": "HASURA_URL=http://localhost:9696/v1/graphql HASURA_SECRET=secret graphql-codegen-esm --config codegen.yml", ... }, ... } उन्होंने URL को इंगित किया कि स्क्रिप्ट ने जानकारी, रहस्य और स्वयं कमांड प्राप्त करने के लिए एक्सेस किया। अंत में, हम क्लाइंट बनाते हैं: import { GraphQLClient } from "graphql-request"; import { getSdk } from "./operations.js"; export const createGraphQlClient = ({ getToken }: CreateGraphQlClient) => { const graphQLClient = new GraphQLClient('your url goes here...'); return getSdk(graphQLClient); }; इस प्रकार, हमें एक ऐसा फ़ंक्शन मिलता है जो क्लाइंट को सभी क्वेरी और म्यूटेशन के साथ उत्पन्न करता है। Operations.ts में बोनस हमारे सभी प्रकारों को देता है जिन्हें हम निर्यात और उपयोग कर सकते हैं, और पूरे अनुरोध का एक पूरा टाइपिंग है: हम जानते हैं कि क्या देना है और क्या आएगा। कमांड चलाने और टाइपिंग की सुंदरता का आनंद लेने के अलावा आपको किसी और चीज के बारे में सोचने की जरूरत नहीं है। निष्कर्ष इस प्रकार, हमने बड़ी संख्या में अनावश्यक रिपॉजिटरी से छुटकारा पा लिया और यह जांचने के लिए कि चीजें कैसे काम करती हैं, थोड़े से बदलावों को लगातार धकेलने की जरूरत है। इसके बजाय, वे एक के साथ आए जिसमें सब कुछ संरचित है, इसके उद्देश्य के अनुसार विघटित हो गया है, और सब कुछ आसानी से पुन: उपयोग किया जाता है। इसलिए हमने अपने जीवन को आसान बना दिया और नए लोगों को प्रोजेक्ट से परिचित कराने, प्लेटफॉर्म और मॉड्यूल / एप्लिकेशन को अलग से लॉन्च करने के लिए समय कम कर दिया। सब कुछ टाइप किया गया है, और अब प्रत्येक फ़ोल्डर में जाने और यह देखने की आवश्यकता नहीं है कि यह या वह फ़ंक्शन/घटक क्या चाहता है। नतीजतन, विकास का समय कम कर दिया गया है। अंत में, मैं यह कहना चाहता हूं कि आपको कभी भी जल्दबाजी नहीं करनी चाहिए। जानबूझकर अपने जीवन को जटिल बनाने की तुलना में यह समझना बेहतर है कि आप क्या कर रहे हैं और इसे कैसे करना आसान है। समस्याएं हर जगह और हमेशा होती हैं, जल्दी या बाद में वे कहीं बाहर आ जाएंगी, और फिर जानबूझकर जटिलता आपको घुटने में गोली मार देगी, लेकिन किसी भी तरह से मदद नहीं करेगी। dev.family टीम आपके साथ थी, जल्द ही मिलते हैं!
