हमने ग्राफक्यूएल में विरासत परियोजना का अनुवाद कैसे किया

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

संक्षिप्त परिचय

"लीगेसी"। मुझे लगता है कि हर किसी ने इस भयानक शब्द को सुना, और सबसे आमने-सामने मिले। इसलिए, आपको यह बताने की जरूरत नहीं है कि अपनी विरासत परियोजना में नई और महान सुविधाओं को एकीकृत करना कितना मुश्किल है।



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

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

तकनीकी बिंदु

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

टास्क अपघटन

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

• GameInfo - में लॉटरी गेम और ड्रॉ के बारे में जानकारी शामिल है।
• ड्राइन्फो - इसमें सर्कुलेशन पर डेटा होता है

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

कुल मिलाकर, ग्राफकॉल कार्यान्वयन के तीन चरणों को प्रतिष्ठित किया जा सकता है:

• ग्राहक निर्माण;
• लिगेसी मॉडल के लिए एक इनिशाइज़र बनाना;
• GraphQL के साथ एपीआई अनुरोधों की जगह।

GraphQLClient

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

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

enum GraphQLRequest { case image(ImageId?) } 

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

 func fetch<Response>(requestType: GraphQLRequest, completion: @escaping (QLRequestResult<Response>) -> Void) 

QLRequestResult क्या है? यह साधारण है

  typealias QLRequestResult<Response> = Result<Response, APIError> 

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

  private func fetchGameInfo<Response>(gameId: String? = "", completion: @escaping (QLRequestResult<Response>) -> Void) { //   Apollo  let query = GetLotteriesQuery(input: gameId) //       apolloClient.fetch(query: query, cachePolicy: .returnCacheDataAndFetch, queue: .global()) { result in switch result { case .success(let response): guard let gamesQL = response.data?.games, let info = gamesQL.info else { completion(.failure(.decodingError)) return } //    let infos: [Games.Info] = info.compactMap({ gameInfo -> Games.Info? in guard let gameIdRaw = gameInfo?.gameId, let gameId = GameId(rawValue: gameIdRaw), let bonusMultiplier = gameInfo?.bonusMultiplier, let maxTicketCost = gameInfo?.maxTicketCost, let currentDraws = gameInfo?.currentDraws else { return nil } let currentDrawsInfo = Games.Info.CurrentDrawsInfo(currntDraw: currentDraws) let gameInfo = Games.Info(gameId: gameId, bonusMultiplier: bonusMultiplier, maxTicketCost: maxTicketCost, currentDraws: currentDrawsInfo) return gameInfo }) //    let games = Games(info: infos) guard let response = games as? Response else { completion(.failure(.decodingError)) return } completion(.success(response)) case .failure(let error): … } } } 

नतीजतन, हमें ग्राफक्यूएल से प्राप्त एक तैयार-निर्मित, पुराना मॉडल मिलता है।

स्केलर प्रकार

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

क्लाइंट लिखते समय, मैं एक समस्या में भाग गया कि मेरी योजना में एक स्केलर टाइप लॉन्ग था, जो अनिवार्य रूप से था

 typealias Long = Int64 

सबकुछ ठीक हो जाएगा, लेकिन अपोलो स्वचालित रूप से सभी उपयोगकर्ता स्केलर को स्ट्रिंग में डाल देता है, जिससे दुर्घटना होती है। मैंने इस तरह की समस्या को हल किया:

• मैंने कोडजेन लिपि में जोड़ा है -passthroughCustomScalars
• टाइपेलियास के लिए एक अलग फाइल बनाई गई
• फाइल करने के लिए जोड़ा गया
  

   public typealias Long = Int64 

भविष्य में, प्रत्येक स्केलर प्रकार के लिए, आपको एक नया टाइपेलियास जोड़ना होगा। अपोलो संस्करण 14.0 के साथ, उन्होंने "इंट कस्टम स्केलर्स के लिए समर्थन" जोड़ा। यदि आप कोडेन में इस दृष्टिकोण और ध्वज का उपयोग करने से बचना चाहते हैं, तो अपोलो गिट में इस समस्या का समाधान देखें।

पेशेवरों और विपक्ष

यह दृष्टिकोण अच्छा क्यों है? सभी पुराने मॉडलों को हटाने के साथ दृष्टिकोण के संबंध में, ग्राफ़िकल का उपयोग करने के लिए एक त्वरित त्वरित संक्रमण।

भविष्य में, जब हमें किसी भी स्क्रीन / मॉडल के लिए डेटा प्राप्त करने की आवश्यकता होती है, तो हम ग्राफकिनकिएंट की ओर मुड़ सकते हैं और आवश्यक डेटा प्राप्त कर सकते हैं।

Minuses की:

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

निष्कर्ष

सामान्य तौर पर, ग्राफक्लाइन पर स्विच करना एक अच्छी तरह से लिखे गए क्लाइंट के साथ त्वरित और दर्द रहित हो सकता है। मुझे लगभग तीन दिन = 24 घंटे काम करना पड़ा। इस समय के दौरान, मैं एक क्लाइंट बनाने, मॉडल का अनुवाद करने और GameInfo मॉडल को फिर से बनाने में कामयाब रहा। वर्णित दृष्टिकोण एक रामबाण नहीं है, लेकिन विशुद्ध रूप से मेरा निर्णय है, थोड़े समय में लागू किया गया।

यदि आपके बीच में एक ग्राफक्यूएल गुरु है, तो मैं आपके अनुभव को साझा करने का सुझाव देता हूं और यह बताता हूं कि बड़ी परियोजनाओं में ग्राफकॉल + अपोलो का उपयोग करना कितना सुविधाजनक है। या खेल मोमबत्ती के लायक नहीं है?

आपका ध्यान के लिए धन्यवाद!