गोलंग एपीआई फ्रेमवर्क

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

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

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

सबसे पहले, मैंने आवेदन में क्या होना चाहिए, इसके लिए एक योजना तैयार की। चूंकि लेख में मैं प्रत्येक आइटम के बारे में अलग से बात करूंगा, इसलिए मैं सबसे पहले इस सूची में से मुख्य को सामग्री के रूप में दूंगा।

• पैकेज मैनेजर चुनें
• एपीआई बनाने के लिए एक रूपरेखा चुनें
• निर्भरता इंजेक्शन (DI) के लिए उपकरण का चयन करें
• वेब अनुरोध मार्ग
• अनुरोध हेडर के अनुसार JSON / XML प्रतिक्रियाएँ
• ORM
• प्रवास
• मॉडल लेयर्स के लिए बेस क्लास बनाएं सेवा-> रिपोजिटरी-> एंटिटी
• बेसिक CRUD रिपॉजिटरी
• बेसिक CRUD सेवा
• बेसिक CRUD कंट्रोलर
• अनुरोध अनुरोध
• कन्फिग्स और पर्यावरण चर
• कंसोल कमांड
• लॉगिंग
• संतरी या किसी अन्य चेतावनी प्रणाली के साथ लकड़हारा एकीकरण
• त्रुटियों के लिए सतर्कता स्थापित करना
• DI के माध्यम से सेवाओं के पुनर्वितरण के साथ इकाई परीक्षण
• प्रतिशत और परीक्षण कवरेज कोड मानचित्र
• अकड़
• डॉकटर रचना

पैकेज प्रबंधक

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

पैकेज और उनके संस्करणों के बारे में जानकारी एक विक्रेता में जमा हो जाती है। जेसन फ़ाइल । इस दृष्टिकोण में एक ऋण भी है। यदि आप इसकी निर्भरता के साथ एक पैकेज जोड़ते हैं, तो पैकेज के बारे में जानकारी के साथ, इसकी निर्भरता के बारे में जानकारी भी फ़ाइल में मिल जाएगी। फ़ाइल तेजी से बढ़ती है और यह स्पष्ट रूप से निर्धारित करना संभव नहीं है कि कौन सी निर्भरताएं मुख्य हैं और कौन सी डेरिवेटिव हैं।

PHP कंपोज़र या npm में, मुख्य निर्भरताएं एक फ़ाइल में वर्णित हैं, और सभी मुख्य और व्युत्पन्न निर्भरताएं और उनके संस्करण स्वचालित रूप से लॉक फ़ाइल में दर्ज किए जाते हैं। यह दृष्टिकोण मेरी राय में अधिक सुविधाजनक है। लेकिन अभी के लिए, मेरे लिए govendor कार्यान्वयन पर्याप्त है।

ढांचा

फ्रेमवर्क से मुझे अधिक, एक सुविधाजनक राउटर, अनुरोधों की मान्यता की आवश्यकता नहीं है। यह सब लोकप्रिय जिन में पाया गया था। वह उस पर रुक गया।

निर्भरता इंजेक्शन

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

मुझे बस इसे फोर्क करना पड़ा, क्योंकि बॉक्स के बाहर यह आपको सेवाओं को जोड़ने और उन्हें फिर से परिभाषित करने से मना करता है। और जब ऑटोटैस्ट्स लिखते हैं, तो मेरी राय में, यह कंटेनर को इनिशियलाइज़ करने के लिए अधिक सुविधाजनक है, और फिर कुछ सेवाओं को फिर से परिभाषित करें, इसके बजाय स्टब्स निर्दिष्ट करें। कांटा में, उन्होंने सेवा के विवरण को ओवरराइड करने के लिए एक विधि जोड़ी।

लेकिन अंत में, डीग के मामले में और सेवा कंटेनर के मामले में, मुझे परीक्षणों को एक अलग पैकेज में रखना पड़ा। अन्यथा, यह पता चलता है कि परीक्षण पैकेज ( go test model/service ) में अलग-अलग चलाए जाते हैं, लेकिन वे चक्रीय निर्भरता के कारण पूरे एप्लिकेशन ( go test ./... ) के लिए तुरंत शुरू नहीं होते हैं।

