🤷🏾 🤜🏿 🥄 बिना सिर के सी.एम.एस. मैं क्यों लिख रहा हूँ मेरा 🚗 👵 🕜

सभी को नमस्कार!

इस हालिया लेख ने मुझे इस प्रकाशन को लिखने के लिए प्रेरित किया (मैंने इसे कल देखा)।

Headless / content-first / api-first, आदि की मुख्य विशेषताओं को फिर से बताएं। मुझे CMS नहीं मिला, सामग्री भरी हुई है और शायद कई लोग पहले से ही इस प्रवृत्ति से परिचित हैं। और मैं आपको बताना चाहता हूं कि मैंने अपना सिस्टम क्यों और कैसे लिखा है, मैं मौजूदा लोगों में से क्यों नहीं चुन सकता, मैं उन अन्य प्रणालियों के बारे में क्या सोचता हूं जो मैंने पहले भी झेले हैं और इन सभी के लिए मुझे क्या संभावनाएं दिखती हैं। फिक्शन स्वैच्छिक (दो वर्षों में सामग्री के लिए) होगा, लेकिन मैं अधिक दिलचस्प और उपयोगी लिखने की कोशिश करूंगा। कौन परवाह करता है, कृपया, बिल्ली के नीचे।

सामान्य तौर पर, कहानी वास्तव में लंबी है और मैं इसे पहले बताने की कोशिश करूंगा। या तो इसे और अधिक स्पष्ट करने के लिए कि आपके स्वयं के इस इंजन को बनाने के सही कारण क्या हैं, या केवल इसलिए कि इसके बिना यह समझाना ज़मीन पर मुश्किल होगा कि मैं इसे इस तरह से क्यों कर रहा हूं, और किसी तरह नहीं।

लेकिन शुरू करने के लिए, मैं व्यक्तिगत रूप से मेरे लिए आधुनिक हेडलेस-सीएमएस के मुख्य चयन मानदंड को संक्षेप में लिखूंगा, फिर भी मैं अपने लिए तैयार समाधान क्यों नहीं चुन सका। बस इतना है कि लोग बहुत सारे मधुमक्खियों को पढ़ने के लिए नहीं टूटते हैं, यह नहीं समझते कि आखिरकार क्या कहा जाएगा।

संक्षेप में: मैं चाहता था कि सब कुछ एक ही स्थान पर हो: दोनों पीछे और सामने (और या तो यह या वह भी नहीं), और ग्राफकलाइन-एपीआई, और यह कि डेटाबेस को प्रबंधित किया जाए और "मेक ब्यूटीफुल" बटन सहित और भी बहुत कुछ। मुझे यह नहीं मिला। मैंने खुद भी अभी तक ऐसा नहीं किया है, लेकिन पूरी तरह से यह काफी बदल गया है, और सबसे महत्वपूर्ण बात यह है कि यह मुझे वास्तविक परियोजनाएं करने की अनुमति देता है।

