1सी वेब क्लाइंट के बारे में

1C:एंटरप्राइज़ तकनीक की एक अच्छी विशेषता यह है कि प्रबंधित फॉर्म तकनीक का उपयोग करके विकसित एप्लिकेशन समाधान को विंडोज, लिनक्स, मैकओएस एक्स के लिए एक पतले (निष्पादन योग्य) क्लाइंट और 5 ब्राउज़रों के लिए एक वेब क्लाइंट के रूप में लॉन्च किया जा सकता है - क्रोम, इंटरनेट एक्सप्लोरर, फ़ायरफ़ॉक्स, सफारी, एज, और यह सब एप्लिकेशन स्रोत कोड को बदले बिना। इसके अलावा, बाह्य रूप से पतले क्लाइंट और ब्राउज़र में एप्लिकेशन कार्य करता है और लगभग समान दिखता है।
10 अंतर खोजें (कट के नीचे 2 चित्र):

Linux पर पतली क्लाइंट विंडो:

वेब क्लाइंट में वही विंडो (क्रोम ब्राउज़र में):

हमने वेब क्लाइंट क्यों बनाया? कुछ हद तक दयनीय रूप से कहें तो, समय ने हमारे लिए ऐसा कार्य निर्धारित किया है। व्यावसायिक अनुप्रयोगों के लिए इंटरनेट पर काम करना लंबे समय से एक पूर्व शर्त रही है। सबसे पहले, हमने अपने पतले क्लाइंट के लिए इंटरनेट के माध्यम से काम करने की क्षमता जोड़ी (वैसे, हमारे कुछ प्रतिस्पर्धी वहीं रुक गए; इसके विपरीत, अन्य ने पतले क्लाइंट को छोड़ दिया और खुद को वेब क्लाइंट लागू करने तक सीमित कर लिया)। हमने अपने उपयोगकर्ताओं को उनके लिए सबसे उपयुक्त ग्राहक विकल्प चुनने का अवसर देने का निर्णय लिया।

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

समस्या का निरूपण

तो, परियोजना की आवश्यकताएँ: वेब क्लाइंट को पतले क्लाइंट के समान ही करना होगा, अर्थात्:

1. उपयोगकर्ता इंटरफ़ेस प्रदर्शित करें
2. 1सी भाषा में लिखे गए क्लाइंट कोड को निष्पादित करें

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

1C भाषा में क्लाइंट कोड में सर्वर कॉल, स्थानीय संसाधनों (फ़ाइलें, आदि) के साथ काम करना, प्रिंटिंग और बहुत कुछ शामिल हो सकता है।

थिन क्लाइंट (वेब ​​के माध्यम से काम करते समय) और वेब क्लाइंट दोनों 1C एप्लिकेशन सर्वर के साथ संचार करने के लिए वेब सेवाओं के समान सेट का उपयोग करते हैं। बेशक, क्लाइंट कार्यान्वयन अलग-अलग हैं - पतला क्लाइंट C++ में लिखा जाता है, वेब क्लाइंट जावास्क्रिप्ट में लिखा जाता है।

एक छोटा सा इतिहास

वेब क्लाइंट प्रोजेक्ट 2006 में शुरू हुआ, जिसमें (औसतन) 5 लोगों की टीम थी। परियोजना के कुछ चरणों में, डेवलपर्स विशिष्ट कार्यक्षमता (स्प्रेडशीट दस्तावेज़, आरेख, आदि) को लागू करने में शामिल थे; एक नियम के रूप में, ये वही डेवलपर्स थे जिन्होंने थिन क्लाइंट में यह कार्यक्षमता की थी। वे। डेवलपर्स ने जावास्क्रिप्ट में उन घटकों को फिर से लिखा जो उन्होंने पहले C++ में बनाए थे।

शुरुआत से ही, हमने दोनों भाषाओं के बीच मजबूत वैचारिक मतभेदों के कारण C++ थिन क्लाइंट कोड के जावास्क्रिप्ट वेब क्लाइंट में किसी भी स्वचालित (यहां तक ​​कि आंशिक) रूपांतरण के विचार को खारिज कर दिया; वेब क्लाइंट शुरुआत से जावास्क्रिप्ट में लिखा गया था।

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

वेब क्लाइंट समर्थन के साथ 1C:एंटरप्राइज़ प्लेटफ़ॉर्म का पहला संस्करण 2009 में जारी किया गया था। उस समय वेब क्लाइंट 2 ब्राउज़रों - इंटरनेट एक्सप्लोरर और फ़ायरफ़ॉक्स का समर्थन करता था। मूल योजनाओं में ओपेरा के लिए समर्थन शामिल था, लेकिन उस समय ओपेरा में एप्लिकेशन बंद करने वाले हैंडलर के साथ दुर्गम समस्याओं के कारण (100% निश्चितता के साथ ट्रैक करना संभव नहीं था कि एप्लिकेशन बंद हो रहा था, और उस समय वियोग प्रक्रिया को पूरा करना संभव नहीं था) इन योजनाओं में से 1C एप्लिकेशन सर्वर) को छोड़ना पड़ा।