अनुरोध हेडर के अनुसार JSON / XML प्रतिक्रियाएँ

जिन में, मुझे यह नहीं मिला, इसलिए मैंने बस आधार नियंत्रक के लिए एक विधि जोड़ी जो अनुरोध हेडर के आधार पर प्रतिक्रिया उत्पन्न करता है।

 func (c BaseController) response(context *gin.Context, obj interface{}, code int) { switch context.GetHeader("Accept") { case "application/xml": context.XML(code, obj) default: context.JSON(code, obj) } } 

ORM

ओआरएम के साथ पसंद की लंबी पीड़ा महसूस नहीं हुई। से चुनने के लिए बहुत कुछ था। लेकिन सुविधाओं के वर्णन के अनुसार, मुझे GORM पसंद है, जो चयन के समय सबसे लोकप्रिय में से एक है। सबसे अधिक इस्तेमाल होने वाले DBMS के लिए समर्थन है। कम से कम PostgreSQL और MySQL तो जरूर हैं। इसमें आधार स्कीमा को प्रबंधित करने के तरीके भी हैं जिनका उपयोग आप माइग्रेशन बनाते समय कर सकते हैं।

प्रवास

माइग्रेशन के लिए, मैं gorm-goose पैकेज पर बस गया। मैंने विश्व स्तर पर एक अलग पैकेज रखा और इसके लिए माइग्रेशन शुरू किया। सबसे पहले, इस तरह के कार्यान्वयन को शर्मिंदा किया गया था, क्योंकि डेटाबेस से कनेक्शन को एक अलग डीबी / dbconf.yml फ़ाइल में वर्णित किया जाना था। लेकिन फिर यह पता चला कि इसमें कनेक्शन स्ट्रिंग को इस तरह से वर्णित किया जा सकता है कि मूल्य पर्यावरण चर से लिया गया है।

 development: driver: postgres open: $DB_URL 

और यह काफी सुविधाजनक है। कम से कम डॉकटर-रचना के साथ, मुझे कनेक्शन स्ट्रिंग की नकल नहीं करनी थी।

Gorm-goose भी माइग्रेशन रोलबैक का समर्थन करता है, जो मुझे बहुत उपयोगी लगता है।

बेसिक CRUD रिपॉजिटरी

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

CRUD रिपॉजिटरी निम्नलिखित इंटरफ़ेस को लागू करता है

 type CrudRepositoryInterface interface { BaseRepositoryInterface GetModel() (entity.InterfaceEntity) Find(id uint) (entity.InterfaceEntity, error) List(parameters ListParametersInterface) (entity.InterfaceEntity, error) Create(item entity.InterfaceEntity) entity.InterfaceEntity Update(item entity.InterfaceEntity) entity.InterfaceEntity Delete(id uint) error } 

अर्थात्, CRUD Create() , Find() , List() , Update() , Delete() GetModel() और GetModel() मेथड को लागू करता है।

GetModel () के बारे में। एक बुनियादी CrudRepository रिपॉजिटरी है जो बुनियादी CRUD संचालन को लागू करता है। रिपॉजिटरी में जो इसे खुद में एम्बेड करते हैं, यह इंगित करने के लिए पर्याप्त है कि उन्हें किस मॉडल के साथ काम करना चाहिए। ऐसा करने के लिए, GetModel() विधि को GORM मॉडल को वापस करना होगा। तब हमें सीआरएम विधियों में प्रतिबिंब का उपयोग करके GetModel() के परिणाम का उपयोग करना था।

उदाहरण के लिए

 func (c CrudRepository) Find(id uint) (entity.InterfaceEntity, error) { item := reflect.New(reflect.TypeOf(c.GetModel()).Elem()).Interface() err := c.db.First(item, id).Error return item, err } 