और इसलिए, मेरे दृष्टिकोण को शायद ही वैज्ञानिक और न्यायसंगत कहा जा सकता है। तथ्य यह है कि मैं आमतौर पर बहुत कुछ अपने खुद के लिखता हूं। मुझे यहां कार्यक्रम करना पसंद है। और दो साल पहले (और एक और 8 साल पहले) मैं MODX CMF पर बैठा था (जिसके तहत मैंने अपनी बहुत सारी बैसाखियों का भी आविष्कार किया था)। और तीन साल के लिए हमने बड़े पैमाने पर एक परियोजना शुरू की, जिसके तहत, यह मुझे लग रहा था, मैं MODX का उपयोग कर सकता हूं। लेकिन जैसा कि यह निकला, मैं नहीं कर सका ... मुख्य कारण यह था कि यह बिना किसी तकनीकी आवश्यकताओं के एक स्टार्टअप था, जिसमें विचारों का एक समूह था, जो हर दिन (और कई बार एक दिन) पूरक होता था। और अब, हर बार जब एक नए विचार के तहत कुछ नई इकाई को जोड़ना, मौजूदा लोगों के लिए फ़ील्ड्स को पंजीकृत / परिवर्तित करना, इन संस्थाओं के बीच संबंध बनाना / हटाना / बदलना (क्रमशः, डेटाबेस संरचना में बदलाव के साथ), मुझे कुछ बिंदु पर है इन संस्थाओं को बदलने में कई घंटे लगने लगे। वास्तव में, इस तथ्य के अलावा कि योजना में इन परिवर्तनों को पंजीकृत करना आवश्यक था, डेटाबेस को बदलना (लगभग मैन्युअल रूप से), एपीआई को अपडेट करना, प्रोग्राम कोड को फिर से लिखना, आदि, आदि आवश्यक थे। तदनुसार, इस सब के तहत सामने को अद्यतन किया जाना था। नतीजतन, मैंने फैसला किया कि हमें कुछ नया, अधिक सुविधाजनक देखना चाहिए, जो किसी तरह यह सब सरल कर देगा। मैं एक बार फिर स्पष्ट कर दूंगा कि उस समय मैं एक php बैकएंड था, इसलिए आश्चर्यचकित न हों या हंसे नहीं कि मुझे विभिन्न फ्रंट-एंड बिल्डरों, कम प्रोसेसरों, npm, आदि की खोज शुरू हुई। आदि लेकिन वैसे भी, धीरे-धीरे हमारी परियोजना में प्रतिक्रिया + कम, ग्राफकॉल पर एक एपीआई और एक्सप्रेस पर एक सर्वर दिखाई दिया।

लेकिन सब कुछ उतना रसात्मक नहीं था जितना अब बहुतों को प्रतीत होगा। मैं आपको याद दिला दूं, यह दो साल पहले की बात है। यदि आप दो साल से कम समय के लिए आधुनिक जेएस-वेब में रहे हैं, तो मैं आपको इस लेख को पढ़ने की सलाह देता हूं: क्रिएट रिएक्ट ऐप (हब) का उपयोग करने के एन कारण । बहुत आलसी, संक्षेप में: प्रतिक्रिया-लिपियों के आगमन के साथ, आप वेबपैक को कॉन्फ़िगर करने के साथ परेशान नहीं कर सकते, आदि। यह सब पृष्ठभूमि में चला जाता है। दयालु लोग पहले से ही वेबपैक कॉन्फ़िगर कर चुके हैं ताकि अधिकांश प्रतिक्रिया परियोजनाएं उस पर काम करने की गारंटी दे सकें, और अंतिम डेवलपर निर्भरता, लोडर, आदि का एक गुच्छा कॉन्फ़िगर करने के बजाय सीधे अंतिम उत्पाद की प्रोग्रामिंग पर ध्यान केंद्रित करता है। लेकिन यह बाद में है। और इससे पहले, मुझे बस इस वेबपैक को कॉन्फ़िगर करना था, सब कुछ के ढेर के अपडेट का पालन करना जो उसे पकड़ने के लिए उसके साथ उड़ान भरी, आदि। आदि लेकिन यह काम का केवल एक हिस्सा है, केवल अनिवार्य रूप से सामने। और आपको एक सर्वर की भी आवश्यकता है। और आपको एक एपीआई की भी आवश्यकता है। और आपको एसएसआर (सर्वर-साइड रेंडरिंग) की भी आवश्यकता है, जो, वैसे, प्रतिक्रिया-स्क्रिप्ट अभी भी प्रदान नहीं करता है, जहां तक मुझे पता है। सामान्य तौर पर, सब कुछ तब और अधिक जटिल था, अब तक बहुत कुछ नहीं हुआ है, और हर कोई जितना अच्छा हो सकता है उतने ही तंग करता है। और फिर मैंने कैसे क्रैक किया ...

जरा कल्पना करें:

फ्रंट और सर्वर के लिए अलग से नेटिव वेबपैक कॉन्फ़िगरेशन।
SSR का स्वयं का कार्यान्वयन, जिससे कि async सामान्य रूप से प्रतिक्रिया-सर्वर के साथ काम करता है, और तुरंत तैयार होने वाली शैलियाँ आती हैं, और सामान्य रूप से अनुक्रमित की जाती हैं, और जिन पृष्ठों को नहीं मिला, उनके लिए सर्वर स्टेटस दिए गए।
नो-redux। खैर, मुझे रेडक्स पसंद नहीं आया। मुझे अपनी मूल प्रतिक्रिया प्रवाह का उपयोग करने का विचार पसंद आया (हालांकि मुझे इसे अपने लिए थोड़ा फिर से लिखना पड़ा)।
डेटाबेस की स्वचालित तैनाती के बिना मैन्युअल रूप से निर्धारित ग्राफ़कॉल-योजनाएं और रिज़ॉल्वर, (एपीआई सर्वर एक MODX साइट के लिए मध्य के रूप में इस्तेमाल किया गया था)।
कोई प्रतिक्रिया-अपोलो / अपोलो-क्लाइंट, आदि। सब कुछ स्वतंत्र रूप से कस्टम फ्लक्स पर आधारित ब्राउज़र में भ्रूण, रिपॉजिटरी के माध्यम से अनुरोध के साथ लिखा जाता है।

परिणामस्वरूप: अब तक, इसके पहले संस्करणों में से एक में 500+ की उपस्थिति के साथ एक परियोजना है, और सीजन (सर्दियों) में एक दिन में 1000-1700 अद्वितीय छात्र हैं। 2 महीने तक। ऐसा इसलिए है क्योंकि मैंने एक निवारक सॉफ़्टवेयर अपडेट के बाद सर्वर को मैन्युअल रूप से रिबूट किया। और इस रिबूट से पहले, अपटाइम एक और 6+ महीने था। लेकिन सबसे दिलचस्प है मेमोरी की खपत। वर्तमान में लगभग 700 मेगाबाइट js प्रक्रिया है। हाँ, हाँ, मैं आपके साथ यहाँ भी हँसी हूँ :) बेशक, यह बहुत कुछ है। और इससे पहले मैंने थोड़ी रोकथाम की और इस सूचक में सुधार किया। पहले, कुल 1000M + प्रति प्रक्रिया थी ... फिर भी, यह काम किया और काफी सहनीय था। और Google द्वारा नवंबर में पेजस्पीड इनसाइट्स एल्गोरिदम को बदलने से पहले, साइट में 97/100 प्रदर्शन मीट्रिक था। सबूत ।

इस परियोजना के आधार पर एक मध्यवर्ती निष्कर्ष जो इस परियोजना के बिना आगे विकसित हुआ (परियोजना पीछे रह गई थी):

आकर्षण आते हैं

ग्राफिंक के उपयोग से प्रोजेक्ट एपीआई और अधिक लचीला हो गया है, और सर्वर अनुरोधों की संख्या में काफी कमी आई है।
इस परियोजना के पास npm पर बड़ी संख्या में घटक हैं।
निर्भरता, गिट आदि के उपयोग से परियोजना प्रबंधन अधिक पारदर्शी हो गया है।
अंतर्निहित स्क्रिप्ट और शैलियाँ निश्चित रूप से पुरानी साइटों पर अलग-अलग लिपियों के एक समूह की तुलना में अधिक मनभावन हैं, जब आप यह नहीं जानते कि आप इस चिड़ियाघर से बिना परिणामों के क्या निकाल सकते हैं (और आप अक्सर एक साइट पर बग के कई संस्करण देखते हैं)।
साइट अधिक संवादात्मक हो गई है, पेज रिबूट किए बिना काम करते हैं, पहले देखे गए पृष्ठों पर लौटने से सर्वर को बार-बार कॉल की आवश्यकता नहीं होती है।
बिना किसी अलग व्यवस्थापक पैनल के, "जो कुछ भी आप देखते हैं और जहां आप देखते हैं उसे संपादित करें" के सिद्धांत पर सीधे डेटा संपादन पृष्ठ पर होता है।

