სარჩევი[დამალვა][ჩვენება]
- მაშ, რა არის მოდულის ფედერაცია?
- რატომ მოდულის ფედერაცია?
- მოდულის ფედერაციის ძირითადი კომპონენტები
მოდულის ფედერაციის ძირითადი მახასიათებლები+-
- შესანიშნავი ვებ შესრულება
- ეფექტური განვითარება
- თვითგანკურნების უნარი და სიჭარბე
- საერთო დამოკიდებულებების ეფექტური მართვა
- იმის ნაცვლად, რომ მოგიწიოთ მომხმარებლების ხელახლა განლაგება, განათავსეთ დამოუკიდებელი კოდი.
- გაშვებისას, შემოიტანეთ კოდი სხვა კონსტრუქციებიდან.
- დეველოპერების გაძლიერებული გამოცდილება კლიენტის გამოცდილების შენარჩუნებისას
- მიკრო-ფრონტენდები ფუნქციონირებს მონოლითურად.
- დასკვნა
მიკრო ფრონტენდების კონცეფცია იყენებს მიკროსერვისებს ფრონტენდის განვითარებაში.
იდეა არის აპლიკაციის ან ვებსაიტის დაყოფა უფრო პატარა, დამოუკიდებლად შემუშავებულ ნაწილად, რომლებიც შემდეგ დაკავშირებულია მუშაობის დროს, განსხვავებით მათი შექმნისგან, როგორც ერთიანი, შეკრული მონოლითი.
მეთოდი საშუალებას გაძლევთ შექმნათ აპლიკაციის სხვა კომპონენტები სხვა ტექნოლოგიების გამოყენებით და დამოუკიდებელ გუნდებთან ერთად.
იდეა მდგომარეობს იმაში, რომ შემცირდეს ტიპიურ მონოლითთან დაკავშირებული ტექნიკური ხარჯები ამ გზით განვითარების სეგმენტირების გზით.
საშუალებას აძლევს მათ კონცენტრირდნენ აპლიკაციის კონკრეტულ სფეროზე, როგორც თანმიმდევრული გუნდი, ის ასევე შესაძლებელს ხდის backend-ისა და frontend-ის დეველოპერებს შორის თანამშრომლობის ახალ ფორმებს.
მაგალითად, შეიძლება გყავდეთ გუნდი, რომელიც მხოლოდ პასუხისმგებელია ძიების შესაძლებლობებზე ან ძირითადი პროდუქტის სხვა ასპექტზე, რომელიც გადამწყვეტია ბიზნესისთვის.
მოდულის ფედერაციის წყალობით, თქვენ გაქვთ საკმარისი ფუნქციონირება იმ სამუშაო პროცესის გასატარებლად მიკრო წინა ნაწილი მიახლოების მანდატები.
ეს პოსტი ღრმად განიხილავს მოდულის ფედერაციის არქიტექტურას, ასევე მის ძირითად მახასიათებლებს და აპლიკაციის შაბლონებს.
რა არის ა მოდულის ფედერაცია?
Javascript-ის მოდულის ფედერაციის დიზაინი იყენებს ხელახლა გამოყენებულ ნაწილებს მრავალ აპლიკაციაში.
ეს საკმაოდ საბაზისო ჟარგონია, მაგრამ მე უბრალოდ ვაჩვენე, რომ ასე მხიარულად გამოვიჩინე.
როგორც ჩვენ ყველანი ვიცნობთ React აპლიკაციის კომპონენტების გაზიარებას, Module Federation ეფექტურად ასრულებს იმავე მიზანს პრაქტიკაში, გარდა იმისა, რომ იგი დინამიურად ავლენს აპლიკაციის მოდულებს სხვა აპლიკაციების მოხმარებისთვის.
მოდულის ფედერაცია ცდილობს გადალახოს მოდულის გაზიარების პრობლემა განაწილებულ სისტემაში ამ ძირითადი საზიარო ელემენტების მიწოდებით, როგორც მაკრო ან მიკრო, როგორც სასურველია.
ეს მიიღწევა თქვენი აპებიდან და build workflow-დან მათი ამოღებით.
რატომ მოდულის ფედერაცია?
აქ არის რამდენიმე ფაქტორი, რომელსაც მოდულის ფედერაცია ადვილად უმკლავდება:
- გარე და DLL-ები (დინამიური ბმული ბიბლიოთეკები) იყო ყველაფერი, რაც ზოგჯერ გვქონდა აპებს შორის ფუნქციების გასაზიარებლად. ამ ყველაფერმა სკალირების კოდის გაზიარება უკიდურესად რთული გახადა.
- NPM არის დუნე.
- როდესაც ორი ცალკეული პროგრამა იზიარებს მნიშვნელოვან კოდს, ისინი უნდა იყოს დინამიური და მოქნილი.
იმისათვის, რომ დამოუკიდებელი აპლიკაციები იყოს მთლიანად საკუთარ საცავში, განლაგდეს ცალკე და ფუნქციონირებდეს როგორც საკუთარი დამოუკიდებელი SPA, შეიქმნა Module Federation.
მოდულის ფედერაციის ძირითადი კომპონენტები
სანამ ღრმად ჩაყვინთავთ, მნიშვნელოვანია მოკლედ განიხილოთ რამდენიმე ახალი კონცეფცია, რომელსაც მოდულის ფედერაცია მოაქვს.
- მასპინძელი: როდესაც გვერდი იტვირთება, თავდაპირველად ინიციალიზებულ build-ს ან მოდულს მასპინძელი ეწოდება. პროვაიდერი შეიძლება ჩაითვალოს მასპინძლად.
- დისტანციური: დისტანციური არის განსხვავებული კონსტრუქცია, რომელიც იყენებს ჰოსტის ნაწილს. მათ ასევე მოიხსენიებენ როგორც მომხმარებელს.
- ორმხრივი ჰოსტი: Webpack-ის კონსტრუქცია, რომელიც ფუნქციონირებს როგორც დისტანციური მართვის პულტით, რომელსაც სხვა ჰოსტები მოიხმარენ, ასევე მასპინძელი, რომელიც მოიხმარს დისტანციურ ტელეფონებს.
- გამყიდველის ფედერაცია: ჩართავს npm მოდულის დამოკიდებულების დეკლარაციულად გაზიარებულ გაზიარებას ჰოსტისთვის ან დისტანციური მართვისთვის, მიუხედავად იმისა, თუ სად არის ისინი ჩატვირთული. მიკრო ფრონტენტებთან მუშაობის ერთ-ერთი მთავარი პრობლემა ამ გზით მოგვარებულია.
ფედერირებული აპლიკაციის ნიმუშები
მარადმწვანე დიზაინის სისტემა
ფედერაციული აპლიკაციების ერთ-ერთი ყველაზე ძირითადი ფორმაა „მარადმწვანე დისტანციური პულტი“, რომელიც წარმოადგენს საერთო დისტანციურ პულტს, როგორიცაა „Design System“ ან „Component Library“, რომელიც დამოუკიდებლად ნაწილდება და განახლებულია ყველა მომხმარებლისთვის.
თითოეული აპლიკაციის გუნდს არ სჭირდება დროის დახარჯვა რევიზიებზე, ეს შეიძლება იყოს გამოსადეგი იმის უზრუნველსაყოფად, რომ ყველა ონლაინ საიტი იცავს უახლეს კორპორატიულ იდენტობას.
იმისათვის, რომ შეიმუშავონ და დაინერგონ საზღვრები და პროცედურები, რომლებიც აუცილებელია უსაფრთხო, მუდმივი განახლებების უზრუნველსაყოფად, ეს შეიძლება იყოს სასარგებლო ადგილი ბიზნესისთვის, რათა დაიწყონ ფედერირებული აპლიკაციის არქიტექტურის განხილვისას.
ქვემოთ მოცემულია გამოყენების რამდენიმე შემთხვევა, როდესაც დამოუკიდებლად განლაგებული საერთო დისტანციური პულტები შეიძლება იყოს შესაფერისი:
- დიზაინის სისტემები
- განაცხადის ჭურვები
- კომპონენტების ბიბლიოთეკები
- მომხმარებელთა
- საერთო ინსტრუმენტების ნაკრები
- განაწილების ალტერნატიული მოდელები ვიჯეტებისთვის, რომლებიც გამოიყენება შიდა ან გარედან
Multi-SPA მოდულის გაზიარება
ხელახლა გამოიყენეთ უკვე ექსპორტირებული ფუნქციები, როგორიცაა კომპონენტები, სხვადასხვა ცალკეულ ერთგვერდიან აპებში. უპირატესობებში შედის:
- მომხმარებლები იღებენ ავტომატურ განახლებებს
- დომენის ექსპერტიზა რჩება გუნდში, რომელიც მასზეა პასუხისმგებელი.
- ამარტივებს განლაგების პროცედურას, რადგან ცალკეული მოდულის გამოშვება საჭირო არ არის.
ჭურვის მართვადი ფედერაცია
ჭურვიზე ორიენტირებული ფედერაცია მოიცავს:
- პროდუქტის ახალი ვერსიის შექმნისას პროდუქტის გუნდი არ ელოდება Checkout-ის გუნდს სამუშაოს დასრულებას.
- დისტანციური მართვის გადართვისას გვერდის გადატვირთვა არ ხდება.
- საჭიროების შემთხვევაში, Shell გთავაზობთ ნელი დისტანციური დატვირთვისა და (უმაღლესი დონის) მარშრუტიზაციას.
- დისტანციურ პულტებზე მარშრუტირება შესაძლებელი ხდება გამყიდველის ფედერაციის მეშვეობით, რაც საშუალებას იძლევა ხშირად გამოყენებული npm პაკეტების ხელახალი გამოყენება.
- Shell გთავაზობთ ჩარჩოს და სხვა საერთო დამოკიდებულებებს, რომლებიც ხელახლა გამოიყენება ზარმაცი დატვირთული დისტანციური მართვის საშუალებით.
მრავალ ჭურვი ფედერაცია
ზემოთ აღწერილი ჭურვის ფედერაციის მსგავსი, მაგრამ გამოიყენება სხვადასხვა ჭურვები.
შეიცავს:
- ჭურვების რაოდენობა
- თეთრი მარკირება
- ყველა დისტანციური პულტი არ არის საჭირო Shell B-ს ან აქვს დამოუკიდებელი განხორციელება.
მოდულის ფედერაციის ძირითადი მახასიათებლები
შესანიშნავი ვებ შესრულება
ნორმალური NPM მოდულის შემადგენლობის პრობლემა ის არის, რომ დამოკიდებულების რაოდენობის მატებასთან ერთად, აპლიკაციის ზომა ზოგადად იზრდება.
იმისათვის, რომ თავიდან აიცილოთ პაკეტების ჩატვირთვა, როდესაც თქვენი აპლიკაცია იტვირთება და ჩატვირთოთ მხოლოდ საჭიროების შემთხვევაში, Module Federation გთავაზობთ შესაძლებლობას ზარმაცი ჩატვირთოთ პაკეტები.
ეს ხელს უშლის მოდულების ჩამოტვირთვის აუცილებლობას, სანამ ისინი რეალურად მოითხოვება, რაც აუმჯობესებს საიტის სიჩქარეს.
ეფექტური განვითარება
თითოეული პროექტი შეიძლება დამზადდეს და მიწოდებული იყოს იზოლირებულად და შეიძლება განხორციელდეს სხვადასხვა გუნდების მიერ, რადგან მოდულის ფედერაცია მოგიწოდებთ, მოაწყოთ თქვენი განაცხადი დისკრეტულ პროექტებად, რათა შეძლოთ მათი ცალკე (და შესაბამისად პარალელურად) შექმნა და განთავსება.
თვითგანკურნების უნარი და სიჭარბე
გაზიარებული დამოკიდებულებები საშუალებას აძლევს მოდულის ფედერაციას თვალყური ადევნოს თქვენი პროგრამის ყველა დამოკიდებულებას ერთ ადგილას.
ამ გზით, მაშინაც კი, როდესაც აპლიკაცია არ აცხადებს დამოკიდებულებას ან როდესაც არის ქსელის პრობლემები, მან მაინც იცის რა სჭირდება და შეუძლია საჭიროებისამებრ მისი ჩამოტვირთვა.
საერთო დამოკიდებულებების ეფექტური მართვა
გარდა ამისა, Module Federation გთავაზობთ უმაღლესი დამოკიდებულების მენეჯმენტს, ეფექტურად გადაჭრის მომწოდებლისა და მესამე მხარის მოთხოვნებს ისე, რომ თქვენი აპლიკაცია არასოდეს იტვირთება ბიბლიოთეკის ერთზე მეტ ვერსიაზე.
იმის ნაცვლად, რომ მოგიწიოთ მომხმარებლების ხელახლა განლაგება, განათავსეთ დამოუკიდებელი კოდი.
დეველოპერი ძალიან დაინტერესებულია მარადმწვანე ფუნქციონირებით. მას შემდეგ, რაც შეიცვლება დამოკიდებული ფუნქციონირება, აღარ იქნება საჭირო მომხმარებლების ხელახლა ინსტალაცია.
უნდა ვაღიარო, რომ ეს თავისთავად ძალიან ძლიერი თვისებაა, რომელიც საჭიროებს ფრთხილად გამოკვლევას მოულოდნელი შედეგების თავიდან ასაცილებლად.
გაშვებისას, შემოიტანეთ კოდი სხვა კონსტრუქციებიდან.
NPM პაკეტის მოდელის მიღებისას, შეიძლება განვიხილოთ აპლიკაციები, რომლებიც იყენებენ მოდულების ფედერაციას API-ების მსგავსი, ვიდრე კოდის გაზიარებისა და „ბიბლიოთეკაზე“ ფიქრის ნაცვლად.
ისევე, როგორც მათ შეუძლიათ მიიღონ ფუნქციონალობა სხვა აპებიდან, ვებ აპლიკაციებს ახლა შეუძლიათ უზრუნველყონ ფუნქციონირება სხვა აპლიკაციებისთვის.
დეველოპერების გაძლიერებული გამოცდილება კლიენტის გამოცდილების შენარჩუნებისას
ნებისმიერი JavaScript დეველოპერი საკმაოდ კომფორტული იქნება Module Federation-ით, რადგან ეს არის Webpack მოდული, რომელიც ხელმისაწვდომია Webpack 5 ვერსიიდან.
ეს რეალურად საკმაოდ ძლიერი და დამაინტრიგებელია, თუ ცოტა დავფიქრდებით.
მესამე მხარის Webpack loaders-ის გამოყენებით, განიხილეთ ყველა ის კომპონენტი, რომელიც ვებგვერდი პაკეტები, მათ შორის სკრიპტები, აქტივები, სტილები, სურათები, ნიშნები და სხვა.
მოდულის ფედერაციის გამოყენებით, ამ ყველაფრის გაზიარება და დაკავშირება შესაძლებელია.
მიკრო-ფრონტენდები ფუნქციონირებს მონოლითურად.
საკმაოდ მარტივია თქვენს აპლიკაციას საერთო ფუნქციების დამატება; უბრალოდ შემოიტანეთ პაკეტი ჩვეულებრივად ან გამოიყენეთ სინქრონული ჩატვირთვა.
ალტერნატიულად, ასინქრონული დატვირთვა შეიძლება გამოყენებულ იქნას მხოლოდ დამოკიდებულებების ჩასატვირთად, საჭიროების შემთხვევაში, ზარმაცი დატვირთვის გამოყენებით.
დასკვნა
ამ პოსტში, ჩვენ განვიხილეთ მოდულების ფედერაცია, როგორც ფანტასტიკური არჩევანი თქვენი მიკრო-ფრონტენდის აპლიკაციის შესაქმნელად.
აპლიკაციების გაცვლის და ფუნქციონირების გამოყენების უფლება გაშვების დროს ხელს უწყობს მასშტაბურობას სხვადასხვა გუნდებს საშუალებას აძლევს იმუშაონ დამოუკიდებელ აპლიკაციებზე.
როდესაც საერთო ფუნქციონალობა იცვლება, თქვენ არ დაგჭირდებათ თქვენი მომხმარებლების დიზაინი და დანერგვა, რადგან ის მხარს უჭერს მარადმწვანე ფუნქციონირებას.
თქვენი პროგრამა იმუშავებს როგორც მონოლითი დაყენების შემდეგ, რაც ფანტასტიკურია.
გაზიარებადი დამოკიდებულებები გამოიყენება აპების ზომის შესამცირებლად. ვინაიდან ბევრი დეველოპერი უკვე იცნობს Webpack გარემოს, დეველოპერის გამოცდილება შესანიშნავია.
დატოვე პასუხი