वेब अनुप्रयोग के क्लाइंट और सर्वर भागों की सहभागिता की वास्तुकला

मैं बताना चाहता था कि मैं सर्वर और क्लाइंट भागों के बीच बातचीत की वास्तुकला कैसे देखता हूं। और मैं खाबरोवस्क निवासियों से पूछना चाहता हूं कि यह वास्तुकला कितनी खराब या अच्छी है।

ग्राहक संरचना

यहां तक ​​कि पुराने ब्राउज़र हमें पूरी तरह कार्यात्मक इंटरैक्टिव वेब एप्लिकेशन बनाने के लिए सुविधाओं का एक सेट प्रदान करते हैं। और पुस्तकालयों जैसे jQuery के लिए धन्यवाद, जो मामूली क्रॉस-ब्राउज़र और मल्टी-प्लेटफ़ॉर्म समाधान प्रदान करते हैं, ग्राहक भागों का विकास कई बार तेज होता है। सर्वर और क्लाइंट भागों के इंटरैक्शन के लिए सबसे विविध इंटरफेस का उपयोग करते हुए, यह वेबमास्टर्स पूरी तरह से उपयोग करते हैं।

क्यों jQuery? इस लेख में, मैं इसे एक उदाहरण के रूप में उपयोग करता हूं। क्लाइंट और सर्वर के अनुप्रयोगों के इंटरैक्शन के लिए, यह कोई फर्क नहीं पड़ता कि आप क्या उपयोग करते हैं: किसी भी पुस्तकालय, अपने स्वयं के विकास या नंगे जावास्क्रिप्ट। लक्ष्य को प्राप्त करने के लिए मुख्य बात यह है: कि सब कुछ सही ढंग से काम करता है और काम करता है।

बेशक, हम में से कई ने शुरुआती लोगों के लिए लेख चक्रों के साथ jquery सीखना शुरू कर दिया, हमारी साइटों पर सामग्री के गतिशील लोडिंग की शुरुआत की, और सर्वर साइड पर रूपों की जांच की, और बहुत कुछ किया।

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

सबसे पहले। अनुरोध भेजने के लिए एकल इंटरफ़ेस बनाएँ।
ऐसा करने के लिए, अपने स्वयं के चीनी फ़ंक्शन में $ .ajax लपेटें।

बेशक, $ .ajax $ .ajaxSetup के माध्यम से कॉन्फ़िगर किया जा सकता है। और यह अधिक सुविधाजनक और व्यावहारिक है। लेकिन फिर कुछ समस्याएं उत्पन्न होती हैं।

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

  // -
$.ajaxSetup({
url: 'mysite.ru/ajax.php' ,
dataType: 'xml'
});
/* ... */
$.ajax({
url: 'ajax.mysite.ru' ,
data: {
action: 'do_something'
username: 'my_username'
},
global: false //
});


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

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

//
$.extend({
gajax: function (s) {
//
var options = {
url: "ajax.mysite.ru" ,
};
//
$.extend( options, s, { action:s.action } );
$.ajax( options );
}
});
//
$.gajax({
data: {
username: 'my_username'
},
action: 'do_something'
});


दूसरे , आपको AJAX अनुरोधों के लिए प्रवेश बिंदुओं की संख्या कम करने की आवश्यकता है। यदि अनुरोध index.php, request.pl, और upload.xml पर भेजे गए थे, तो यह बहुत बड़ी मात्रा में काम है, और अक्सर ऐसा होता है कि आप पूरे सर्वर भाग को फिर से लिखे बिना ऐसा नहीं कर सकते। हालांकि यह तब किया जाना चाहिए जब आप जल्दी और बस ग्राहक पक्ष का विस्तार करना चाहते हैं। सभी नियमों की तरह, यह एक अपवाद है। उनके बारे में थोड़ा कम।

तीसरा, सबसे महत्वपूर्ण बात : प्रतिक्रिया हैंडलर को एकजुट करना आवश्यक है।

उदाहरण के लिए, हमारी परियोजना में सभी ajax अनुरोध केवल ajax.php फ़ाइल पर जाते हैं। यह हमेशा XML के रूप में कुछ डेटा लौटाता है, काफी सरल रूप से संरचित होता है।