विपक्ष (मुख्य रूप से डेवलपर के लिए)

सब कुछ बहुत जटिल है। सच में। परियोजना के लिए कुछ तृतीय-पक्ष डेवलपर को कनेक्ट करना सरल है। मैं खुद शायद ही समझ सकता हूं कि यह क्या और कैसे काम करता है और मेरे पैर कहां से बढ़ते हैं। यदि आप प्लसस के पी। 3 को देखते हैं, जहां पारदर्शिता के बारे में कहा जाता है, तो पारदर्शिता केवल इस में है कि यदि आप कहीं पर किसी चीज को हुक करते हैं, तो आप तुरंत देख सकते हैं कि क्या टूटा हुआ है (स्क्रिप्ट निर्माण नहीं करते हैं, आदि), लेकिन कमिट और भिन्नता से। आप पा सकते हैं कि कहाँ झुका। ठीक है, अगर आप कुछ नया जोड़ने में कामयाब रहे और यह काम करता है, तो कम से कम आप स्पष्ट रूप से समझते हैं कि, हां, सब कुछ ठीक है। लेकिन कुल मिलाकर यह अभी भी नारकीय नरक है।
कैशिंग के साथ कठिनाइयाँ। बाद में, मैंने अपने लिए अपोलो-क्लाइंट की खोज की। और इससे पहले, जैसा कि मैंने कहा, मैंने अपने फ्लक्स-आधारित स्टोरेज लिखे। इन भंडारणों के कारण, विभिन्न घटकों से प्रतिपादन के लिए आवश्यक डेटा प्राप्त करना संभव था, लेकिन क्लाइंट की तरफ कैश की मात्रा बहुत बड़ी थी (इकाई प्रकारों के प्रत्येक सेट का अपना भंडार था)। नतीजतन, यह सत्यापित करना मुश्किल था कि क्या वस्तु पहले अनुरोध की गई थी या नहीं (जो कि, इसे खोजने के लिए सर्वर से अनुरोध करने लायक है), क्या सभी संबंधित डेटा उपलब्ध है, आदि।
स्कीमा, डेटाबेस संरचना और रिज़ॉल्वर (डेटा प्राप्त / संशोधित करने के लिए एपीआई कार्य) के साथ कठिनाइयाँ। जैसा कि मैंने कहा, मैंने मैन्युअल रूप से योजनाएं लिखी हैं, और रिज़ॉल्वर भी। रिज़ॉल्वर में किस पर मैंने कैशिंग प्रदान करने का प्रयास किया, और नेस्टेड अनुरोधों और अन्य सूक्ष्मताओं का प्रसंस्करण। उस क्षण मुझे सार और ग्राफकॉल प्रोग्राम कोड में बहुत गहराई तक जाना पड़ा। उल्टा यह है कि मैं आम तौर पर बहुत अच्छी तरह से समझता हूं कि ग्राफकॉल कैसे काम करता है, इसके पेशेवरों और विपक्ष, और इसे बेहतर कैसे पकाना है। नकारात्मक पक्ष यह है कि निश्चित रूप से, आप उन सभी सुविधाओं और बन्स को नहीं लिख सकते हैं जो एक में अपोलो जैसी आज्ञाओं द्वारा लिखे गए हैं। नतीजतन, जब मैंने अपोलो की खोज की, निश्चित रूप से, मैंने उनके घटकों का उपयोग बड़े आनंद के साथ करना शुरू कर दिया (लेकिन मुख्य रूप से सामने की तरफ, मैं आपको नीचे बताऊंगा)।

