Lorawan-stack: गोगो प्रोटो प्लगइन भविष्य की जांच करें

सत्यापन प्लगइन हम GoGo के लिए गिराए गए समर्थन का उपयोग कर रहे हैं
https://github.com/envoyproxy/protoc-gen-validate/pull/340

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

@rvolosatovs शायद हमारे gogottn जनरेटर में सेट किए गए कस्टम विकल्पों के बारे में अधिक जानता है, लेकिन यहां मुझे हमारी प्रोटो फाइलों में स्पष्ट विकल्पों के लिए मिला है:

• हम gogoproto.customname , gogoproto.stdtime और gogoproto.stdduration और goproto_enum_prefix विकल्पों को हटाकर शुरुआत कर सकते हैं। उन्हें हटाना अपेक्षाकृत आसान है, क्योंकि गो कंपाइलर किसी भी परिणामी समस्या के बारे में तुरंत शिकायत करेगा।
• gogoproto.embed विकल्प को हटाने का मतलब यह होगा कि अब हम एम्बेडेड फ़ील्ड तक नहीं पहुंच सकते हैं (गो कंपाइलर हमें उन्हें ढूंढने में मदद करेगा), और यह कि संदेश अब कुछ इंटरफेस को संतुष्ट नहीं करते हैं (यह अधिक कठिन हो सकता है)।
• gogoproto.nullable विकल्प बहुत अधिक काम करेगा, क्योंकि हमें गेटर्स का उपयोग शुरू करना होगा, और शून्य-चेक ​​जोड़ना होगा। परिणामी समस्याएं गो कंपाइलर द्वारा पकड़ में नहीं आ सकती हैं। संभावित समाधान अस्थायी रूप से उन क्षेत्रों को निजी बनाना होगा, फिर गेटर्स/सेटर्स को फिर से लिखना और अंत में फ़ील्ड को फिर से सार्वजनिक करना।
• जो क्षेत्र काफी समस्याग्रस्त होने जा रहे हैं वे हैं gogoproto.customtype उपयोग करने वाले क्षेत्र और gogoproto.enum_stringer विकल्पों का उपयोग करने वाले एनम। उन लोगों के लिए हमने अक्सर जेएसओएन में मार्शल/अनमर्शल किए जाने के तरीके को बदल दिया है। कस्टम bytes फ़ील्ड जैसे EUI, DevAddr आदि के लिए हम प्रकार (प्रोटो संदेशों में) को string (जो बाइनरी संगत है) में बदल सकते हैं। Enums के साथ मुझे डर है कि यह JSON API को तोड़ने जा रहा है, क्योंकि अब उन्हें (UnmarshalJSON द्वारा) स्ट्रिंग्स और इनट्स दोनों के रूप में स्वीकार किया जाता है।

हो सकता है कि यह हमारे v4 एपीआई के बारे में सोचना शुरू करने का भी एक अच्छा समय है, क्योंकि मैं कल्पना कर सकता हूं कि हम कुछ और (एपीआई ब्रेकिंग) आश्चर्य खोज सकते हैं।

मुझे लगता है कि आगे बढ़ने का सबसे अच्छा तरीका यह होगा कि पहले https://github.com/alta/protopatch को आज़माएं। परिणाम के आधार पर:

• अगर हमारी सभी ज़रूरतें पूरी हो जाती हैं -> माइग्रेट करें और इसके बारे में भूल जाएं ( api निर्देशिका में बस खोज और बदलें)
• यदि केवल हमारी कुछ जरूरतों को कवर किया गया है और प्लगइन द्वारा कवर नहीं किए गए कस्टम विकल्प हैं -> हमें प्रति-विकल्प के आधार पर मूल्यांकन करना चाहिए और या तो इन कस्टम विकल्पों को हटा देना चाहिए या शायद, protopatch योगदान करना चाहिए यदि यह एक है कम प्रयास सुविधा। यह वास्तव में विकल्प पर निर्भर करता है, हालांकि - अगर हम customtype बारे में बात कर रहे हैं - कि IMO निश्चित रूप से योगदान को सही ठहराता है, लेकिन शायद stdtime जैसा कुछ - इतना नहीं।

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

