1C ვებ კლიენტის შესახებ

1C: Enterprise ტექნოლოგიის ერთ-ერთი კარგი თვისებაა ის, რომ აპლიკაციის გადაწყვეტა, რომელიც შემუშავებულია მართული ფორმების ტექნოლოგიის გამოყენებით, შეიძლება გაშვებული იყოს როგორც თხელ (შესრულებად) კლიენტში Windows, Linux, MacOS X-ისთვის და როგორც ვებ კლიენტი 5 ბრაუზერისთვის - Chrome, Internet Explorer, Firefox, Safari, Edge და ეს ყველაფერი აპლიკაციის საწყისი კოდის შეცვლის გარეშე. უფრო მეტიც, გარედან აპლიკაცია თინ კლიენტში და ბრაუზერში ფუნქციონირებს და თითქმის იდენტურად გამოიყურება.
იპოვეთ 10 განსხვავება (2 სურათი ჭრილის ქვეშ):

თხელი კლიენტის ფანჯარა Linux-ზე:

იგივე ფანჯარა ვებ კლიენტში (Chrome ბრაუზერში):

რატომ შევქმენით ვებ კლიენტი? ცოტა პათეტიკურად რომ ვთქვათ, დრომ ასეთი ამოცანა დაგვისახა. ინტერნეტში მუშაობა დიდი ხანია არის ბიზნეს აპლიკაციების წინაპირობა. პირველ რიგში, ჩვენს თხელი კლიენტს დავამატეთ ინტერნეტით მუშაობის შესაძლებლობა (სხვათა შორის, ზოგიერთი ჩვენი კონკურენტი იქ გაჩერდა; სხვებმა, პირიქით, მიატოვეს თხელი კლიენტი და შემოიფარგლნენ ვებ კლიენტის განხორციელებით). ჩვენ გადავწყვიტეთ, რომ ჩვენს მომხმარებლებს მივცეთ საშუალება აირჩიონ კლიენტის ვარიანტი, რომელიც მათ საუკეთესოდ შეეფერება.

თხელი კლიენტისთვის ვებ-ზე დაფუძნებული შესაძლებლობების დამატება იყო დიდი პროექტი კლიენტ-სერვერის არქიტექტურის სრული ცვლილებით. ვებ კლიენტის შექმნა სრულიად ახალი პროექტია, დაწყებული ნულიდან.

პრობლემის შესახებ განცხადება

ასე რომ, პროექტის მოთხოვნები: ვებ კლიენტმა უნდა გააკეთოს იგივე, რაც თხელი კლიენტმა, კერძოდ:

1. მომხმარებლის ინტერფეისის ჩვენება
2. შეასრულეთ კლიენტის კოდი დაწერილი 1C ენაზე

მომხმარებლის ინტერფეისი 1C-ში აღწერილია ვიზუალურ რედაქტორში, მაგრამ დეკლარაციულად, ელემენტების პიქსელ-პიქსელ მოწყობის გარეშე; გამოყენებულია ინტერფეისის ელემენტების სამი ათეული ტიპი - ღილაკები, შეყვანის ველები (ტექსტი, რიცხვითი, თარიღი/დრო), სიები, ცხრილები, გრაფიკები და ა.შ.

კლიენტის კოდი 1C ენაზე შეიძლება შეიცავდეს სერვერის ზარებს, ადგილობრივ რესურსებთან მუშაობას (ფაილები და ა.შ.), ბეჭდვას და ბევრ სხვას.

როგორც თხელი კლიენტი (ვებზე მუშაობისას) ასევე ვებ კლიენტი იყენებს ვებ სერვისების ერთსა და იმავე კომპლექტს 1C აპლიკაციის სერვერთან კომუნიკაციისთვის. კლიენტის იმპლემენტაციები, რა თქმა უნდა, განსხვავებულია - თინ კლიენტი იწერება C++-ში, ვებ კლიენტი იწერება JavaScript-ში.

პატარა ისტორიის