परियोजना संरचना

कुल मिलाकर, 1C:एंटरप्राइज़ प्लेटफ़ॉर्म पर जावास्क्रिप्ट में लिखी गई 4 परियोजनाएँ हैं:

1. वेबटूल्स - अन्य परियोजनाओं द्वारा उपयोग की जाने वाली साझा लाइब्रेरी (हम इसमें शामिल हैं गूगल क्लोजर लाइब्रेरी).
2. नियंत्रण तत्व स्वरूपित दस्तावेज़ (जावास्क्रिप्ट में पतले क्लाइंट और वेब क्लाइंट दोनों में लागू किया गया)
3. नियंत्रण तत्व समयबद्धक (जावास्क्रिप्ट में पतले क्लाइंट और वेब क्लाइंट दोनों में लागू किया गया)
4. वेब क्लाइंट

प्रत्येक प्रोजेक्ट की संरचना जावा प्रोजेक्ट्स (या .NET प्रोजेक्ट्स - जो भी करीब हो) की संरचना से मिलती जुलती है; हमारे पास नामस्थान हैं, और प्रत्येक नामस्थान एक अलग फ़ोल्डर में है। फ़ोल्डर के अंदर फ़ाइलें और नेमस्पेस कक्षाएं हैं। वेब क्लाइंट प्रोजेक्ट में लगभग 1000 फ़ाइलें हैं।

संरचनात्मक रूप से, वेब क्लाइंट को बड़े पैमाने पर निम्नलिखित उपप्रणालियों में विभाजित किया गया है:

• प्रबंधित क्लाइंट एप्लिकेशन इंटरफ़ेस
  • सामान्य एप्लिकेशन इंटरफ़ेस (सिस्टम मेनू, पैनल)
  • प्रबंधित प्रपत्रों का इंटरफ़ेस, जिसमें अन्य चीज़ों के अलावा, लगभग 30 नियंत्रण (बटन, विभिन्न प्रकार के इनपुट फ़ील्ड - पाठ, संख्यात्मक, दिनांक/समय, आदि, तालिकाएँ, सूचियाँ, ग्राफ़, आदि) शामिल हैं।

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

विकास सुविधाएँ

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

क्लाइंट कोड के आकार को कम करने के लिए, हमने सबसे पहले अपने स्वयं के ऑबफस्केटर का उपयोग किया, और प्लेटफ़ॉर्म संस्करण 8.3.6 (अक्टूबर 2014) से शुरू करके हमने इसका उपयोग करना शुरू किया गूगल क्लोजर कंपाइलर. संख्याओं में उपयोग का प्रभाव - अस्पष्टता के बाद वेब क्लाइंट फ्रेमवर्क का आकार:

• स्वयं का ऑबफस्केटर - 1556 केबी
• गूगल क्लोजर कंपाइलर - 1073 केबी

Google क्लोजर कंपाइलर का उपयोग करने से हमें अपने स्वयं के ऑबफस्केटर की तुलना में वेब क्लाइंट के प्रदर्शन को 30% बेहतर बनाने में मदद मिली। इसके अलावा, एप्लिकेशन द्वारा खपत की गई मेमोरी की मात्रा में 15-25% की कमी आई है (ब्राउज़र पर निर्भर करता है)।

Google क्लोजर कंपाइलर ऑब्जेक्ट-ओरिएंटेड कोड के साथ बहुत अच्छी तरह से काम करता है, इसलिए वेब क्लाइंट के लिए इसकी दक्षता यथासंभव अधिक है। क्लोजर कंपाइलर हमारे लिए कुछ अच्छे काम करता है:

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

हम वेबस्टॉर्म का उपयोग अपने वेब क्लाइंट विकास परिवेश के रूप में करते हैं।

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

हमने किन समस्याओं का समाधान किया/कर रहे हैं?

परियोजना के कार्यान्वयन के दौरान, हमें कई दिलचस्प समस्याओं का सामना करना पड़ा जिन्हें हमें हल करना था।

सर्वर के साथ और विंडोज़ के बीच डेटा का आदान-प्रदान करें

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

• डेटा संरचनाओं के रूप में सर्वर से आने वाला कोड
• किसी अन्य एप्लिकेशन विंडो के लिए कोड

