सर्वर के बिना मोबाइल एप्लिकेशन का विकास

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

यह स्थिति विभिन्न कारणों से हो सकती है। हालांकि, सबसे अधिक बार विकास की शुरुआत में, बैकएंड बस लिखा नहीं जाता है और क्लाइंट इसके बिना शुरू होता है। इस मामले में, विकास की शुरुआत में 2-4 महीने की देरी होती है

कभी-कभी सर्वर केवल क्रैश हो जाता है (क्रैश), कभी-कभी इसमें आवश्यक विधियों को रोल करने का समय नहीं होता है, कभी-कभी डेटा समस्याएं होती हैं, आदि। इन सभी समस्याओं ने हमें एक छोटी मॉकर सेवा लिखने के लिए प्रेरित किया जो आपको वास्तविक बैकएंड को बदलने की अनुमति देता है।

परिचय

एक नियम के रूप में, कोई भी क्लाइंट-सर्वर एप्लिकेशन कुछ इस तरह दिखता है:



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

1. पहले हम डिजाइन करते हैं। हम विघटित, वर्णन और चर्चा करते हैं।
2. कार्यों और आवश्यकताओं को प्राप्त करने के बाद, हम विकास शुरू करते हैं। हम कोड, टाइपसेट आदि लिखते हैं।
3. हमने कुछ लागू करने के बाद, एक असेंबली तैयार की जा रही है, जो मैन्युअल परीक्षण में जाती है, जहां विभिन्न मामलों के लिए आवेदन की जांच की जाती है।
4. यदि हमारे साथ सब कुछ ठीक है, और परीक्षक विधानसभा का परीक्षण करते हैं, तो यह ग्राहक के पास जाता है जो स्वीकृति देता है।

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

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

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

उदाहरण के लिए, हम यह जांचना चाहते हैं कि यदि उपयोगकर्ता का भुगतान नियत तारीख से अधिक समय का है तो आवेदन कैसे व्यवहार करता है। सर्वर पर ऐसी स्थिति को पुन: पेश करना बहुत मुश्किल (और लंबा) है और हमें इसे कृत्रिम रूप से करने की आवश्यकता है।

इसलिए, निम्नलिखित समस्याएं हैं:

1. सर्वर पूरी तरह से गायब है। इस वजह से, इसे डिजाइन, परीक्षण और प्रस्तुत करना असंभव है।
2. सर्वर के पास समय नहीं है, जो विकास में हस्तक्षेप करता है और परीक्षण में हस्तक्षेप कर सकता है।
3. हम सीमा मामलों का परीक्षण करना चाहते हैं, और सर्वर लंबे इशारों के बिना इसकी अनुमति नहीं दे सकता है।
4. परीक्षण को प्रभावित करना और प्रस्तुतियों को धमकी देना।
5. सर्वर क्रैश हो जाता है (एक बार, स्थिर विकास के दौरान, हमने 3.5 दिनों के लिए सर्वर खो दिया है)।

इन समस्याओं का सामना करने के लिए, मॉकर बनाया गया था।

कार्य सिद्धांत

Mocker एक छोटी वेब सेवा है जिसे कहीं होस्ट किया जाता है, एक विशिष्ट पोर्ट पर ट्रैफ़िक सुनता है और विशिष्ट नेटवर्क अनुरोधों के लिए पूर्व-तैयार डेटा के साथ प्रतिक्रिया कर सकता है।

अनुक्रम इस प्रकार है:

1. ग्राहक एक अनुरोध भेजता है।
2. Mocker अनुरोध प्राप्त करता है।
3. Mocker वांछित नकली पाता है।
4. मॉक वांछित मॉक लौटाता है।

यदि अंक 1,2 और 4 के साथ सब कुछ स्पष्ट है, तो 3 प्रश्न उठाता है।

यह समझने के लिए कि ग्राहक के लिए सेवा कैसे आवश्यक है, हम पहले स्वयं मॉक की संरचना पर विचार करते हैं।