ვებ კლიენტის პროექტი დაიწყო 2006 წელს, გუნდში (საშუალოდ) 5 კაციანი. პროექტის გარკვეულ ეტაპებზე დეველოპერები ჩართულნი იყვნენ კონკრეტული ფუნქციების განსახორციელებლად (ელცხრილის დოკუმენტი, დიაგრამები და ა.შ.); როგორც წესი, ესენი იყვნენ იგივე დეველოპერები, რომლებმაც შეასრულეს ეს ფუნქცია თხელი კლიენტში. იმათ. დეველოპერებმა ხელახლა დაწერეს კომპონენტები JavaScript-ში, რომლებიც ადრე შექმნეს C++-ში.

თავიდანვე უარვყავით C++ თხელი კლიენტის კოდის JavaScript ვებ კლიენტად ავტომატური (თუნდაც ნაწილობრივი) გადაქცევის იდეა ორ ენას შორის ძლიერი კონცეპტუალური განსხვავებების გამო; ვებ კლიენტი დაიწერა JavaScript-ში ნულიდან.

პროექტის პირველ გამეორებებში, ვებ კლიენტმა გადააქცია კლიენტის კოდი ჩაშენებულ 1C ენაზე პირდაპირ JavaScript-ში. თხელი კლიენტი განსხვავებულად მოქმედებს - ჩაშენებულ 1C ენაში კოდი შედგენილია ბაიტეკოდში, შემდეგ კი ეს ბაიტიკოდი ინტერპრეტირებულია კლიენტზე. შემდგომში, ვებ-კლიენტმაც იგივე დაიწყო - ჯერ ერთი, მან გაზარდა შესრულების მომატება და მეორეც, შესაძლებელი გახადა თხელი და ვებ კლიენტების არქიტექტურის გაერთიანება.

1C: Enterprise პლატფორმის პირველი ვერსია ვებ კლიენტის მხარდაჭერით გამოვიდა 2009 წელს. იმ დროს ვებ კლიენტი მხარს უჭერდა 2 ბრაუზერს - Internet Explorer და Firefox. თავდაპირველი გეგმები მოიცავდა ოპერის მხარდაჭერას, მაგრამ იმ დროისთვის გადაულახავი პრობლემების გამო ოპერაში აპლიკაციის დახურვის დამმუშავებლებთან (შეუძლებელი იყო 100% დარწმუნებით თვალყური ადევნოთ, რომ აპლიკაცია იხურებოდა და იმ მომენტში ჩაატარეთ გათიშვის პროცედურა 1C აპლიკაციის სერვერი) ამ გეგმებიდან უნდა მიტოვებულიყო.

პროექტის სტრუქტურა

საერთო ჯამში, 1C:Enterprise პლატფორმას აქვს 4 პროექტი დაწერილი JavaScript-ში:

1. WebTools – გაზიარებული ბიბლიოთეკები, რომლებიც გამოიყენება სხვა პროექტების მიერ (ჩვენ ასევე მოიცავს Google-ის დახურვის ბიბლიოთეკა).
2. საკონტროლო ელემენტი ფორმატირებული დოკუმენტი (დანერგილი JavaScript-ში როგორც თინ კლიენტში, ასევე ვებ კლიენტში)
3. საკონტროლო ელემენტი განრიგი (დანერგილი JavaScript-ში როგორც თინ კლიენტში, ასევე ვებ კლიენტში)
4. ვებ კლიენტი

თითოეული პროექტის სტრუქტურა წააგავს Java პროექტების სტრუქტურას (ან .NET პროექტები - რომელი უფრო ახლოს არის); ჩვენ გვაქვს სახელთა სივრცეები და თითოეული სახელთა სივრცე ცალკე საქაღალდეშია. საქაღალდის შიგნით არის ფაილები და სახელთა სივრცის კლასები. ვებ კლიენტის პროექტში დაახლოებით 1000 ფაილია.

სტრუქტურულად, ვებ კლიენტი დიდწილად იყოფა შემდეგ ქვესისტემებად:

