Habr front-end დეველოპერების ჟურნალები: refactoring და ასახვა

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

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

ბევრი სხვა IT კომპანიის მსგავსად, Habr ასწავლის Agile იდეებს, CI პრაქტიკას და ეს ყველაფერია. მაგრამ ჩემი გრძნობების მიხედვით, ჰაბრი, როგორც პროდუქტი, უფრო ტალღებით ვითარდება, ვიდრე განუწყვეტლივ. ასე რომ, ზედიზედ რამდენიმე სპრინტი გულმოდგინედ ვაკოდირებთ რაღაცას, ვქმნით და ხელახლა ვქმნით, ვამტვრევთ და ვასწორებთ, ვხსნით ბილეთებს და ვქმნით ახლებს, ვაბიჯებთ და ფეხებში ვესროლით, რათა საბოლოოდ გავათავისუფლოთ ფუნქცია წარმოება. და შემდეგ მოდის გარკვეული სიმშვიდე, ხელახალი განვითარების პერიოდი, დრო, რომ გავაკეთოთ ის, რაც არის "მნიშვნელოვანი და არა გადაუდებელი" კვადრატში.

სწორედ ეს "სეზონის გარეთ" სპრინტი იქნება განხილული ქვემოთ. ამჯერად ის მოიცავდა Habr-ის მობილური ვერსიის რეფაქტორირებას. ზოგადად, კომპანია მასზე დიდ იმედებს ამყარებს და მომავალში მან უნდა შეცვალოს ჰაბრის ინკარნაციების მთელი ზოოპარკი და გახდეს უნივერსალური კროს-პლატფორმული გადაწყვეტა. ოდესმე იქნება ადაპტური განლაგება, PWA, ოფლაინ რეჟიმი, მომხმარებლის მორგება და ბევრი სხვა საინტერესო რამ.

დავსვათ დავალება

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

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

მობილური Habr ინტერფეისი რეფაქტორირებამდე

Რა ხდება აქ? მოკლედ, სერვერი ყველას ერთნაირად ემსახურებოდა HTML გვერდს, მიუხედავად იმისა, იყო თუ არა მომხმარებელი შესული. შემდეგ კლიენტი JS იტვირთება და კვლავ ითხოვს საჭირო მონაცემებს, მაგრამ მორგებულია ავტორიზაციისთვის. ანუ რეალურად ერთი და იგივე სამუშაო ორჯერ გავაკეთეთ. ინტერფეისი ციმციმდა და მომხმარებელმა ჩამოტვირთა ასი დამატებითი კილობაიტი. დეტალურად ყველაფერი კიდევ უფრო საშინელი ჩანდა.

ძველი SSR-CSR სქემა. ავტორიზაცია შესაძლებელია მხოლოდ C3 და C4 ეტაპებზე, როდესაც Node JS არ არის დაკავებული HTML-ის გენერირებით და შეუძლია API-ზე პროქსის მოთხოვნა.

ჩვენი იმდროინდელი არქიტექტურა ძალიან ზუსტად იყო აღწერილი Habr-ის ერთ-ერთმა მომხმარებელმა:

მობილური ვერსია სისულელეა. მე ვამბობ ისე როგორც არის. SSR-ისა და CSR-ის საშინელი კომბინაცია.

უნდა გვეღიარებინა, რაც არ უნდა სამწუხარო ყოფილიყო.

მე შევაფასე ვარიანტები, შევქმენი ბილეთი ჯირაში აღწერით "ახლა ცუდია, გააკეთე სწორად" და დავაშალე ფართო შტრიხებით:

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

მოდით ხელახლა გამოვიყენოთ მონაცემები

თეორიულად, სერვერის მხრიდან რენდერი შექმნილია ორი პრობლემის გადასაჭრელად: არ დაზარალდეს საძიებო სისტემის შეზღუდვები. SPA ინდექსირება და გააუმჯობესე მეტრიკა FMP (აუცილებლად გაუარესება TTI). კლასიკურ სცენარში რომ საბოლოოდ ჩამოყალიბებულია Airbnb-ზე 2013 წელს წელი (ჯერ კიდევ Backbone.js-ზე), SSR არის იგივე იზომორფული JS აპლიკაცია, რომელიც მუშაობს Node გარემოში. სერვერი უბრალოდ აგზავნის გენერირებულ განლაგებას მოთხოვნის პასუხად. შემდეგ ხდება რეჰიდრატაცია კლიენტის მხარეს და შემდეგ ყველაფერი მუშაობს გვერდის გადატვირთვის გარეშე. Habr-ისთვის, ისევე როგორც ტექსტური შინაარსის მქონე მრავალი სხვა რესურსისთვის, სერვერის რენდერი გადამწყვეტი ელემენტია საძიებო სისტემებთან მეგობრული ურთიერთობების დამყარებისთვის.

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

რატომ? ამ კითხვაზე ზუსტი პასუხი არ არსებობს. ან მათ არ სურდათ სერვერის პასუხის ზომის გაზრდა, ან სხვა არქიტექტურული პრობლემების გამო, ან უბრალოდ არ აიღო. ამა თუ იმ გზით, მდგომარეობის გამორთვა და ყველაფრის ხელახლა გამოყენება, რაც სერვერმა გააკეთა, საკმაოდ სათანადო და სასარგებლო ჩანს. ამოცანა რეალურად ტრივიალურია - მდგომარეობა უბრალოდ ინექციაა შესრულების კონტექსტში და Vue ავტომატურად ამატებს მას გენერირებულ განლაგებაში, როგორც გლობალური ცვლადი: window.__INITIAL_STATE__.

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