सर्वर के साथ इंटरैक्ट करते समय अस्पष्टता से बचने के लिए, हम @expose टैग का उपयोग करते हैं:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

और अन्य विंडो के साथ इंटरैक्ट करते समय अस्पष्टता से बचने के लिए, हम तथाकथित निर्यातित इंटरफेस (इंटरफेस जिसमें सभी विधियां निर्यात की जाती हैं) का उपयोग करते हैं।

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

मुख्यधारा बनने से पहले हमने वर्चुअल DOM का उपयोग किया था)

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

वेब क्लाइंट का अनुकूलन

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

परीक्षण

कार्यात्मक और प्रदर्शन परीक्षण के लिए, हम एक मालिकाना उपकरण (जावा और सी++ में लिखा हुआ) का उपयोग करते हैं, साथ ही इसके शीर्ष पर निर्मित परीक्षणों का एक सूट भी उपयोग करते हैं। सेलेनियम.

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

यह टूल 25 मिलीसेकंड तक की सटीकता के साथ एप्लिकेशन प्रदर्शन को भी मापता है। कुछ मामलों में, हम समय के साथ निष्पादन समय में गिरावट का विश्लेषण करने के लिए स्क्रिप्ट के कुछ हिस्सों को लूप करते हैं (उदाहरण के लिए, ऑर्डर प्रविष्टि को कई बार दोहराते हुए)। सभी मापों के परिणाम विश्लेषण के लिए एक लॉग में दर्ज किए जाते हैं।

हमारा परीक्षण उपकरण और अनुप्रयोग परीक्षणाधीन है

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

दोनों टूल (हमारे और सेलेनियम) पर परीक्षण हमारे एप्लिकेशन समाधानों से विशिष्ट कार्य परिदृश्य चलाते हैं। 1सी:एंटरप्राइज़ प्लेटफ़ॉर्म के दैनिक निर्माण के बाद परीक्षण स्वचालित रूप से लॉन्च किए जाते हैं। यदि स्क्रिप्ट धीमी हैं (पिछले निर्माण की तुलना में), तो हम मंदी के कारण की जांच करते हैं और उसका समाधान करते हैं। हमारा मानदंड सरल है - नया निर्माण पिछले वाले की तुलना में धीमा नहीं होना चाहिए।

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

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

ब्राउज़र एक्सटेंशन

जब किसी एप्लिकेशन समाधान को ऐसी कार्यक्षमता की आवश्यकता होती है जो जावास्क्रिप्ट में उपलब्ध नहीं है, तो हम ब्राउज़र एक्सटेंशन का उपयोग करते हैं:

• फाइलों के साथ काम करने के लिए
• क्रिप्टोग्राफी के साथ काम करने के लिए
• के साथ काम बाहरी घटक

हमारे एक्सटेंशन में दो भाग होते हैं। पहले भाग को ब्राउज़र एक्सटेंशन कहा जाता है (आमतौर पर क्रोम और फ़ायरफ़ॉक्स के लिए जावास्क्रिप्ट में लिखे गए एक्सटेंशन), ​​जो दूसरे भाग के साथ इंटरैक्ट करता है - एक बाइनरी एक्सटेंशन जो हमारे लिए आवश्यक कार्यक्षमता को लागू करता है। यह उल्लेख किया जाना चाहिए कि हम बाइनरी एक्सटेंशन के 3 संस्करण लिखते हैं - विंडोज, लिनक्स और मैकओएस के लिए। बाइनरी एक्सटेंशन 1C:एंटरप्राइज़ प्लेटफ़ॉर्म के हिस्से के रूप में आपूर्ति की जाती है और 1C एप्लिकेशन सर्वर पर स्थित है। जब किसी वेब क्लाइंट से पहली बार कॉल किया जाता है, तो इसे क्लाइंट कंप्यूटर पर डाउनलोड किया जाता है और ब्राउज़र में इंस्टॉल किया जाता है।

सफ़ारी में चलते समय, हमारे एक्सटेंशन एनपीएपीआई का उपयोग करते हैं; इंटरनेट एक्सप्लोरर में चलते समय, वे ActiveX तकनीक का उपयोग करते हैं। Microsoft Edge अभी तक एक्सटेंशन का समर्थन नहीं करता है, इसलिए इसमें वेब क्लाइंट प्रतिबंधों के साथ काम करता है।

आगे विकास

वेब क्लाइंट डेवलपमेंट टीम के कार्यों में से एक कार्यक्षमता का और विकास करना है। वेब क्लाइंट की कार्यक्षमता थिन क्लाइंट की कार्यक्षमता के समान होनी चाहिए; सभी नई कार्यक्षमता थिन और वेब क्लाइंट दोनों में एक साथ लागू की जाती है।

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

स्रोत: www.habr.com