• მართული კლიენტის აპლიკაციის ინტერფეისი
  • ზოგადი აპლიკაციის ინტერფეისი (სისტემის მენიუები, პანელები)
  • მართული ფორმების ინტერფეისი, მათ შორის, 30-მდე კონტროლის ჩათვლით (ღილაკები, სხვადასხვა ტიპის შეყვანის ველები - ტექსტი, რიცხვითი, თარიღი/დრო და ა.შ., ცხრილები, სიები, გრაფიკები და ა.შ.)

• ობიექტის მოდელი ხელმისაწვდომია დეველოპერებისთვის კლიენტზე (სულ 400-ზე მეტი ტიპი: მართული ინტერფეისის ობიექტის მოდელი, მონაცემთა განლაგების პარამეტრები, პირობითი სტილი და ა.შ.)
• ჩაშენებული 1C ენის თარჯიმანი
• ბრაუზერის გაფართოებები (გამოიყენება JavaScript-ში მხარდაჭერილი ფუნქციებისთვის)
  • კრიპტოგრაფიასთან მუშაობა
  • ფაილებთან მუშაობა
  • გარე კომპონენტების ტექნოლოგია, რაც მათ საშუალებას აძლევს გამოიყენონ როგორც თხელი, ასევე ვებ კლიენტებისთვის

განვითარების მახასიათებლები

ყოველივე ზემოთქმულის JavaScript-ში დანერგვა ადვილი არ არის. შესაძლოა, 1C ვებ კლიენტი არის ერთ-ერთი ყველაზე მსხვილი აპლიკაცია კლიენტის მხარეს, რომელიც დაწერილია JavaScript-ში - დაახლოებით 450.000 ხაზი. ვებ კლიენტის კოდში აქტიურად ვიყენებთ ობიექტზე ორიენტირებულ მიდგომას, რაც ამარტივებს ასეთ დიდ პროექტთან მუშაობას.

კლიენტის კოდის ზომის შესამცირებლად, ჩვენ პირველად გამოვიყენეთ ჩვენი საკუთარი დამაბნეველი და დაწყებული პლატფორმის ვერსიით 8.3.6 (2014 წლის ოქტომბერი) დავიწყეთ გამოყენება. Google Closure Compiler. რიცხვებში გამოყენების ეფექტი – ვებ კლიენტის ჩარჩოს ზომა დაბინდვის შემდეგ:

• საკუთარი ობფუსკატორი – 1556 კბ
• Google Closure Compiler – 1073 kb

Google Closure Compiler-ის გამოყენება დაგვეხმარა ვებ-კლიენტის მუშაობის გაუმჯობესებაში 30%-ით ჩვენს ობფუსკატორთან შედარებით. გარდა ამისა, აპლიკაციის მიერ მოხმარებული მეხსიერების რაოდენობა შემცირდა 15-25%-ით (ბრაუზერის მიხედვით).

Google Closure Compiler ძალიან კარგად მუშაობს ობიექტზე ორიენტირებულ კოდთან, ამიტომ მისი ეფექტურობა ვებ კლიენტისთვის მაქსიმალურად მაღალია. დახურვის შემდგენელი აკეთებს რამდენიმე სიკეთეს ჩვენთვის:

• სტატიკური ტიპის შემოწმება პროექტის აშენების ეტაპზე (უზრუნველყოფს, რომ ჩვენ ვფარავთ კოდს JSDoc ანოტაციებით). შედეგი არის სტატიკური აკრეფა, დონესთან ძალიან ახლოს C++-ში აკრეფასთან. ეს ხელს უწყობს შეცდომების საკმაოდ დიდი პროცენტის დაჭერას პროექტის შედგენის ეტაპზე.
• კოდის ზომის შემცირება დაბინდვის გზით
• შესრულებული კოდის მთელი რიგი ოპტიმიზაცია, მაგალითად, როგორიცაა:
  • inline ფუნქციის ჩანაცვლება. JavaScript-ში ფუნქციის გამოძახება საკმაოდ ძვირი ოპერაციაა და ხშირად გამოყენებული მცირე მეთოდების შიდა ჩანაცვლება მნიშვნელოვნად აჩქარებს კოდს.
  • მუდმივების დათვლა კომპილაციის დროს. თუ გამოხატულება დამოკიდებულია მუდმივზე, მუდმივის რეალური მნიშვნელობა ჩანაცვლდება მასში