सामान्य तौर पर, पुरानी तकनीकों का उपयोग करने वाली यह परियोजना व्यक्तिगत रूप से 100% पर है, इसलिए मैं इसे बेहतर समय तक छोड़ने का जोखिम उठा सकता हूं। लेकिन अन्य परियोजनाएं हैं जिनके लिए मुझे आगे जाना पड़ा और प्लेटफॉर्म का विकास करना पड़ा। और कई बार मुझे खरोंच से सब कुछ फिर से लिखना पड़ा। इसके अलावा, मैं उन व्यक्तिगत कार्यों के बारे में अधिक विस्तार से बात करूंगा, जिनका मैंने सामना किया और परिणामस्वरूप मैंने कौन से समाधान विकसित किए और लागू किए।

स्कीमा-पहले। पहले सर्किट, और फिर सब कुछ

एक साइट (वेब इंटरफ़ेस, पतला ग्राहक, आदि) सभी जानकारी का प्रदर्शन है (अच्छी तरह से, सूचना प्रबंधन, यदि अनुमति दी गई है और कार्यक्षमता अनुमति देती है)। लेकिन सबसे पहले, सभी एक ही, एक डेटाबेस (टेबल, कॉलम, आदि)। अपने रास्ते पर डेटाबेस के साथ काम करने के लिए कई अलग-अलग तरीकों का सामना करना पड़ा, मुझे स्कीमा-पहला तरीका सबसे ज्यादा पसंद आया। यही है, आप स्कीमा और डेटा प्रकार (मैन्युअल रूप से या इंटरफ़ेस के माध्यम से) के स्कीमा का वर्णन करते हैं, स्कीमा को तैनात करते हैं, और आपके पास डेटाबेस में वर्णित परिवर्तन (तालिकाओं / स्तंभों को बनाया / हटाए जाते हैं, साथ ही उनके बीच संबंध) होते हैं। कार्यान्वयन के आधार पर, आप इस डेटा को प्रबंधित करने के लिए सभी आवश्यक रिज़ॉल्वर फ़ंक्शन भी उत्पन्न करेंगे। इस दिशा में सबसे ज्यादा मुझे प्रिज्मा.आईओ प्रोजेक्ट पसंद आया।

आपकी अनुमति के साथ, चूंकि हब पर भी मैंने प्रिज्म के बारे में एक भी लेख नहीं देखा है, मैं उन पर थोड़ा ध्यान आकर्षित करूंगा, क्योंकि यह परियोजना वास्तव में बहुत दिलचस्प है, और उनके बिना मेरे पास अब ऐसा कोई मंच नहीं होगा, जिससे मुझे बहुत खुशी हो। । दरअसल, इसीलिए मैंने अपने प्लेटफॉर्म को प्रिज्मा-सेमी कहा, क्योंकि प्रिज्मा.आईओ इसमें बहुत बड़ी भूमिका निभाता है।

दरअसल, प्रिज्मा.आईओ एक सास प्रोजेक्ट है, लेकिन एक बड़े कैविएट के साथ: उन्होंने लगभग वह सब कुछ डाल दिया, जो वे एक गीथब पर करते हैं। यही है, आप उनके सर्वर का उपयोग बहुत ही उचित शुल्क के लिए कर सकते हैं (और कुछ ही मिनटों में अपने डेटाबेस और एपीआई को अपने लिए कॉन्फ़िगर कर सकते हैं), या आप घर पर सब कुछ पूरी तरह से तैनात कर सकते हैं। इस मामले में, प्रिज्म को तार्किक रूप से दो महत्वपूर्ण अलग-अलग भागों में विभाजित किया जाना चाहिए:

प्रिज्मा-सर्वर, यानी वह सर्वर जहां डेटाबेस भी घूम रहा है।
प्रिस्मा-ग्राहक। यह अनिवार्य रूप से एक सर्वर भी है, लेकिन डेटा स्रोत (प्रिज्मा-सर्वर) के संबंध में यह एक ग्राहक है।

