34-წუთიანი სამუშაო სესია იმაზე, როგორ გავავლოთ საზღვრები ბრაუზერში — მოდულების დაწყვილებიდან, მონორეპოებისა და მოდულური მონოლითის გავლით, მიკროფრონტენდებამდე და Module Federation-მდე. ერთი გულახდილი გზავნილით: აირჩიეთ უფრო მარტივი ვარიანტი მანამ, სანამ ნამდვილად შეგიძლიათ.
ყველაფერი, რაც დაწყვილებისა და კოჰეზიის შესახებ OOP & არქიტექტურიდან იცით, პირდაპირ ბრაუზერშიც გადმოდის. მოდულური ფრონტენდი ის არის, სადაც ერთი ფუნქციონალის პოვნა, შეცვლა და გაშვება შეგიძლიათ ისე, რომ მთელი აპლიკაცია არ გამოათრიოთ. ეს დეკი კონკრეტულად ბილდის კუთხეს ეხება — როგორ აისახება ეს საზღვრები ფაილებზე, პაკეტებზე და დეპლოებზე.
../../checkout/internals/tax). შეეხებით ერთ ფუნქციონალს და CI-ში სრულიად უკავშირო ეკრანი ტყდება.utils/ დირექტორია ფლობს თარიღების არითმეტიკას, API გამოძახებებს და თარიღის ამრჩევს. მისი დასახელება ვერავინ ახერხებს, ამიტომ მას ყველაფერი იმპორტს უკეთებს.მოდულარიზაცია წამალია როგორც კლასის დონეზე (OOP & არქიტექტურა), ისე სისტემის დონეზე (არქიტექტურული პატერნები & სტილები — ბექენდის ეკვივალენტი). აქ მას ბილდზე ვიყენებთ.
მარცხნივ: ყოველი ფუნქციონალი ყველა დანარჩენს იმპორტს უკეთებს. მარჯვნივ: ფუნქციონალები მხოლოდ საერთო, ცხადი კონტრაქტის გავლით ხვდებიან ერთმანეთს.
ერთსტრიქონიანი ტექსტური ცვლილება მთელ აპლიკაციას თავიდან აგებს და თავიდან დეპლოის. ნელი უკუკავშირი საზღვრების პრობლემაა და არა CI-ის.
ხუთი გუნდი, რომელიც ერთსა და იმავე routes.tsx-ს არედაქტირებს, ნიშნავს, რომ ყოველი PR ყველა დანარჩენს ეომება. მფლობელობა ბუნდოვანია, რადგან ნაკერებიც ბუნდოვანია.
მთელი დღის წესრიგი ესაა: ცვლილება ერთ, კარგად დასახელებულ ადგილს უნდა ეხებოდეს, აფეთქების რადიუსი კი იმ საზღვართან უნდა ჩერდებოდეს, რომელსაც თვალით ხედავთ.
ნებისმიერ დახვეწილ არქიტექტურამდე ირჩევთ, როგორ განლაგდება რეპოზიტორიები. ეს მიკროფრონტენდებისგან დამოუკიდებელია — მოდულურ მონოლითსაც და მიკროფრონტენდულ სისტემასაც ორივე განლაგებაში შეუძლია ცხოვრება. ჯერ ტერმინოლოგია დაალაგეთ.
მონორეპო: საერთო კოდი დირექტორიაა, რომელსაც პირდაპირ იმპორტს უკეთებთ. პოლირეპო: საერთო კოდი გამოქვეყნებული პაკეტია, რომლის ვერსიასაც ამაგრებთ.
workspace არის მონორეპოს ფუნქციონალი (npm-ში, pnpm-ში ან Yarn-ში), რომელიც ერთ აპლიკაციას საშუალებას აძლევს, მეზობელ პაკეტზე სახელით იყოს დამოკიდებული — @acme/ui — გამოქვეყნების ნაბიჯის გარეშე. პაკეტების მენეჯერი მას სიმლინკით აკავშირებს; რედაქტირება მთელ რეპოზიტორიაში მყისვე ჩანს.
მონორეპო ≠ მონოლითი, პოლირეპო ≠ მიკროფრონტენდები. კოდის განლაგება და რანტაიმის არქიტექტურა დამოუკიდებელი არჩევანებია — ნუ აურევთ ერთმანეთში.
სანამ აპლიკაციას ცალ-ცალკე დეპლოირებად ნაწილებად დაშლით, აიღეთ იაფად მოსაპოვებელი 90%: ერთი ბილდი, დალაგებული ფუნქციონალის მოდულებად, ისეთი საზღვრებით, რომლებსაც მართლა აღასრულებთ. სწორედ ეს არის ის ნაგულისხმევი ვარიანტი, რომელსაც გვინდა, რომ მიმართოთ.
ყოველი ფუნქციონალი ერთ index.ts კარს აქვეყნებს; დანარჩენი ყველაფერი პრივატულია. shared ქვემოთ დგას და მასზე ყველა არის დამოკიდებული.
index.ts მისი საჯარო API-ია; ღრმა გზები შიდა რჩება.no-restricted-imports ან Nx/Sheriff-ის საზღვრების კონფიგი) გვერდის ავლისას ბილდს აგდებს.shared-ზე და არასოდეს ერთმანეთის შიგთავსზე. იგივე წესი, რაც არქიტექტურულ პატერნებში: "დამოკიდებულებები შიგნით მიმართეთ".ჰგავს კარგად მოწესრიგებულ სახლს ჩაკეტილი ოთახებით — და არა ცალკეული შენობების ქუჩას, რომელზეც ფეხით უნდა იაროთ.
მიკროფრონტენდული არქიტექტურა მიკროსერვისების იდეას ბრაუზერამდე ავრცელებს: UI-ის ყოველ ნაჭერს ცალკე გუნდი ფლობს, აგებს და უშვებს საკუთარი რიტმით. მძლავრია — და, მიკროსერვისების მსგავსად, ხშირად ინერგება მანამ, სანამ ის ნამდვილად საჭირო გახდება.
მთელი პრობლემა კომპოზიციაა: როგორ იქცევა ცალ-ცალკე აგებული ნაჭრები მომხმარებლისთვის ერთ გვერდად? არსებობს ინტეგრაციის სამი მომენტი — და თითოეული სრულიად სხვანაირად ცვლის დამოუკიდებლობას სიმარტივეზე.
ყოველი გუნდი აქვეყნებს npm პაკეტს; ჰოსტი მათ აინსტალირებს და ბანდლში აერთიანებს. მარტივი და ტიპებით უსაფრთხო — მაგრამ გუნდის ცვლილება მხოლოდ მაშინ გადის, როცა ჰოსტი თავიდან დეპლოის. ნამდვილად დამოუკიდებელი არაა.
edge/სერვერის შრე ყოველი გუნდის სერვისიდან მიღებულ HTML ფრაგმენტებს ერთ დოკუმენტად კრავს (SSI, ESI ან თანამედროვე ფრეიმვორკები). შესანიშნავი პირველი დახატვა და SEO; ასაწყობად სერვერის ინფრასტრუქტურა სჭირდება.
შელი ყოველი გუნდის ბანდლს ცოცხლად, URL-ით ტვირთავს. გუნდი დეპლოის თავის ბანდლს და ის ჰოსტის თავიდან აგების გარეშე ჩნდება — დეპლოის ნამდვილი დამოუკიდებლობა. Module Federation სწორედ აქ ცხოვრობს (შემდეგში).
რელიზის ნამდვილ დამოუკიდებლობას მხოლოდ სერვერზე და რანტაიმში ინტეგრაცია იძლევა. თუ მიკროფრონტენდებს დანერგავთ და ბილდის დროზე დარჩებით, სირთულეში უკვე გადაიხადეთ, დაწყვილება კი შეინარჩუნეთ.
Module Federation არის ბანდლერის ფუნქციონალი, რომელმაც რანტაიმის მიკროფრონტენდები პრაქტიკული გახადა. ერთი აპლიკაცია (ჰოსტი) ქსელით ტვირთავს კოდს, რომელსაც მეორე (რემოუთი) აქვეყნებს, და ისინი საერთო ბიბლიოთეკებს იზიარებენ, რომ React ხუთჯერ არ გაიგზავნოს.
ჰოსტი feed/Feed-ს რემოუთის remoteEntry.js-იდან აიმპორტებს; ორივე ერთსა და იმავე React-ის ინსტანციას იზიარებს.
გაუშვით რემოუთი და ჰოსტი მას შემდეგივე ჩატვირთვაზე აიღებს — შეთანხმებული რელიზის გარეშე. სწორედ ამ შესაძლებლობას ყიდულობდით.
singleton-ის შეუსაბამობა (React-ის ორი მაჟორული ვერსია) რანტაიმში ჰუკებს ამტვრევს. საერთო ვერსიები გუნდებს შორის უნდა მართოთ — კონტრაქტები კომპილაციის დროიდან რანტაიმში გადადის.
რემოუთი შეიძლება იყოს ჩავარდნილი, ნელი ან 404. ახლა გჭირდებათ ჩანაცვლებები, შეცდომების საზღვრები და ვერსიის შემოწმებები, რომლებსაც ბანდლერი ადრე უფასოდ გაძლევდათ.
ნუ აურევთ ერთმანეთში. მონორეპოს ინსტრუმენტები დიდი რეპოზიტორიის აგებასა და ტესტირებას აჩქარებს; ინტეგრაციის ინსტრუმენტები ცალ-ცალკე აგებულ UI-ებს ერთად კერავს. ხშირად გჭირდებათ მონორეპოს ინსტრუმენტი და არავითარი ინტეგრაციის ინსტრუმენტი.
უბრალოდ პაკეტების მენეჯერის workspace ფუნქციონალი — აკავშირებს მეზობელ პაკეტებს, აერთიანებს ინსტალაციებს.
ქეშირებადი ამოცანების გრაფი თქვენს არსებულ სკრიპტებზე — თავიდან მხოლოდ შეცვლილი იგება.
ქეშირება პლუს პროექტის გრაფი, კოდის გენერატორები და აღსრულებადი მოდულების საზღვრები.
ბანდლერის დონის რემოუთები საერთო დამოკიდებულებებით (Webpack/Rspack; Vite-ის პლაგინი).
თემის პლაგინი, რომელსაც federation Vite/Rollup ბილდებში შემოაქვს.
როუტერი, რომელიც ერთ გვერდზე მთელ ფრეიმვორკულ აპლიკაციებს რთავს და თიშავს.
ბრაუზერის საკუთარი საზღვარი — ცალკე დოკუმენტი თითო ნაწილზე.
შენიშნეთ: მონორეპოს ინსტრუმენტი თითქმის ყველას სჭირდება; ინტეგრაციის ინსტრუმენტი — გაცილებით ნაკლებს. მეორე მხოლოდ მაშინ აიღეთ, როცა დეპლოის საზღვარი რეალური, დღევანდელი მოთხოვნაა — და არა ოდესღაც სამომავლო.
მიკროსერვისების მსგავსად, ისინი ორგანიზაციულ პრობლემას წყვეტს (დამოუკიდებელი გუნდები დამოუკიდებლად უშვებენ რელიზებს) რეალური ტექნიკური ფასის სანაცვლოდ. თუ ორგანიზაციული პრობლემა არ გაქვთ, ამ ფასს ტყუილად იხდით.
დუბლირებული ფრეიმვორკის payload მიდის მომხმარებლებთან, თუ გაზიარება იდეალური არაა — რეალური Core Web Vitals გადასახადი.
რანტაიმის ჩავარდნის ზედაპირი: ყოველი რემოუთი ქსელური დამოკიდებულებაა, რომელსაც გვერდის გატეხვა შეუძლია.
ვერსიების მართვა გუნდებს შორის — ერთი დიზაინ-სისტემა და ფრეიმვორკის ერთი მაჟორი, სამუდამოდ კოორდინირებული.
მოდულური მონოლითი ამათგან არაფერს იხდის და მოდულარობის 90%-ს მაინც გაძლევთ. დაიწყეთ აქედან.
"სჭირდება თუ არა დღეს ორ გუნდს ერთი და იმავე UI-ის დეპლოი სხვადასხვა გრაფიკით?"
ამ დეკში ყველაფერი ამ ერთ კითხვამდე დაიყვანება. იხილეთ აგრეთვე მიკროსერვისების კომპრომისები — არქიტექტურული პატერნები & სტილები.
ხუთი სწრაფი კითხვა საზღვრებზე, რეპოებზე, მოდულურ მონოლითზე, მიკროფრონტენდებსა და Module Federation-ზე — მყისიერი შედეგი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში