सॉफ्टवेयर विकास में, एक अक्सर दिलचस्प चुनौतियों का सामना करता है, विशेष रूप से जब सख्त संसाधन प्रतिबंधों के तहत संचालन किया जाता है और एमवीपी को अपने मूल्य साबित करने से पहले लागत को कम करने का प्रयास करता है। विपरीत Geocoding 2019 के अंत में, कुछ दोस्तों के साथ, मैंने एक छोटे से आईओएस ऐप के विकास पर काम किया, जिसे नाम दिया गया था। ऐप उपयोगकर्ताओं को उन देशों की एक सूची बनाए रखने और इसे दूसरों के साथ साझा करने की अनुमति देता है. इसके पीछे की मुख्य अवधारणा यह है कि उपयोगकर्ताओं को मैन्युअल रूप से उन देशों को दर्ज करने की आवश्यकता नहीं है जिन्हें उन्होंने दौरा किया है. AWAY यह कैसे काम करता है: यदि आपके फोन में तस्वीरें हैं, तो ऐप, मीडिया पुस्तकालय के लिए अनुरोध करने और पहुंच प्राप्त करने पर, EXIF मेटाडेटा से प्रत्येक तस्वीर को लेने के स्थान की चौड़ाई और लंबाई को पढ़ सकता है। भौगोलिक संदर्भों से एक पते (इस मामले में, देश का नाम) प्राप्त करने का यह प्रक्रिया कहा जाता है संदर्भ के लिए, इस प्रक्रिया के विपरीत - एक टेक्स्टल पते से भौगोलिक समन्वय प्राप्त करना - को forward geocoding कहा जाता है। reverse geocoding तीसरे पक्ष के समाधान हमारे एमवीपी को विकसित करते समय, हमने सबसे सरल विकल्प के साथ शुरू किया जो उपलब्ध और इस्तेमाल किया गया था एप्लिकेशन काम कर रहा था, देशों को स्वचालित रूप से सूची में जोड़ा गया था, और हमने अपने पहले उपयोगकर्ताओं को आकर्षित करना शुरू किया। एप्पल का अप्रत्याशित समाधान हालांकि, हम जल्द ही महत्वपूर्ण सीमाओं का सामना करते थे. एप्पल का समाधान अपने एपीआई के लिए नेटवर्क अनुरोधों पर सख्त दर सीमाओं के कारण बहुत धीमा था, और यह समन्वयों के बैच प्रसंस्करण के लिए डिज़ाइन नहीं किया गया था. चूंकि उपयोगकर्ता मीडिया पुस्तकालयों में अक्सर हजारों तस्वीरें होती थीं, देशों को निर्धारित करने की प्रक्रिया बेहद समय लेने वाली थी, कभी-कभी पूरा करने में 30 मिनट से अधिक समय लगता था। ऐसे लंबे प्रतीक्षा समय अनिवार्य रूप से हमारे ऐप की वायरलता को खराब कर देते हैं. यात्रा की गई देशों की एक सूची को तुरंत प्राप्त करने और इसे इंस्टाग्राम या फेसबुक पर साझा करने के बजाय, उपयोगकर्ता बस प्रक्रिया को पूरा करने के लिए इंतजार किए बिना चले जाते हैं। हम एक अधिक उपयुक्त तीसरे पक्ष समाधान नहीं पा सकते थे। , , और अन्य समान एपीआई या तो एप्पल के समान समस्याएं थीं - बैच प्रसंस्करण के लिए उपयुक्त नहीं थीं और कोई समय बचाने का लाभ नहीं प्रदान करती थीं - या हमें संदर्भों की मात्रा को संभालने की आवश्यकता थी। एक उपयुक्त सर्वर किराए पर लेने की लागत के कारण बहुत महंगा हो जाएगा। Google के मैपबॉक्स नामांकन कोई सस्ती ऑफ-द-शेल विकल्प उपलब्ध होने के साथ, मैं, बैकेंड के लिए जिम्मेदार होने के नाते, अपने स्वयं के एपीआई का निर्माण करना शुरू कर दिया। GeoJSON इस परियोजना से पहले, मेरे पास भौगोलिक डेटा के साथ काम करने का कोई अनुभव नहीं था, इसलिए मुझे एप्लिकेशन विकसित करने के दौरान सब कुछ सीखना पड़ा। पहला चीज जो मुझे कार्यान्वयन के लिए आवश्यक थी, वह देश की सीमा पर जानकारी थी ताकि संदर्भों के साथ मेल खा सकें. भूगोलिक डेटा संरचनाओं को संग्रहीत करने के लिए एक व्यापक रूप से उपयोग किए गए प्रारूप है GeoJSON. GeoJSON एक विशिष्ट संरचना के साथ एक मानक JSON फ़ाइल है जो आपको क्षणिक जटिलता के बिंदुओं, रेखाओं और आकारों का वर्णन करने की अनुमति देता है। उदाहरण के लिए, मान लें कि हम इटली के क्षेत्र के बारे में जानकारी संग्रहीत करना चाहते हैं. इसके लिए, हम एक विशेष वस्तु का उपयोग करेंगे जिसे देश की सीमाओं को एक के भीतर वर्णित किया जाएगा प्रत्येक बहुमुखी एक या अधिक समन्वय जोड़ों से बना है, जहां पहला और अंतिम समन्वय जोड़े एक बंद आकार का गठन करते हुए समान हैं. पहले पैराग्राफ में वर्णित आकार को समग्र भौगोलिक क्षेत्र में जोड़ा जाएगा, इस मामले में, इटली स्वयं, सार्डिनिया के द्वीप के साथ (इस द्वीप को एक अलग बहुमुखी में वर्णित किया जाएगा). इस पैराग्राफ में समन्वयों को एक विपरीत दिशा में सूचीबद्ध किया जाना चाहिए. Feature MultiPolygon [lon, lat] पॉलिगोन के भीतर किसी भी बाद की रेटिंग वैकल्पिक है और अपवाद क्षेत्रों का प्रतिनिधित्व करती है. यह इटली द्वारा पूरी तरह से घिरा हुआ शहर-राज्य जैसे क्षेत्रों को छोड़ने के लिए आवश्यक होगा, जैसे सैन मारिनो और वेटिकन. इन रेटिंग में संदर्भों को घड़ी के अनुरूप सूचीबद्ध किया जाना चाहिए. जितने अधिक बिंदु हम निर्दिष्ट करते हैं, उतने सटीक देश की सीमाएं होंगे. मेटाडेटा, जैसे देश का नाम, एक निहित में शामिल किया जा सकता है वस्तु है। properties { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "MultiPolygon", "coordinates": [ [ // Polygon // Exterior ring, Italy [ [20, 35],[10, 30],[10, 10], ... ,[45, 20],[20, 35]], // Interior "excluding" ring, San-Marino [ [30, 20],[20, 15],[20, 25], ... ,[30, 20]] ], [ // Polygon // Exterior ring, Sardinia [ [40, 40],[20, 45], [45, 30], ... ,[40, 40]] ] ] }, "properties": { "country": "Italy", } } ] } Geodata तैयार करें एक विश्व मानचित्र बनाने के लिए, मुझे सभी राष्ट्रीय सीमाओं के समन्वय के साथ सबसे सटीक GeoJSON फ़ाइलों को स्रोत करना पड़ा, जो आश्चर्यजनक रूप से चुनौतीपूर्ण साबित हुआ। मैं विभिन्न खुले स्रोतों पर भरोसा किया, जिसमें से एकत्रित डेटा शामिल है , , और खुले भौगोलिक डेटा से , अन्य लोगों के बीच. मेरे द्वारा प्राप्त सभी डेटा के साथ एक आम समस्या इसकी गुणवत्ता थी. कभी-कभी, सीमाओं को दोहराया जाता था, विशेष रूप से क्षेत्रों के बीच राजनीतिक विवादों के मामले में. अन्य मामलों में, केवल डेटा उपलब्ध था जिसमें क्षेत्रीय जल शामिल थे, जो हमारी जरूरतों के लिए उपयुक्त नहीं था. मुझे देश के क्षेत्रों से महासागर का नक्शा निकालकर उन पानीों को बाहर करना पड़ा (विशेष रूप से हमारे लिए धन्यवाद) आवश्यक डेटा प्रदान करने के लिए). कभी-कभी, संकल्प (संयुक्तों की संख्या) भरोसेमंद भू-कोडिंग के लिए बहुत कम था, जिससे मुझे विकल्पों की तलाश करने की आवश्यकता थी। महासागरिक संस्थान npmjs.org से पैकेज नामांकन फ्लैंडर्स समुद्री संस्थान एप्लिकेशन की आवश्यकताएं काफी कठोर थीं: हमें उच्च संकल्प में किसी भी भौगोलिक क्षेत्र के लिए सटीक, अवरोधित सीमाओं की आवश्यकता थी, बिना भूमिगत जल (आधारित नक्शे पर प्रदर्शित करने के लिए), और भूमिगत जल सहित कम संकल्प सीमाओं (अधिक तेजी से और अधिक कुशल भू-कोडिंग के लिए, विशेष रूप से तटीय लाइनों के पास जहाजों पर ली गई तस्वीरों के लिए - एक समस्या हमने तीसरे पक्ष के समाधानों के साथ काम करते समय पाया)। एक सप्ताह और आधे का सावधानीपूर्वक काम करने के बाद, मैं दो उच्च संकल्प GeoJSON फ़ाइलें बनाने में कामयाब रहा। , सभी देशों की सीमाओं का वर्णन किया, उनके क्षेत्रीय जल सहित, जबकि दूसरे, प्रत्येक फ़ाइल के आकार में कई सौ मेगाबाइट थे, और अंत में, मुझे लगा कि मैंने व्यक्तिगत रूप से दुनिया के हर कोने का दौरा किया था। countries_maritime.json countries_coastline.json आग जब लॉन्च किया गया था, तो एप्लिकेशन का अद्यतन संस्करण 10,000 बैच में उपयोगकर्ता के मीडिया पुस्तकालय से पहले संसाधित नहीं किए गए सभी फोटो संदर्भों को इकट्ठा किया और उन्हें कई अनुरोधों में मेरे बैकेंड को भेजा। Node.js पर बनाए गए और AWS पर होस्ट किए गए बैकेंड ने फ़ाइल को प्रारंभ करने पर स्मृति में रखा जाता है. जब समन्वयों के एक बैच के साथ एक अनुरोध आया, तो यह फ़ाइल से संबंधित क्षेत्रों के समन्वयों को समायोजित करने के लिए पुस्तकालय, जिसमें 250 देश शामिल थे। countries_maritime.json पॉलिसी देखभाल संदर्भों की सूची को सख्ती से सत्यापित किया गया क्योंकि, जैसा कि यह पता चला, कुछ संदर्भों की अनुमति की सीमा से बाहर थी. हमने विमानों के पंखों की विशिष्ट इंस्टाग्राम शैली की तस्वीरों की गिनती से बचने के लिए 8,850 मीटर से अधिक ऊंचाई वाले संदर्भों को भी फेंक दिया (यूरिस्ट की चोटी से थोड़ा ऊपर) ( विमान आमतौर पर 9,000 मीटर से अधिक ऊंचाई पर उड़ते हैं)। जब एक मैच पाया जाता है, तो देश पहचानकर्ता से सभी संदर्भों को संसाधित करने के बाद, रिकॉर्ड किए गए पहचानकर्ताओं की सूची deduplicated किया गया था, उपयोगकर्ता के दौरे वाले देशों की सूची में जोड़ा गया था, और ग्राहक के लिए वापस किया गया था ऐप बैकेंड डेटाबेस के साथ सिंक्रनाइज़ करने के लिए। property हमारे कस्टम समाधान के लिए स्विच करने के बाद, पिक (सिंथेटिक परीक्षणों में), एक उपयोगकर्ता के मीडिया पुस्तकालय को संसाधित करने का औसत समय 20-25 सेकंड (उपयोगकर्ता पंजीकरण से लेकर यात्रा की गई देशों की सूची को वापस करने तक) तक गिर गया, और अधिक सटीक जियोकोडिंग के कारण। प्रसंस्करण की गति प्रति सेकंड 10,000 समन्वय तक पहुंच गई प्रति उपयोगकर्ता के लिए औसत देशों की संख्या 225% बढ़ी Geodata प्रबंधन जब ऐप बढ़ता रहा, तो उपयोगकर्ता सुविधा अनुरोध भेजने लगे. सबसे आम अनुरोधों में से एक प्रत्येक देश के भीतर क्षेत्रों और प्रमुख शहरों के लिए स्वचालित पहचान जोड़ना था. 250 देशों की सीमाओं के लिए उच्च गुणवत्ता वाले डेटा एकत्र करना पहले से ही मुश्किल था. हजारों क्षेत्रों और शहरों के लिए समान डेटा एकत्र करने की संभावना और भी अधिक डरावनी थी। इस समस्या को हल करने के लिए, मैंने JSON फ़ाइल से क्षेत्रों को एक Postgres तालिका में स्थानांतरित किया और भौगोलिक क्षेत्रों को प्रबंधित करने के लिए एक प्रशासनिक इंटरफ़ेस विकसित किया. इसके अलावा, मैंने अपने मूल देशों के आधार पर क्षेत्रों और शहरों के लिए सूची बनाने को स्वचालित करने के लिए कई बाहरी एपीआई के साथ प्रशासनिक पैनल को एकीकृत किया। पहला मुद्दा जो मैंने सामना किया था वह भूगोलिक क्षेत्र डेटा की निहित जटिलता थी. क्षेत्रों और शहरों के बीच कोई सार्वभौमिक रूप से स्पष्ट अंतर नहीं है, और विभिन्न देशों में प्रशासनिक विभाजन के विभिन्न स्तर हैं। , व्यवस्थात्मक केंद्रों, आबादी के आकार और आंतरिक रिश्तों के अनुसार फ़िल्टर करने के लिए शर्तों और पुनरावृत्ति कॉल का उपयोग करना. इसमें यह भी अध्ययन करना शामिल था कि भौगोलिक नोड्स, उनके रिश्तों, और निहित संरचनाओं को कैसे विभाजित और व्यवस्थित किया जाए, और कुछ गलत डेटा को सही करना। आउटपुट.de दूसरा चुनौती क्षेत्रीय सीमाओं के लिए समन्वय स्रोतों के साथ काम करते समय उत्पन्न हुई. क्षेत्रीय और शहरों के लिए osmId की सूची प्राप्त करने के बाद, मुझे उनकी सीमाओं की भूमि का निष्कर्ष निकालने की आवश्यकता थी. व्यापक खोज के बाद, मैंने उपयोग करने के लिए समाप्त किया , और लगभग पूरी तरह से अज्ञात इन स्रोतों को अपूर्ण था, इसलिए मुझे कई अनुरोध भेजने और उनके परिणामों की तुलना करना पड़ा, लौटाए गए डेटा की गुणवत्ता के आधार पर सबसे अच्छा मैच चुनें। OpenStreetMap.org पर क्लिक करें पेंटिंग.openstreetmap.fr दस्तावेज़ की कमी, जटिल डेटा रिश्तों, और स्रोतों में असंगति के बावजूद, मैं एक स्थिर समाधान बनाने में सक्षम था। प्रशासन पैनल इंटरफ़ेस अब किसी भी देश के लिए शहर और क्षेत्र सूचीों को केवल कुछ क्लिकों के साथ स्वचालित लोड करने की अनुमति देता है, जिसमें उनके मेटाडेटा और सर्वश्रेष्ठ उपलब्ध सीमा भौगोलिकता शामिल हैं. डेटा तब डेटाबेस में संग्रहीत किया जाता है, जहां इसे उपयोगकर्ता उपलब्धता, कैशिंग और भू-कोडिंग सूचकांक में शामिल करने के लिए और अधिक परिष्कृत किया जा सकता है. GeoJSON डेटा के साथ अक्सर समस्याओं को हल करने के लिए, मैंने यहां तक कि एक अंतर्निहित संपादक विकसित किया है जो विघटन, मिश्रण, छूट, और गायब सीमा भौगोलिकता को आकर्षित करने की अनुमति देता है। इन सभी उपकरणों ने हमें, केवल दो लोगों के एक टीम के साथ, क्षेत्रों और शहरों की एक डेटाबेस बनाने की अनुमति दी, जिसे हम एक महीने और आधे के भीतर उपयोगकर्ताओं को प्रस्तुत करने पर गर्व करते थे। , प्रत्येक सटीक सीमाओं के साथ, और उन उपयोगकर्ताओं की संख्या को ट्रैक करता है जिन्होंने उन्हें देखा है। वर्तमान में, ऐप 3,134 क्षेत्रों और 28,083 शहरों का समर्थन करता है Geodata को कम करें Node.js के साथ 31,467 क्षेत्रों का प्रबंधन प्रदर्शन और संसाधन सीमाओं के कारण पहले से ही सूचकांक प्रारंभिककरण चरण में असंभव हो गया था. इस चुनौती को संबोधित करने का मेरा पहला विचार GeoJSON डेटा के आकार को कम करना था, जबकि किसी भी दृश्य क्षति को कम करना था। जैसा कि मैंने पहले उल्लेख किया था, एप्लिकेशन डिस्प्ले और भू-कोडिंग के लिए आवश्यक डेटा के लिए बहुत अलग आवश्यकताएं थीं: जबकि एप्लिकेशन में चित्रण के लिए नक्शे की तैयारी मिनटों तक चले सकती थी, भू-कोडिंग डेटा की मात्रा के लिए अत्यधिक संवेदनशील थी, जिसकी गति सीधे क्षेत्रीय सीमाओं में समन्वयों की संख्या से जुड़ी थी। मैंने बहुजनों के समन्वय श्रृंखलाओं को सरल बनाने के लिए कई एल्गोरिथ्मों के साथ प्रयोग किया। पहला दृष्टिकोण था इसका अनुकूलन अस्थिर था, जिससे अलग-अलग GeoJSON फ़ाइलों के बीच साझा सीमाओं में असंगति हुई, और यह छोटे विवरणों, जैसे द्वीपों के नुकसान का कारण भी था। रैमर-डूगलस-पीउकर अंत में, (NPM पैकेज के रूप में प्रकाशित) के आधार पर GeoJSON के साथ काम करने के लिए अनुकूलित एल्गोरिथ्म। इस एल्गोरिथ्म के मौजूदा कार्यान्वयन केवल एक GeoJSON संरचना के विशिष्ट हिस्सों पर लागू किया जा सकता था, जो परिणाम स्थिरता के मुद्दे को हल करता था, लेकिन फिर भी सीमाओं की महत्वपूर्ण गिरावट और छोटे विवरणों के नुकसान का कारण बनता था। (छोड़ी तत्व के रूप में तीन पड़ोसी संदर्भों के बीच कोण के साथ), और इसे सामान्य बिंदुओं को संरक्षित करने के लिए अतिरिक्त तर्क के साथ एक झुकाव के रूप में संसाधित किया. मैंने फिर इसे अंतिम वस्तु में पुनर्निर्माण किया. इसने बिंदुओं को अधिक समान रूप से अस्वीकार करने की अनुमति दी और महत्वपूर्ण विवरणों के नुकसान को रोक दिया. मैंने अपना स्वयं का निर्माण किया कचरे के कारण हेप मैंने अपना स्वयं का निर्माण किया डेटा मात्रा को कम करने के अलावा, GeoJSON फ़ाइलों के इस पुनर्निर्माण ने डेटा के भीतर कई त्रुटियों और संघर्षों को प्रकट करने में मदद की: अविश्वसनीय संदर्भ संदर्भ। गलत संदर्भों के झटके के कारण विवादित रेंज। खाली समन्वय पैरामीटर। अतिरिक्त नींद। संदर्भों में अनावश्यक सटीकता। मैंने इन त्रुटियों के सत्यापन और सुधार को सफलतापूर्वक स्वचालित किया, आंशिक रूप से मौजूदा उपकरणों का उपयोग करके जैसे: , , , , और आंशिक रूप से अनुकूलित ऑपरेशनों को लागू करके. इनमें अलग बहुलोगों को बहुलोगों और भूमिगत संग्रहों में जोड़ना शामिल था, समन्वय संकल्प को आवश्यक स्तर तक कम करना, समन्वय दिशा को सही करना, और खाली रेंज को हटाना। पॉलिसी कटौती @ मैपबॉक्स / geojsonhint @MAPBOX / geojson-rewind के बारे में और @mapbox/geojson-extent नतीजतन, मैंने भौगोलिक डेटा प्रसंस्करण के प्रदर्शन में एक महत्वपूर्ण सुधार हासिल किया. इसके अलावा, मेरे एल्गोरिदम की स्थिरता ने नक्शे पर पड़ोसी क्षेत्रों के बीच असंगठित सरल सीमाओं की समस्या को हल किया। माइक्रोसेवे पर जाएं geodata की सरलता के माध्यम से गणना भार को कम करने के बावजूद, यह स्पष्ट हो गया कि Node.js निश्चित रूप से हमारी जरूरतों के लिए आदर्श समाधान नहीं था। व्यापक अनुसंधान के बाद, प्रदर्शन और संसाधन खपत माप सहित, मैंने अंतिम विकल्प चुना - एक सरल माइक्रोसेस जो Go के साथ बनाया गया था। पोस्टर माइक्रोसेस आर्किटेक्चर को समन्वय युग्म प्रोसेसिंग की गति को अधिकतम करने के लिए डिज़ाइन किया गया है, जबकि अनावश्यक ऑपरेशन को कम करने के लिए। अपने पहले संचालन पर, माइक्रोसेस PostgreSQL से कनेक्ट होता है और 100 वस्तुओं के बैचों में सभी प्रासंगिक GeoJSON डेटा प्राप्त करता है. यह डेटा संरचनाओं में विभाजित होता है, प्रत्येक में एक बहुजन और संबंधित क्षेत्र पहचानकर्ता होता है. इन संरचनाओं को बाद में माइक्रोसेस के पुनरारंभ पर समय बचाने के लिए एक gob फ़ाइल में कैश किया जाता है. एक बार संरचना पैटर्न बनाया गया है, एक इस प्रकार के पेड़ का उपयोग अक्सर बहुआयामी डेटा के लिए खोज सूचकांक बनाने के लिए किया जाता है, जैसे कि बहुआयामी पेड़। R पेड़ पेड़ का निर्माण करने के बाद, माइक्रोसेस एक सुनने की स्थिति में प्रवेश करता है, आने वाले अनुरोधों की प्रतीक्षा करता है। जब एक अनुरोध प्राप्त होता है, जो समन्वय जोड़ों से बना होता है मल्टीथ्रेड प्रोसेसिंग शुरू होता है. परिणाम एक अद्वितीय क्षेत्र पहचानकर्ताओं का एक श्रृंखला है जो प्रदान किए गए संदर्भों को शामिल करता है। [lat, lon] प्रत्येक समन्वय पहले R-पृथ्वी के माध्यम से एक खोज के अधीन होता है. यह खोज एक रिक्शांगल को वापस कर सकती है जिसमें एक बहुजन होता है, जिसमें संभावित रूप से समन्वय शामिल हो सकता है. यह जांचने के लिए कि क्या समन्वय वास्तव में बहुजन के अंदर है, इस एल्गोरिदम का उपयोग किया जाता है। यह लाइनरी समय में काम करता है, जिससे यह प्रक्रिया का सबसे संसाधन-संवेदनशील हिस्सा होता है. हालांकि, रेड-स्टैटिंग चेक करने से पहले, मैं जांच करता हूं कि क्या अनुरोध में अन्य समन्वयों के प्रसंस्करण के दौरान बहुजन के लिए क्षेत्र पहचानकर्ता पहले से ही पाया गया है. यदि ऐसा है, तो रेड-स्टैटिंग चेक को अनदेखा किया जाता है, जिससे सेवा के प्रसंस्करण का समय काफी कम हो जाता है। Ray-Casting एल्गोरिथ्म सभी तारों के काम पूरा होने के बाद, पहचानकर्ताओं की रेंज को Node.js परत में वापस किया जाता है. नीचे, मैंने निम्नलिखित चार्ट में वास्तुकला का प्रतिनिधित्व करने की कोशिश की है: पूरे खोज प्रक्रिया, बार-बार रेयर-स्टैटिंग चेक को छोड़ने के लिए विशिष्ट अनुकूलन के अलावा, निकटता से दर्शाता है कि PostGIS उपयोग करते समय एक समान कार्य को कैसे संभालता है सूचकांक उपहार Go microservice के आसपास बनाई गई एपीआई का उपयोग करके, तुलना में, पिछले Node.js समाधान ने नेटवर्क अनुरोधों और बैकेंड ऑपरेशनों के ओवरहेड सहित 250 क्षेत्रों के लिए लगभग 10,000 समन्वय जोड़े का प्रबंधन किया। हमने प्रति सेकंड लगभग 100,000 समन्वय जोड़े को संसाधित करने की क्षमता हासिल की प्रोसेसिंग गति में इस महत्वपूर्ण सुधार ने उपयोगकर्ताओं द्वारा देखे गए देशों की सूचीओं को बहुत तेजी से संग्रहीत करने की अनुमति दी. इसके अलावा, क्षेत्रों और शहरों को पहचानने के लिए समर्थन के साथ, उनके परिणाम ऐप ने सक्रिय उपयोगकर्ताओं में 160% वृद्धि और उपयोगकर्ता साझा करने में 107% वृद्धि देखी समाधान आज भी उपयोग में रहता है और बढ़ती मात्रा में अनुरोधों और भौगोलिक क्षेत्रों को कुशलता से संभालना जारी रखता है. उल्लेखनीय रूप से, पूरे बैकेंड रैम के एक जीबी से कम के साथ काम करता है, जिससे इसकी अनुकूलित संसाधन उपयोग दिखाई देती है.