निम्न प्रारूप में Mock एक JSON फ़ाइल है:

{ "url": "string", "method": "string", "statusCode": "number", "response": "object", "request": "object" } 

आइए प्रत्येक क्षेत्र का अलग-अलग विश्लेषण करें।

यूआरएल

इस पैरामीटर का उपयोग ग्राहक के अनुरोध के URL को निर्दिष्ट करने के लिए किया जाता है।

उदाहरण के लिए, यदि कोई मोबाइल एप्लिकेशन host.dom/path/to/endpoint को url करने का अनुरोध करता है, तो url फ़ील्ड में हमें /path/to/endpoint लिखने की आवश्यकता है।
यही है, यह फ़ील्ड समापन बिंदु के सापेक्ष पथ को संग्रहीत करता है।

इस फ़ील्ड को url- टेम्प्लेट प्रारूप में स्वरूपित किया जाना चाहिए, अर्थात् निम्नलिखित प्रारूप की अनुमति है:

1. /path/to/endpoint - सामान्य यूआरएल पता। जब अनुरोध प्राप्त होता है, तो सेवा चरित्र द्वारा वर्ण की तुलना करेगी।
2. /path/to/endpoint/{number} - पथ पैटर्न के साथ यूआरएल। इस तरह के URL वाला Mock इस पैटर्न से मेल खाने वाले किसी भी अनुरोध का जवाब देगा।
3. /path/to/endpoint/data?param={value} - पैरामीटर-पैटर्न के साथ यूआरएल। इस तरह के एक यूआरएल के साथ नकली दिए गए मापदंडों वाले एक अनुरोध को ट्रिगर करेगा। इसके अलावा, यदि कोई पैरामीटर अनुरोध में नहीं है, तो यह टेम्पलेट से मेल नहीं खाएगा।

इस प्रकार, URL मापदंडों को नियंत्रित करके, आप स्पष्ट रूप से निर्धारित कर सकते हैं कि एक निश्चित नकली एक विशिष्ट यूआरएल पर वापस आ जाएगा।

विधि

यह अपेक्षित http विधि है। उदाहरण के लिए POST या GET ।
स्ट्रिंग में केवल बड़े अक्षर होने चाहिए।

statusCode

यह प्रतिक्रिया के लिए http स्थिति कोड है। यही है, इस नकली का अनुरोध करके, क्लाइंट को स्टेटसकोड फ़ील्ड में दर्ज की गई स्थिति के साथ एक प्रतिक्रिया प्राप्त होगी।

प्रतिक्रिया

इस फ़ील्ड में JSON ऑब्जेक्ट शामिल है जिसे क्लाइंट को उसके अनुरोध के जवाब में दिया जाएगा।

प्रार्थना

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

 { "url": "/auth", "method": "POST", "statusCode": 200, "response": { "token": "cbshbg52rebfzdghj123dsfsfasd" }, "request": { "login": "Tester", "password": "Valid" } } 

 { "url": "/auth", "method": "POST", "statusCode": 400, "response": { "message": "Bad credentials" }, "request": { "login": "Tester", "password": "Invalid" } } 

यदि ग्राहक शरीर के साथ एक अनुरोध भेजता है:

 { "login": "Tester", "password": "Valid" } 

फिर जवाब में वह प्राप्त करेगा:

 { "token": "cbshbg52rebfzdghj123dsfsfasd" } 

और अगर हम जांचना चाहते हैं कि आवेदन कैसे काम करेगा यदि पासवर्ड गलत तरीके से दर्ज किया गया है, तो शरीर के साथ एक अनुरोध भेजा जाएगा:

 { "login": "Tester", "password": "Invalid" } 

फिर जवाब में वह प्राप्त करेगा:

 { "message": "Bad credentials" } 

और हम गलत पासवर्ड के साथ मामले की जांच कर सकते हैं। और इसलिए अन्य सभी मामलों के लिए।