1. रजिस्ट्री से *ttnpb.EndDevice (वेनिला उत्पन्न गो प्रकार) प्राप्त करें, संग्रहीत बाइनरी डेटा से deserialized
2. *ttnpb.EndDevice को T_device कनवर्ट करें, (नोट: शायद यह शुरुआत में या हमेशा के लिए केवल एक रैपर हो सकता है)
3. NS . में आंतरिक रूप से T_device उपयोग करें
4. T_device को *ttnpb.EndDevice कनवर्ट करें (नोट: यदि हम एक रैपर का उपयोग कर रहे हैं तो यह एक छोटा, बहुत तेज़ काम हो सकता है, क्योंकि हमें केवल बदले गए फ़ील्ड को संशोधित करने की आवश्यकता है और यह बाइनरी पर भी किया जा सकता है। डेटा सीधे)
5. *ttnpb.EndDevice सेट करें, बाइनरी डेटा में क्रमबद्ध करें

रेफरी भी https://github.com/TheThingsNetwork/lorawan-stack/issues/342 (जनरेटेड पॉप्युलेटर)

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

मैं इस बात से सहमत हूं कि हम हर जगह उत्पन्न प्रोटोज पर निर्भर होने के बजाय कुछ जगहों पर मध्यस्थ प्रकारों का उपयोग करने पर विचार कर सकते हैं। यह मूल रूप से डेटा ट्रांसफर ऑब्जेक्ट्स (डीटीओ: प्रोटोस, स्टोरेज के लिए भी) को डेटा एक्सेस ऑब्जेक्ट्स (डीएओ: हम उनका उपयोग कैसे करते हैं) से अलग कर रहे हैं। यदि वह मुख्य रूप से पढ़ रहा है, तो हम इंटरफेस भी घोषित कर सकते हैं और देख सकते हैं कि हम इससे कितनी दूर हैं।

उस ने कहा, मैं T_device का उपयोग करने के लिए पूरे एनएस को बदलने तक नहीं जाऊंगा, बल्कि आवश्यकतानुसार विशिष्ट structs और/या इंटरफेस।

आइए इस चर्चा को नवंबर तक ले चलते हैं

@rvolosatovs एक कस्टम JSON

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

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

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

कठिन आवश्यकता यह है कि हम अपने v3 API की संगतता को भंग न करें। भले ही हम इस स्थिति का उपयोग v4 API (कम से कम आंतरिक रूप से) पर काम करना शुरू करने के क्षण के रूप में करने का निर्णय लेते हैं, फिर भी हमें मौजूदा उपयोगकर्ताओं के लिए उस v3 API का समर्थन करते रहना होगा।

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

लेकिन मुझे लगता है कि कुछ ऐसे कदम हैं जिन्हें हम अभी उठा सकते हैं:

JSON

हमारे v3 JSON API को संगत बनाए रखने के लिए, मुझे लगता है कि हमारा पहला TODO JSON मार्शलर और अनमर्शलर उत्पन्न करने पर काम करना है जो समझते हैं कि हमारे कस्टम प्रकारों को कैसे मार्शल / अनमर्शल करना है। मुझे लगता है कि ऐसा करना वैसे भी स्मार्ट है क्योंकि प्रोटोकॉल बफ़र्स के लिए JSON प्रारूप के गो के कार्यान्वयन के लिए कोई स्थिरता का वादा नहीं है , इसलिए हम बेहतर तरीके से उस पर नियंत्रण रखते हैं। ऐसा करने से हम JSON के लिए मार्शल करते समय फील्ड मास्क पर विचार कर सकते हैं। grpc-gateway रनटाइम में हम कोडेक पंजीकृत कर सकते हैं, इसलिए हम केवल एक कोडेक लिख सकते हैं जो {gogo,golang}/protobuf के jsonpb के बजाय हमारे अपने (जेनरेट) (अन) मार्शलर्स को बुलाता है।

नए प्रोटोस उत्पन्न करें _अगले से_ पुराने वाले

मैंने पहले ही यहां कोशिश की थी: https://github.com/TheThingsNetwork/lorawan-stack/commit/a41f62d98ae7ee719b576e6fcd2009a79cd38f4c

यह प्रोटोबफ को प्रकार की रजिस्ट्री के बारे में शिकायत करता है, इसलिए हमें यह काम करने के लिए अपने पुराने प्रोटोज से golang_proto.RegisterType निकालने की आवश्यकता हो सकती है। इसे हटाने से संभावित रूप से google.protobuf.Any का समाधान बाधित हो सकता है, लेकिन हम इसका उपयोग केवल त्रुटियों और घटनाओं में करते हैं, इसलिए हम संभवतः उन विशिष्ट मामलों के लिए समाधान ढूंढ सकते हैं।

पुराने और नए प्रोटोज के बीच कनवर्ट करने के लिए फ़ंक्शन जेनरेट करें