यही है, वास्तव में, इस मामले में गतिशील टाइपिंग के पक्ष में स्थिर टाइपिंग को छोड़ना आवश्यक था। ऐसे क्षणों में, भाषा में सामान्य ज्ञान की कमी महसूस होती है।

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

 listQueryBuilder ListQueryBuilderInterface 

यह बहुत मजेदार निकला। भाषा को देर से बाध्यकारी करने के लिए, जो पहले एक दोष की तरह लगता है, कोड के एक स्पष्ट अलगाव को प्रोत्साहित करता है।

बेसिक CRUD सेवा

यहां कुछ भी दिलचस्प नहीं है, क्योंकि फ्रेमवर्क में कोई व्यावसायिक तर्क नहीं है। रिपॉजिटरी के लिए सीआरयूडी विधियों के कॉल बस अनुमानित हैं ।

सेवाओं की परत में, व्यावसायिक तर्क को लागू किया जाना चाहिए।

बेसिक CRUD कंट्रोलर

नियंत्रक CRUD विधियों को लागू करता है। वे अनुरोध से मापदंडों को संसाधित करते हैं, नियंत्रण को संबंधित सेवा पद्धति में स्थानांतरित किया जाता है, और सेवा की प्रतिक्रिया के आधार पर, क्लाइंट के लिए एक प्रतिक्रिया बनाई जाती है।

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

CRUD नियंत्रक के साथ आने वाले हाइड्रेटर में, केवल पृष्ठांकन पैरामीटर संसाधित होते हैं। विशिष्ट नियंत्रकों में जिसमें CRUD नियंत्रक एकीकृत है, हाइड्रेटर को फिर से परिभाषित किया जा सकता है।

अनुरोध अनुरोध

जिन द्वारा सत्यापन किया जाता है। उदाहरण के लिए, रिकॉर्ड बनाते समय ( Create() विधि), यह इकाई संरचना के तत्वों को सजाने के लिए पर्याप्त है

 Name string `binding:"required"` 

डेकोरेटर में वर्णित आवश्यकताओं के अनुपालन के लिए अनुरोध के मापदंडों की जांच करने के लिए फ्रेमवर्क की ShouldBindJSON() विधि ध्यान रखती है।

कन्फिग्स और पर्यावरण चर

मैं वास्तव में वाइपर के कार्यान्वयन को पसंद करता था, खासकर कोबरा के साथ संयोजन के रूप में।

मैंने मुख्य.गो में वर्णित विन्यास को पढ़ा। आधारभूत पैरामीटर जिनमें रहस्य नहीं होते हैं , उन्हें आधार .env फ़ाइल में वर्णित किया गया है । आप .enignore में जोड़ी गई .env फ़ाइल में उन्हें ओवरराइड कर सकते हैं। .Env में, आप पर्यावरण के लिए गुप्त मूल्यों का वर्णन कर सकते हैं।

पर्यावरण चर की उच्च प्राथमिकता है।

कंसोल कमांड

कंसोल कमांड के विवरण के लिए, मैंने कोबरा को चुना। थान के लिए वाइपर के साथ कोबरा का उपयोग करना अच्छा है। हम कमांड का वर्णन कर सकते हैं

 serverCmd.PersistentFlags().StringVar(&serverPort, "port", defaultServerPort, "Server port") 

और कमांड पैरामीटर के मान के लिए पर्यावरण चर को बांधें

 viper.BindPFlag("SERVER_PORT", serverCmd.PersistentFlags().Lookup("port")) 

वास्तव में, इस ढांचे का पूरा अनुप्रयोग कंसोल है। वेब सर्वर एक सर्वर कंसोल कमांड द्वारा लॉन्च किया जाता है।

 gin -i run server 

लॉगिंग

मैंने लॉगिंग के लिए लॉग्रस पैकेज चुना, क्योंकि इसमें वह सब कुछ है जो मुझे आमतौर पर चाहिए: लॉगिंग स्तर सेट करना, जहां लॉग करना, हुक जोड़ना, उदाहरण के लिए, अलर्ट सिस्टम में लॉग भेजने के लिए।

चेतावनी प्रणाली के साथ लकड़हारा एकीकरण