और अब हम यह पता लगाएंगे कि वांछित moq के काम को कैसे समूहीकृत करना और खोजना है।



वांछित मॉक को जल्दी और आसानी से खोजने के लिए, सर्वर सभी मोकों को मेमोरी में लोड करता है और उन्हें सही तरीके से समूहित करता है। ऊपर दी गई तस्वीर समूहीकरण का एक उदाहरण दिखाती है।

सर्वर url और विधि द्वारा अलग-अलग मोकों को जोड़ता है। यह आवश्यक है, अन्य चीजों के बीच, ताकि हम एक यूआरएल पर कई अलग-अलग मोक्स बना सकें।

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

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

 { "url": "/products", "method": "GET", "statusCode": 200, "response": { "name": "product", "currency": 1, "value": 20 } } 

 { "url": "/products", "method": "GET", "statusCode": 200, "response": { "name": "gdshfjshhkfhsdgfhshdjgfhjkshdjkfsfgbjsfgskdf", "currency": 5, "value": 100000000000 } } 

 { "url": "/products", "method": "GET", "statusCode": 200, "response": null } 

 { "url": "/products", "method": "GET", "statusCode": 400, "response": null } 

फिर, जब हम पहली बार GET / उत्पादों की विधि कहते हैं, तो हमें पहले उत्तर मिलेगा:

 { "name": "product", "currency": 1, "value": 20 } 

जब हम दूसरी बार कॉल करते हैं, तो इट्रेटर पॉइंटर अगले तत्व पर शिफ्ट हो जाएगा और हमारे पास लौटेगा:

 { "name": "gdshfjshhkfhsdgfhshdjgfhjkshdjkfsfgbjsfgskdf", "currency": 5, "value": 100000000000 } 

और हम जांच सकते हैं कि अगर हमें कुछ बड़े मूल्य मिलते हैं तो आवेदन कैसे व्यवहार करता है। और इसी तरह।

खैर, और जब हम अंतिम तत्व को प्राप्त करते हैं और फिर से विधि को कॉल करते हैं, तो पहला तत्व फिर से हमारे पास वापस आ जाएगा, क्योंकि इट्रेटर पहले तत्व पर वापस आ जाएगा।

कैशिंग प्रॉक्सी

Mocker प्रॉक्सी मोड को कैशिंग करने का काम कर सकता है। इसका मतलब यह है कि जब कोई सेवा किसी क्लाइंट से अनुरोध प्राप्त करती है, तो वह उस होस्ट का पता निकालती है, जिस पर वास्तविक सर्वर स्थित है और स्कीम (प्रोटोकॉल का निर्धारण करने के लिए)। फिर उसे प्राप्त अनुरोध (उसके सभी शीर्षकों के साथ, इसलिए यदि विधि को प्रमाणीकरण की आवश्यकता होती है, तो यह ठीक है, आपका Authorization: Bearer ... स्थानांतरित Authorization: Bearer ... ) और उससे सेवा जानकारी (उसी host और scheme ) को काट देता है और वास्तविक सर्वर को अनुरोध भेजता है।

200 वें कोड के साथ प्रतिक्रिया प्राप्त करने के बाद, मॉकर ने मॉक फाइल के उत्तर को सहेजा (हां, आप इसे तब कॉपी या बदल सकते हैं) और क्लाइंट को वापस आ जाता है जो इसे वास्तविक सर्वर से प्राप्त होता है। इसके अलावा, यह न केवल फ़ाइल को एक यादृच्छिक स्थान पर सहेजता है, बल्कि फ़ाइलों को व्यवस्थित करता है ताकि आप तब उनके साथ मैन्युअल रूप से काम कर सकें। उदाहरण के लिए, Mocker निम्नलिखित URL पर एक अनुरोध भेजता है: hostname.dom/main/products/loans/info । फिर यह एक hostname.dom फ़ोल्डर बनाएगा, फिर इसके अंदर यह एक main फ़ोल्डर बनाएगा, इसके अंदर एक products फ़ोल्डर ...