გარდა ამისა, UGC კონტენტთან ურთიერთობისას უნდა გახსოვდეთ, რომ მონაცემები უნდა გადაკეთდეს HTML ერთეულებად, რათა არ დაირღვეს HTML. ამ მიზნებისთვის ჩვენ ვიყენებთ he.

გადახაზვის მინიმიზაცია

როგორც ზემოთ მოყვანილი დიაგრამადან ხედავთ, ჩვენს შემთხვევაში, ერთი Node JS ინსტანცია ასრულებს ორ ფუნქციას: SSR და „proxy“ API-ში, სადაც ხდება მომხმარებლის ავტორიზაცია. ეს გარემოება შეუძლებელს ხდის ავტორიზაციას, სანამ JS კოდი მუშაობს სერვერზე, ვინაიდან კვანძი ერთნაკადიანია და SSR ფუნქცია სინქრონულია. ანუ სერვერი უბრალოდ ვერ აგზავნის თხოვნებს საკუთარ თავს, სანამ ქოლსტაკი რაღაცით არის დაკავებული. აღმოჩნდა, რომ ჩვენ განვაახლეთ მდგომარეობა, მაგრამ ინტერფეისმა არ შეწყვიტა ტრიალი, რადგან კლიენტზე მონაცემები უნდა განახლებულიყო მომხმარებლის სესიის გათვალისწინებით. ჩვენ უნდა გვესწავლებინა ჩვენს აპლიკაციას სწორი მონაცემების საწყის მდგომარეობაში მოთავსება, მომხმარებლის შესვლის გათვალისწინებით.

პრობლემის მხოლოდ ორი გამოსავალი იყო:

• დაურთეთ ავტორიზაციის მონაცემები კროსსერვერის მოთხოვნებს;
• გაყავით Node JS ფენები ორ ცალკეულ ინსტანციად.

პირველი გამოსავალი მოითხოვდა სერვერზე გლობალური ცვლადების გამოყენებას, ხოლო მეორემ ამოცანის შესრულების ვადა მინიმუმ ერთი თვით გაახანგრძლივა.

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

ამ ლოგიკით და პრობლემის სწრაფად გადაჭრის საკუთარი სურვილით, ავირჩიე გლობალური ცვლადები. და, როგორც ხშირად ხდება, ადრე თუ გვიან უნდა გადაიხადო მათთვის. გადავიხადეთ თითქმის მაშინვე: ვიმუშავეთ შაბათ-კვირას, გავარკვიეთ შედეგები, დავწერეთ სიკვდილის შემდეგ და დაიწყო სერვერის ორ ნაწილად გაყოფა. შეცდომა ძალიან სულელური იყო და მისი გამრავლება ადვილი არ იყო. და დიახ, ამის სირცხვილია, მაგრამ ასე თუ ისე, დაბრკოლება და კვნესა, ჩემი PoC გლობალური ცვლადებით მაინც შევიდა წარმოებაში და საკმაოდ წარმატებით მუშაობს, სანამ ელოდება ახალ „ორკვანძიან“ არქიტექტურაზე გადასვლას. ეს მნიშვნელოვანი ნაბიჯი იყო, რადგან ფორმალურად მიზანი მიღწეული იყო - SSR-მ ისწავლა სრულიად მზა გვერდის მიწოდება და UI გახდა ბევრად უფრო მშვიდი.

მობილური Habr ინტერფეისი რეფაქტორირების პირველი ეტაპის შემდეგ

საბოლოო ჯამში, მობილური ვერსიის SSR-CSR არქიტექტურა იწვევს ამ სურათს:

"ორი კვანძის" SSR-CSR წრე. Node JS API ყოველთვის მზად არის ასინქრონული I/O-სთვის და არ არის დაბლოკილი SSR ფუნქციით, რადგან ეს უკანასკნელი განლაგებულია ცალკეულ ინსტანციაში. შეკითხვის ჯაჭვი #3 არ არის საჭირო.

დუბლიკატი მოთხოვნების აღმოფხვრა

მანიპულაციების ჩატარების შემდეგ გვერდის თავდაპირველმა რენდერმა ეპილეფსიის პროვოცირება აღარ გამოიწვია. მაგრამ Habr-ის შემდგომმა გამოყენებამ SPA რეჟიმში მაინც გამოიწვია დაბნეულობა.

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

პოსტის არხზე დაბრუნება იწვევს მონაცემთა ახალი მოთხოვნის პროვოცირებას

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

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

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

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

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

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

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

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

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

სტატიების სიის გამომავალი ასევე გახდა უფრო გამჭვირვალე: iterator კომპონენტი იმეორებს მასივის მეშვეობით სტატიის ID-ებით და ხატავს სტატიის teaser კომპონენტს, გადასცემს Id-ს საყრდენად, ხოლო შვილი კომპონენტი, თავის მხრივ, იღებს საჭირო მონაცემებს. სტატიების სია. როდესაც მიდიხართ პუბლიკაციის გვერდზე, ვიღებთ უკვე არსებულ თარიღს სტატიების სია, ვთხოვთ გამოტოვებული მონაცემების მოპოვებას და უბრალოდ დავამატებთ არსებულ ობიექტს.

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

ჩამოტვირთვა უფრო სასიამოვნოს გახდის

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

ჰაბრა დატვირთვა

ასახავს

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

ყველა ამ ცვლილების გამოქვეყნების შემდეგ, ჩვენ მივიღეთ დადებითი გამოხმაურება და ეს ძალიან, ძალიან სასიამოვნო იყო. ეს შთამაგონებელია. Გმადლობთ! დაწერე მეტი.

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

წყარო: www.habr.com