ჩვენ ვიყენებთ WebStorm-ს, როგორც ჩვენი ვებ კლიენტის განვითარების გარემოს.

კოდის ანალიზისთვის ვიყენებთ soundQube, სადაც ჩვენ ვაერთიანებთ სტატიკური კოდის ანალიზატორებს. ანალიზატორების გამოყენებით ვაკვირდებით JavaScript-ის წყაროს კოდის ხარისხის დეგრადაციას და ვცდილობთ თავიდან ავიცილოთ იგი.

რა პრობლემებს ვაგვარებთ/ვაგვარებთ?

პროექტის განხორციელებისას არაერთი საინტერესო პრობლემა შეგვხვდა, რომელთა გადაჭრაც მოგვიწია.

გაცვალეთ მონაცემები სერვერთან და ფანჯრებს შორის

არის სიტუაციები, როდესაც წყაროს კოდის დაბნელებამ შეიძლება ხელი შეუშალოს სისტემის მუშაობას. ვებ-კლიენტის შესრულებადი კოდის გარე კოდს, ბუნდოვანის გამო, შეიძლება ჰქონდეს ფუნქციების და პარამეტრების სახელები, რომლებიც განსხვავდებიან იმისგან, რასაც ჩვენი შესრულებადი კოდი მოელის. ჩვენთვის გარე კოდია:

• კოდი, რომელიც მოდის სერვერიდან მონაცემთა სტრუქტურების სახით
• კოდი სხვა აპლიკაციის ფანჯრისთვის

სერვერთან ურთიერთობისას დაბინდვის თავიდან ასაცილებლად, ჩვენ ვიყენებთ @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-ს, სანამ ის მეინსტრიმში გახდებოდა)

ყველა დეველოპერების მსგავსად, რომლებიც რთულ ვებ UI-ებთან მუშაობენ, ჩვენ სწრაფად მივხვდით, რომ DOM ცუდად არის შესაფერისი მომხმარებლის დინამიურ ინტერფეისებთან მუშაობისთვის. თითქმის მაშინვე განხორციელდა ვირტუალური DOM-ის ანალოგი ინტერფეისთან მუშაობის ოპტიმიზაციისთვის. მოვლენის დამუშავების დროს, DOM-ის ყველა ცვლილება ინახება მეხსიერებაში და მხოლოდ მაშინ, როცა ყველა ოპერაცია დასრულდება, დაგროვილი ცვლილებები გამოიყენება DOM ხეზე.

ვებ კლიენტის ოპტიმიზაცია

იმისათვის, რომ ჩვენი ვებ კლიენტი უფრო სწრაფად იმუშაოს, ჩვენ ვცდილობთ მაქსიმალურად გამოვიყენოთ ბრაუზერის სტანდარტული შესაძლებლობები (CSS და ა.შ.). ამრიგად, ფორმის ბრძანების პანელი (მდებარეობს აპლიკაციის თითქმის ყველა ფორმაზე) გამოსახულია ექსკლუზიურად ბრაუზერის ხელსაწყოების გამოყენებით, CSS-ზე დაფუძნებული დინამიური განლაგების გამოყენებით.

ტესტირება

ფუნქციონალური და შესრულების ტესტირებისთვის, ჩვენ ვიყენებთ საკუთრების ინსტრუმენტს (დაწერილი Java და C++), ისევე როგორც ტესტების კომპლექტს, რომელიც აგებულია თავზე. სელენი.