अब मैं इस भ्रामक स्थिति को समझाने का प्रयास करूंगा। सामान्य तौर पर, प्रिज़्म का सार यह है कि एकल एपीआई समापन बिंदु का उपयोग करके, आप विभिन्न डेटा स्रोतों के साथ काम कर सकते हैं। हां, यहां कोई भी कहेगा कि वे सभी ग्राफकलाइन के साथ आए थे और प्रिज्मा की यहां जरूरत नहीं है। सामान्य तौर पर, हर कोई सही होगा, लेकिन एक गंभीर बिंदु है: ग्राफकलाइन केवल सिद्धांतों और समग्र काम को परिभाषित करता है, लेकिन अपने आप में, यह बॉक्स से बाहर अंतिम डेटा स्रोतों के साथ काम प्रदान नहीं करता है। वह कहते हैं, "आप यह बताने के लिए एक एपीआई बना सकते हैं कि उपयोगकर्ता क्या अनुरोध भेज सकते हैं, लेकिन आप इन अनुरोधों को कैसे संभालते हैं, यह आपको परेशान करना है।" और प्रिज्म भी, निश्चित रूप से, ग्राफकॉल का उपयोग करता है (वैसे, और विभिन्न अपोलो-उत्पादों सहित कई अन्य चीजें)। लेकिन इसके लिए प्रिज़्म प्लस डेटाबेस के साथ काम प्रदान करता है। यही है, योजना और इसकी तैनाती का वर्णन करते हुए, आवश्यक टेबल और कॉलम (साथ ही उनके बीच के रिश्ते) तुरंत निर्दिष्ट डेटाबेस में बनाए जाएंगे, और यहां तक कि तुरंत सभी आवश्यक सीआरयूडी फ़ंक्शन भी उत्पन्न करेंगे। यही है, एक प्रिज्म के साथ, आपको केवल एक ग्राफ़क सर्वर नहीं मिलता है, लेकिन एक पूर्ण-कार्यशील एपीआई जो तुरंत आपको डेटाबेस के साथ काम करने की अनुमति देता है। तो, प्रिज्मा-सर्वर इसके साथ एक डेटाबेस और इंटरैक्शन प्रदान करता है, और प्रिज्मा-क्लाइंट आपको अपने रिसॉल्वर लिखने और प्रिज्मा-सर्वर (या कहीं और, यहां तक कि कुछ प्रिज्मा-सर्वरों के लिए अनुरोध भेजने) की अनुमति देता है। और इसलिए यह पता चलता है कि आप केवल अपने आप पर प्रिज्मा-क्लाइंट को तैनात कर सकते हैं (और SaaS prisma.io को प्रिज्मा-सर्वर के रूप में उपयोग किया जाएगा), और आप अपने दम पर प्रिज्मा-सर्वर को तैनात कर सकते हैं, और आम तौर पर किसी भी तरह से प्रिज्म पर निर्भर नहीं होते हैं, यह सब अपने।

यहां मैंने अपने मंच के आधार के रूप में, अपने लिए एक प्रिज्म चुना है। लेकिन फिर मुझे एक पूर्ण मंच पाने के लिए इसे अपने लिए स्पिन करना पड़ा।

1. योजनाओं को मिलाएं

उस समय, प्रिज्म सर्किट को संयोजित करने में सक्षम नहीं था। अर्थात्, कार्य इस प्रकार है:

आपके पास एक मॉड्यूल में वर्णित उपयोगकर्ता मॉडल है

type User { id: ID! @unique username: String! @unique email: String @unique }

और एक अन्य मॉड्यूल में

 type User { id: ID! @unique username: String! @unique firstname: String lastname: String }

एक परियोजना के भाग के रूप में, आप आउटपुट प्राप्त करने के लिए इन दोनों योजनाओं को स्वचालित रूप से संयोजित करना चाहते हैं

 type User { id: ID! @unique username: String! @unique email: String @unique firstname: String lastname: String }

लेकिन तब यह प्रिज्म नहीं चल सका। यह मर्ज-ग्राफकल-स्कीमा लाइब्रेरी का उपयोग करके इसे लागू करने के लिए निकला।

मनमाना प्रिज्मा-सर्वर के साथ काम करें।

प्रिज्म में, कॉन्फ़िगरेशन को एक विशेष कॉन्फ़िगरेशन फ़ाइल में लिखा जाता है। यदि आप उपयोग किए गए प्रिज़्म सर्वर का पता बदलना चाहते हैं, तो आपको फ़ाइल को संपादित करना होगा। एक तिपहिया, सुखद नहीं। मैं कमांड में निर्दिष्ट करने के लिए URL को संभव बनाना चाहता था, उदाहरण के लिए समापन बिंदु = http: // समापन बिंदु-पता यार्न तैनात (यार्न स्टार्ट)। यह कई दिनों के लिए मारा गया था ... लेकिन अब आप किसी भी संख्या के समापन बिंदु के लिए एक प्रिज्म परियोजना का उपयोग कर सकते हैं। वैसे, अभी तक प्रिज्मा-सीएमएस आसानी से एक स्थानीय डेटाबेस के साथ भी काम करता है, यहां तक कि सास प्रिज्म सर्वर के साथ भी।

मॉड्यूल / प्लगइन्स

यह आमतौर पर पर्याप्त नहीं था। जैसा कि मैंने कहा, प्रिज्म का मुख्य कार्य विभिन्न डेटाबेस के साथ काम प्रदान करना है। और वे इस का एक उत्कृष्ट काम करते हैं। पहले से ही, वे रास्ते में MySQL, PostgreSQL, Amazon RDS और MongoDB के साथ कई और प्रकार के स्रोतों के साथ काम करने का समर्थन करते हैं। लेकिन वे कोई भी बुनियादी ढाँचा प्रदान नहीं करते हैं। अभी तक कोई बाज़ार या ऐसा कुछ नहीं है। केवल कुछ विशिष्ट रिक्त स्थान हैं। लेकिन आप कई ब्लैंक से दो या तीन का चयन नहीं कर सकते हैं और एक प्रोजेक्ट पर इंस्टॉल कर सकते हैं। हमें एक चुनना होगा। मैं चाहता था कि अंतिम परियोजना पर एक अलग संख्या में मॉड्यूल स्थापित करना संभव होगा, और यह कि जब सर्किट और रिज़ॉल्वर को तैनात किया जाता है, तो यह काम करेगा और कुल कार्यक्षमता के साथ इस तरह का एक ही प्रोजेक्ट प्राप्त करेगा। और यद्यपि अभी तक कोई ग्राफिकल इंटरफ़ेस नहीं है, लेकिन पहले से ही दो दर्जन से अधिक कार्यशील मॉड्यूल और घटक हैं जिन्हें अंतिम परियोजना पर जोड़ा जा सकता है। यहां मैं तुरंत व्यक्तिगत परिभाषाओं के बारे में थोड़ा निर्णय करूंगा: एक मॉड्यूल वह है जो पीठ पर स्थापित है (डेटाबेस और एपीआई का विस्तार करते हुए), और एक घटक वह है जो सामने की तरफ स्थापित होता है (विभिन्न इंटरफ़ेस तत्वों को जोड़ने के लिए)। अब तक, मॉड्यूल को जोड़ने के लिए कोई ग्राफ़िकल इंटरफ़ेस नहीं है, लेकिन मेरे लिए इस तरह से लिखना मुश्किल नहीं है (यह अक्सर नहीं होता है):

  constructor(options = {}) { super(options); this.mergeModules([ LogModule, MailModule, UploadModule, SocietyModule, EthereumModule, WebrtcModule, UserModule, RouterModule, ]); }

नए मॉड्यूल जोड़ने के बाद, यह केवल एक कमांड के साथ फिर से एक तैनाती करने के लिए पर्याप्त है और यह है, यहां हमारे पास पहले से ही नए टेबल / कॉलम और संवर्धित कार्यक्षमता है।

5 सामने, बैकएंड में परिवर्तन के लिए उत्तरदायी

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