डुप्लिकेट मोक्स से बचने के लिए, नाम का निर्माण http-method (GET, PUT ...) और असली सर्वर के रिस्पांस बॉडी से हैश के आधार पर किया जाता है। इस मामले में, यदि पहले से ही एक विशिष्ट उत्तर पर एक नकली है, तो यह बस ओवरराइट किया जाएगा।

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

 X-Mocker-Redirect-Is-On: "true", X-Mocker-Redirect-Host: "hostaname.ex:1234", X-Mocker-Redirect-Scheme: "http" 

मोक्स के लिए मार्ग का स्पष्ट संकेत

कभी-कभी आप चाहते हैं कि मॉकर केवल उन मोक को लौटाएं जो हम चाहते हैं, और न कि परियोजना में सभी।

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

अब यह संभव है। इस फ़ंक्शन को सक्षम करने के लिए, आपको एक विशेष शीर्ष लेख का उपयोग करने की आवश्यकता है:

 X-Mocker-Specific-Path: path 

उदाहरण के लिए, मॉकर के मूल में इस तरह की एक फ़ोल्डर संरचना है

 root/ block_card_test_case/ mocks.... main_test_case/ blocked_test_case/ mocks... 

यदि आपको अवरुद्ध कार्ड के बारे में एक परीक्षण मामला चलाने की आवश्यकता है, तो
X-Mocker-Specific-Path: block_card_test_case
यदि आपको मुख्य स्क्रीन लॉक करने से जुड़े एक परीक्षण मामले को चलाने की आवश्यकता है, तो
X-Mocker-Specific-Path: main_test_case/blocked_test_case

इंटरफ़ेस

पहले तो हमने सीधे ssh के माध्यम से मोक के साथ काम किया, लेकिन मोक और उपयोगकर्ताओं की संख्या में वृद्धि के साथ, हमने एक अधिक सुविधाजनक विकल्प पर स्विच किया। अब हम CloudCommander का उपयोग कर रहे हैं।
डॉकटर-कंपोज उदाहरण में, यह मॉकटर कंटेनर से जुड़ा हुआ है।

यह कुछ इस तरह दिखता है:



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



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

तैनाती

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

हालांकि, यदि यह विकल्प आपको सूट नहीं करता है, तो आप स्रोत से स्वतंत्र रूप से सेवा को इकट्ठा कर सकते हैं। इसके लिए पर्याप्त:

 git clone https://github.com/LastSprint/mocker.git cd mocker go build . 

फिर आपको एक कॉन्फ़िगर फ़ाइल ( उदाहरण ) लिखने और सेवा शुरू करने की आवश्यकता है:

 mocker config.json 

ज्ञात मुद्दे

• प्रत्येक नई फ़ाइल के बाद, आपको curl mockerhost.dom/update_models करने की आवश्यकता है ताकि सेवा फिर से फ़ाइलों को पढ़े। मुझे इसे अद्यतन करने का एक त्वरित और सुरुचिपूर्ण तरीका नहीं मिला
• कभी-कभी CloudCommander बग्स (या मैंने कुछ गलत किया है) और यह संपादन moki की अनुमति नहीं देता है जो वेब इंटरफ़ेस के माध्यम से बनाए गए थे। ब्राउज़र कैश को साफ़ करके इसका इलाज किया जाता है।
• सेवा केवल application/json साथ काम करती है। योजनाएं form-url-encoding समर्थन करती हैं।

परिणाम

Mocker एक वेब सेवा है जो क्लाइंट-सर्वर अनुप्रयोगों के विकास की समस्याओं को हल करती है जब सर्वर किसी कारण से तैयार नहीं होता है।

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

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

मुझे उम्मीद है कि यह लेख उन लोगों की मदद करेगा जो समान समस्याओं से पीड़ित हैं और शायद, हम इस उपकरण को विकसित करने के लिए मिलकर काम करेंगे।

गिटहब भंडार ।