ჩვენი ინსტრუმენტი უნივერსალურია - ის საშუალებას გაძლევთ შეამოწმოთ თითქმის ნებისმიერი ფანჯარა და, შესაბამისად, შესაფერისია როგორც თხელი კლიენტის, ასევე ვებ კლიენტის შესამოწმებლად. ინსტრუმენტი იწერს მომხმარებლის მოქმედებებს, რომელმაც 1C აპლიკაციის გადაწყვეტა სკრიპტის ფაილში გაუშვა. ამავდროულად, იწერება ეკრანის სამუშაო ადგილის სურათები - სტანდარტები. ვებ კლიენტის ახალი ვერსიების მონიტორინგისას, სკრიპტები ითამაშება მომხმარებლის მონაწილეობის გარეშე. იმ შემთხვევებში, როდესაც სკრინშოტი არც ერთ ეტაპზე არ ემთხვევა მითითებას, ტესტი ჩაითვლება წარუმატებლად, რის შემდეგაც ხარისხის სპეციალისტი ატარებს გამოძიებას, რათა დადგინდეს, არის თუ არა ეს შეცდომა ან დაგეგმილი ცვლილება სისტემის ქცევაში. დაგეგმილი ქცევის შემთხვევაში სტანდარტები ავტომატურად იცვლება ახლით.

ინსტრუმენტი ასევე ზომავს აპლიკაციის შესრულებას 25 მილიწამამდე სიზუსტით. ზოგიერთ შემთხვევაში, ჩვენ ვახდენთ სკრიპტის ნაწილებს (მაგალითად, შეკვეთის ჩანაწერის რამდენჯერმე გამეორება), რათა გავაანალიზოთ შესრულების დროის დეგრადაცია დროთა განმავლობაში. ყველა გაზომვის შედეგები ჩაიწერება ჟურნალში ანალიზისთვის.

ჩვენი ტესტირების ინსტრუმენტი და აპლიკაცია ტესტირებაშია

ჩვენი ხელსაწყო და სელენი ავსებენ ერთმანეთს; მაგალითად, თუ რომელიმე ეკრანზე რომელიმე ღილაკმა შეცვალა მისი მდებარეობა, სელენი შეიძლება ამას ვერ აკონტროლებდეს, მაგრამ ჩვენი ინსტრუმენტი შეამჩნევს, რადგან აკეთებს პიქსელ-პიქსელ ადარებს ეკრანის სურათს სტანდარტთან. ხელსაწყოს ასევე შეუძლია თვალყური ადევნოს პრობლემებს კლავიატურიდან ან მაუსიდან შეყვანის დამუშავებასთან დაკავშირებით, რადგან ეს არის ზუსტად ის, რასაც ის ამრავლებს.

ტესტები ორივე ხელსაწყოზე (ჩვენი და სელენი) აწარმოებს ტიპურ სამუშაო სცენარებს ჩვენი აპლიკაციის გადაწყვეტილებებიდან. ტესტები ავტომატურად იწყება 1C:Enterprise პლატფორმის ყოველდღიური შექმნის შემდეგ. თუ სკრიპტები უფრო ნელია (წინა ვერსიასთან შედარებით), ჩვენ ვიკვლევთ და ვხსნით შენელების მიზეზს. ჩვენი კრიტერიუმი მარტივია - ახალი კონსტრუქცია არ უნდა მუშაობდეს წინაზე ნელა.

დეველოპერები იყენებენ სხვადასხვა ინსტრუმენტებს შენელების ინციდენტების გამოსაძიებლად; ძირითადად გამოიყენება Dynatrace AJAX გამოცემა მწარმოებელი კომპანია DynaTrace. იწერება წინა და ახალ ნაგებობებზე პრობლემური ოპერაციის შესრულების ჟურნალები, შემდეგ ხდება ჟურნალების ანალიზი. ამავდროულად, ერთჯერადი ოპერაციების შესრულების დრო (მილიწამებში) შეიძლება არ იყოს გადამწყვეტი ფაქტორი - სერვისის პროცესები, როგორიცაა ნაგვის შეგროვება, პერიოდულად იწყება ბრაუზერში, მათ შეუძლიათ გადაფარონ ფუნქციების შესრულების დრო და დაამახინჯონ სურათი. ამ შემთხვევაში უფრო შესაბამისი პარამეტრები იქნება JavaScript-ის შესრულებული ინსტრუქციების რაოდენობა, DOM-ზე ატომური ოპერაციების რაოდენობა და ა.შ. თუ ინსტრუქციების/ოპერაციების რაოდენობა იმავე სკრიპტში გაიზარდა ახალ ვერსიაში, ეს თითქმის ყოველთვის ნიშნავს შესრულების ვარდნას, რომელიც საჭიროებს გამოსწორებას.