5.1 एपीआई टुकड़े उत्पन्न करना

सामने, स्कीमा फ़ाइल से टुकड़े अनुरोधों में पंजीकृत हैं। जब एपीआई सर्वर पर फिर से बनाया जाता है, तो एपीआई टुकड़ों के साथ एक नई जेएस फाइल भी उत्पन्न होती है। और अनुरोधों में यह इस तरह लिखा है:

 const { UserNoNestingFragment, EthAccountNoNestingFragment, NotificationTypeNoNestingFragment, BatchPayloadNoNestingFragment, } = queryFragments; const userFragment = ` fragment user on User { ...UserNoNesting EthAccounts{ ...EthAccountNoNesting } NotificationTypes{ ...NotificationTypeNoNesting } } ${UserNoNestingFragment} ${EthAccountNoNestingFragment} ${NotificationTypeNoNestingFragment} `; const usersConnection = ` query usersConnection ( $where: UserWhereInput $orderBy: UserOrderByInput $skip: Int $after: String $before: String $first: Int $last: Int ){ objectsConnection: usersConnection ( where: $where orderBy: $orderBy skip: $skip after: $after before: $before first: $first last: $last ){ aggregate{ count } edges{ node{ ...user } } } } ${userFragment} `;

5.2 सभी घटकों के लिए एक संदर्भ

प्रतिक्रिया 16.3 एक नया संदर्भ एपीआई पेश करती है। मैंने इसे इसलिए बनाया ताकि किसी भी स्तर पर बाल घटकों में संदर्भ से पहले वांछित प्रकारों को सूचीबद्ध किए बिना एक ही संदर्भ तक पहुंचना संभव हो, लेकिन केवल स्थैतिक संदर्भ इंगित कर रहा है। PrismaCmsContext और इस ग्राहक के माध्यम से सभी आकर्षण प्राप्त करना> संदर्भ (एपीआई क्लाइंट सहित, योजना) , अनुरोध, आदि)।

5.3 गतिशील फिल्टर

मैं भी वास्तव में चाहता था। GraphQL आपको एक नेस्टेड संरचना के साथ जटिल प्रश्नों का निर्माण करने की अनुमति देता है। मैं चाहता था कि फ़िल्टर भी गतिशील हों, एपीआई-स्कीम से बने, और हमें नेस्टेड स्थिति बनाने की अनुमति दें। यहाँ क्या हुआ:

5.4 वेबसाइट बिल्डर

और अंत में, मेरे पास जो कमी थी, वह बाहरी साइट संपादक, यानी एक डिजाइनर की थी। मैं चाहता था कि सर्वर में केवल प्रदर्शन करने के लिए न्यूनतम क्रियाएं हों, और सभी अंतिम डिजाइन सामने की तरफ (राउटिंग स्थापित करने, चयन का निर्माण करने सहित) किया जाना चाहिए। यह एक अलग लेख के लिए एक विषय है, क्योंकि अन्य बातों के अलावा, मैंने अपने crutchy wysiwyg संपादक को इसके लिए शुद्ध contentEditable पर लिखा है, और बहुत सारी सूक्ष्मताएं हैं। अगर मुझे अपने अधिकारों के लिए बहाल किया जाता है और जो रुचि रखते हैं, मैं एक अलग लेख लिखूंगा।

खैर, आखिरकार, एक्शन में डिजाइनर का एक छोटा डेमो वीडियो। अभी भी काफी कच्चा है, लेकिन मुझे यह पसंद है।

मैं उस पर समाप्त करूंगा मैंने अभी तक बहुत कुछ नहीं लिखा है, जो मैं लिखना चाहूंगा, लेकिन ऐसा बहुत कुछ हुआ है। मुझे टिप्पणी करने में खुशी होगी।

पुनश्च: सभी स्रोत कोड, साइट के स्रोत कोड सहित, यहाँ हैं ।

बिना सिर के सी.एम.एस. मैं क्यों लिख रहा हूँ मेरा