मैंने संतरी को चुना, क्योंकि लॉगरस के साथ तैयार एकीकरण के लिए धन्यवाद के साथ सब कुछ काफी सरल हो गया: logrus_sentry । मैंने SENTRY_DSN url के साथ संतरी SENTRY_DSN और सेंट्री SENTRY_TIMEOUT को भेजने के लिए समय सीमा SENTRY_TIMEOUT । यह पता चला कि डिफ़ॉल्ट रूप से, टाइमआउट छोटा है, यदि गलत नहीं है, तो 300 एमएस, और कई संदेश वितरित नहीं किए गए थे।

त्रुटियों के लिए सतर्कता स्थापित करना

मैंने वेब सर्वर के लिए और कंसोल कमांड के लिए अलग से पैनिक प्रोसेसिंग की।

DI के माध्यम से सेवाओं के पुनर्वितरण के साथ इकाई परीक्षण

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

 dic.InitBuilder() 

और इस तरह से स्टब्स में केवल कुछ सेवा विवरणों को फिर से परिभाषित करें

 dic.Builder.Set(di.Def{ Name: dic.UserRepository, Build: func(ctn di.Container) (interface{}, error) { return NewUserRepositoryMock(), nil }, }) 

अगला, आप एक कंटेनर का निर्माण कर सकते हैं और परीक्षण में आवश्यक सेवाओं का उपयोग कर सकते हैं:

 dic.Container = dic.Builder.Build() userService := dic.Container.Get(dic.UserService).(service.UserServiceInterface) 

इस प्रकार, हम उपयोगकर्ता सेवा का परीक्षण करेंगे, जो वास्तविक भंडार के बजाय प्रदान किए गए स्टब का उपयोग करेगा।

प्रतिशत और परीक्षण कवरेज कोड मानचित्र
मैं मानक गो परीक्षण उपयोगिता से पूरी तरह से संतुष्ट था।

आप व्यक्तिगत रूप से परीक्षण चला सकते हैं

 go test test/unit/user_service_test.go -v 

आप एक ही बार में सभी परीक्षण चला सकते हैं

 go test ./... -v 

आप एक कवरेज मैप बना सकते हैं और कवरेज के प्रतिशत की गणना कर सकते हैं

 go test ./... -v -coverpkg=./... -coverprofile=coverage.out 

और एक ब्राउज़र में परीक्षणों के साथ कोड कवरेज का एक नक्शा देखें

 go tool cover -html=coverage.out 

अकड़

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

इसलिए, मैं इस निष्कर्ष पर पहुंचा था कि गोस्वागर का उपयोग करके विनिर्देश उत्पन्न किया जा रहा है, क्योंकि इस मामले में परिचालन को विशिष्ट कार्यों से बंधे बिना वर्णित किया जा सकता है ।

 swagger generate spec -o doc/swagger.yml 

वैसे, गोस्वागर के साथ आप विपरीत से भी जा सकते हैं, और स्वैगर विनिर्देश के आधार पर वेब सर्वर कोड उत्पन्न कर सकते हैं। लेकिन इस दृष्टिकोण के साथ, ओआरएम का उपयोग करने में कठिनाइयां थीं, और मैंने अंततः इसे छोड़ दिया।

दस्तावेज़ जेन-स्वैगर का उपयोग करके उत्पन्न होता है, इसके लिए एक पूर्व-निर्मित विनिर्देश फ़ाइल इंगित की जाती है ।

डॉकटर रचना

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

आपका ध्यान के लिए धन्यवाद। इस प्रक्रिया में, मुझे भाषा की विशेषताओं के अनुकूल होना पड़ा। मुझे उन सहयोगियों की राय जानने में दिलचस्पी होगी जिन्होंने गो के साथ अधिक समय बिताया। निश्चित रूप से कुछ क्षणों को और अधिक सुरुचिपूर्ण बनाया जा सकता है, इसलिए मुझे उपयोगी आलोचना पर खुशी होगी। फ्रेम से लिंक करें: https://github.com/zubroide/go-api-boilerplate