ასევე, შესრულების შემცირების ერთ-ერთი მიზეზი შეიძლება იყოს ის, რომ Google Closure Compiler-მა რაიმე მიზეზით ვერ შეძლო ფუნქციის შიდა ჩანაცვლება (მაგალითად, რადგან ფუნქცია რეკურსიული ან ვირტუალურია). ამ შემთხვევაში, ჩვენ ვცდილობთ გამოვასწოროთ სიტუაცია წყაროს კოდის გადაწერით.

ბრაუზერის გაფართოებები

როდესაც აპლიკაციის გადაწყვეტას სჭირდება ფუნქციონირება, რომელიც მიუწვდომელია JavaScript-ში, ჩვენ ვიყენებთ ბრაუზერის გაფართოებებს:

• ფაილებთან მუშაობისთვის
• კრიპტოგრაფიასთან მუშაობისთვის
• მუშაობა გარე კომპონენტები

ჩვენი გაფართოებები შედგება ორი ნაწილისგან. პირველი ნაწილი არის ის, რასაც ბრაუზერის გაფართოება ჰქვია (ჩვეულებრივ გაფართოებები Chrome-ისთვის და Firefox-ისთვის დაწერილია JavaScript-ში), რომელიც ურთიერთქმედებს მეორე ნაწილთან - ბინარული გაფართოება, რომელიც ახორციელებს ჩვენთვის საჭირო ფუნქციონირებას. აღსანიშნავია, რომ ჩვენ ვწერთ ბინარული გაფართოების 3 ვერსიას - Windows-ისთვის, Linux-ისთვის და MacOS-ისთვის. ბინარული გაფართოება მოწოდებულია როგორც 1C:Enterprise პლატფორმის ნაწილი და მდებარეობს 1C აპლიკაციის სერვერზე. ვებ-კლიენტიდან პირველად გამოძახებისას, ის ჩამოიტვირთება კლიენტის კომპიუტერში და დაინსტალირდება ბრაუზერში.

Safari-ში გაშვებისას, ჩვენი გაფართოებები იყენებენ NPAPI-ს; Internet Explorer-ში გაშვებისას ისინი იყენებენ ActiveX ტექნოლოგიას. Microsoft Edge ჯერ არ უჭერს მხარს გაფართოებებს, ამიტომ მასში არსებული ვებ კლიენტი მუშაობს შეზღუდვებით.

Შემდგომი განვითარება

ვებ კლიენტების განვითარების გუნდის ერთ-ერთი ამოცანაა ფუნქციონირების შემდგომი განვითარება. ვებ კლიენტის ფუნქციონირება უნდა იყოს იდენტური თინ კლიენტის ფუნქციონალურობისა; ყველა ახალი ფუნქციონალობა ერთდროულად განხორციელდება როგორც თინ, ასევე ვებ კლიენტებში.

სხვა ამოცანები მოიცავს არქიტექტურის განვითარებას, რეფაქტორირებას, შესრულებისა და საიმედოობის გაუმჯობესებას. მაგალითად, ერთ-ერთი მიმართულება არის შემდგომი მოძრაობა ასინქრონული სამუშაო მოდელისკენ. ვებ კლიენტის ზოგიერთი ფუნქცია ამჟამად აგებულია სერვერთან ურთიერთქმედების სინქრონულ მოდელზე. ასინქრონული მოდელი ახლა უფრო აქტუალური ხდება ბრაუზერებში (და არა მხოლოდ ბრაუზერებში) და ეს გვაიძულებს შევცვალოთ ვებ კლიენტი სინქრონული ზარების ასინქრონულით ჩანაცვლებით (და შესაბამისად კოდის რეფაქტორირება). ასინქრონულ მოდელზე თანდათანობითი გადასვლა აიხსნება გამოშვებული გადაწყვეტილებების მხარდაჭერისა და მათი თანდათანობითი ადაპტაციის საჭიროებით.

წყარო: www.habr.com