यह केवल ट्रांज़िशन अवधि के लिए है, लेकिन दीर्घकालिक समाधान के लिए, हम समान कन्वर्टर्स जेनरेट करना चाहेंगे।

सेवाओं को एक-एक करके अपडेट करें

मैंने पहले ही कोशिश की है कि यहां एक साधारण सेवा के साथ: https://github.com/TheThingsNetwork/lorawan-stack/commit/cd7d75c8b42ad15eee1ac594ff6d0f2d5a75eb67 , लेकिन अधिक जटिल सेवाओं के लिए हमें निश्चित रूप से उन कन्वर्टर्स की आवश्यकता होगी।

ध्यान दें कि यह केवल जीआरपीसी सेवा को ही बदलता है। जीआरपीसी-गेटवे अभी भी जेएसओएन पक्ष पर पुरानी गोगो सामग्री का उपयोग करता है, और फिर आंतरिक जीआरपीसी सर्वर को कॉल करता है, जो तब नया कार्यान्वयन चलाता है।

कुछ प्रारंभिक निर्भरता अपडेट और पश्च संगतता कार्य-आसपास यहां पुश किए: https://github.com/TheThingsNetwork/lorawan-stack/compare/issue/2798-codec

हमारी अधिक से अधिक निर्भरताएँ प्रोटोबफ़ 1.4 और V2 API में अपग्रेड हो रही हैं, और जितनी देर हम इसे खुला रखेंगे, हमारी निर्भरता को अपग्रेड करने का प्रयास करते समय हमें उतनी ही अधिक समस्याएं होंगी।

हमें वास्तव में इसे कुछ और प्राथमिकता देनी चाहिए और यह निर्णय लेना चाहिए कि हम इस सब के बारे में क्या करने जा रहे हैं।

कृपया अगले सप्ताह के लिए कॉल की योजना बनाएं ताकि हम ऑफ़लाइन चर्चा कर सकें।

मुझे लगता है कि हमें इस दर्द प्रक्रिया से गुजरना चाहिए और इसे एक या दो सप्ताह में हल करने पर ध्यान देना चाहिए। और इससे बचने के लिए हम अन्य चीजें करते हैं क्योंकि इससे अन्यथा बहुत सारे संघर्ष हो सकते हैं। जितना संभव हो उतने हाथ रखने के लिए यह जानना आवश्यक है कि हम किन मामलों में क्या करने जा रहे हैं, कार्यों को यथासंभव विभाजित करना और पुरस्कार पर नजर रखना।

अगले कदम:

1. @rvolosatovs टूलिंग को "वेनिला" के जितना संभव हो
   
   
   
   • unconvert , gofumpt जैसी चीजों को हटा दें और जो कुछ भी हम प्रोटोकॉल के शीर्ष पर कर रहे हैं उसे हटा दें
   
   
   • protoc-gen-gogottn से protoc-gen-gofast पर स्विच करें (या जो भी वैनिला के सबसे करीब हो)
   
   
   • हमारी प्रोटो फाइलों में स्पष्ट रूप से (gogoproto.*) विकल्प जोड़ें, ताकि वे अभी के समान ही प्रस्तुत करें
   
   
2. हमें सीधे फील्ड एक्सेस के बजाय गेटर्स का उपयोग करने के लिए अपने कोड को रिफलेक्टर करने की आवश्यकता है। शायद gopls और rf जैसे टूल इसमें मदद कर सकते हैं।
3. हम एक-एक करके (gogoproto.*) विकल्पों को हटाना शुरू करते हैं और इसका उपयोग करने वाले कोड को अपडेट करते हैं। शायद gopls और rf जैसे टूल इसमें मदद कर सकते हैं।
   
   
   
   • gogoproto.populate निकालना और परीक्षण अपडेट करना (https://github.com/TheThingsNetwork/lorawan-stack/issues/342)
   
   
   • gogoproto.customname हटाना और EUI -> Eui आदि को बदलना।
   
   
   • gogoproto.embed निकाला जा रहा है. हमें यह सुनिश्चित करने की ज़रूरत है कि संदेश अभी भी ValidateContext(context.Context) error और ExtractRequestFields(m map[string]interface{}) जैसे इंटरफेस लागू करते हैं।
   
   
   • gogoproto.nullable हटाना और यह सुनिश्चित करना कि हम जहां संभव हो गेटर्स का उपयोग करें, और अन्यथा शून्य जांच करें।
   
   
   • ...
   
   

@rvolosatovs आइए