एक एकल प्रतिक्रिया हैंडलर XML को पार्स करता है और इसे क्रम में रखता है:

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

//
$.extend({
gajax: function (s) {
var recognize = function ( xml, s ) {
/* , */
// xml ( jQuery XML, )
// js-,
// ,
// callback`
// html
};
//
var options = {
url: "ajax.mysite.ru" ,
success: function (xml){
recognize( xml, s );
}
};
$.extend( options, s, { action:s.action } );
$.ajax( options );
}
});



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

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

जब सभी स्क्रिप्ट लोड हो जाती हैं, तो कॉलबैक फ़ंक्शन चलाएं।

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

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

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

कार्य पूरा हो गए हैं, उपयोगकर्ता जारी है।

सर्वर अनुरोध प्रसंस्करण

अब मैं उस स्थिति को पार्स करना चाहूंगा जब एक अनुरोध भेजा गया था कि सर्वर किसी कारण से पार्स नहीं कर सकता है।

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

ग्राहक की तरफ से गलत अनुरोधों को संभालना

हमें असफल अनुरोधों के प्रसंस्करण के बारे में नहीं भूलना चाहिए, उदाहरण के लिए, नेटवर्क से उपयोगकर्ता के समय-समय पर या अचानक वियोग।

//
var options = {
url: "ajax.mysite.ru" ,
success: function (xml){
recognize( xml, s );
},
error: function ( s,err ){
//
if ( s.status == 200 && err == 'parsererror' ) {
alert( s.responseText );
}
//
else if ( err == 'timeout' ) {
alert( 'Connection to the server was reset on timeout.' );
}
// - .
else if ( s.status == 12029 || s.status == 0 ) {
alert( 'No connection with network.' );
}
};


कैशिंग

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

हर चीज को खूबसूरती से कैसे किया जा सकता है? - विशिष्ट पते पर अनुरोध भेजें। उदाहरण के लिए, ajax.php? क्रिया = प्रतिक्रिया या ajax.example.com/feedback। इससे अनावश्यक कचरे के अनुरोध को बचाया जा सकेगा। जब एक मॉड्यूल परिभाषित किया जाता है जो डेटा को संसाधित करेगा, तो उसे अब इस जानकारी की आवश्यकता नहीं है। अलग से मक्खियों, अलग से कटलेट। क्या यह सुंदर है? खूबसूरती से।

यदि अनुरोध में कोई POST पैरामीटर नहीं हैं, तो यह मध्यवर्ती प्रॉक्सी या ब्राउज़र कैश पर कैश सुविधाओं का उपयोग करने का एक अच्छा अवसर है।
वेबमास्टर्स के लिए Google की एक सिफारिश में कहा गया है कि http अनुरोध में जीईटी मापदंडों की कमी प्रॉक्सी सर्वर को कैश का उपयोग करने के लिए उकसाती है। इसलिए, POST और GET मापदंडों के बिना एक अनुरोध, उदाहरण के लिए ajax.mysite.com/footer, प्रॉक्सी सर्वर द्वारा कैश में जोड़ने के लिए आदर्श होगा। अतिरिक्त लाभों में से, मैं ध्यान देता हूं कि यदि प्रतिक्रिया एक प्रॉक्सी सर्वर से है, तो यह हमारे सर्वर को थोड़ा बोझिल करेगा।
इसकी आवश्यकता कब हो सकती है? जब हम पेज के कुछ हिस्सों को अजाक्स के माध्यम से लोड करते हैं। हालांकि, वे समय के साथ अपरिवर्तित हैं।

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

कैशिंग के मामलों में, हर बार आपको व्यक्तिगत रूप से संपर्क करने और परियोजना के लिए आवश्यक चीजों का उपयोग करने की आवश्यकता होती है।

एक साइकिल का आविष्कार

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

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

अंत में

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

पोस्ट को नैनोस्कॉन्ड्स को बचाने और प्रोग्रामर के कई तंत्रिका कोशिकाओं को उनकी सुंदर रचनाओं को बनाने के नाम पर लिखा गया था।