სარჩევი[დამალვა][ჩვენება]
- შესავალი მიკრო ფრონტ-ენდის არქიტექტურაში
Micro frontend-ის დადებითი მხარეები +-
- განვითარება სწრაფად ავტონომიურ გუნდებში
- ინდივიდუალური მიკრო ფრონტენტების მცირე კოდების ბაზა იწვევს უფრო სუფთა კოდს
- გაუმჯობესებული აპლიკაციის სტაბილურობა ფხვიერი შეერთების გამო
- ინდივიდუალური მახასიათებლების ტესტირება უფრო მარტივია
- პაკეტის შემცირებული ზომა იწვევს გვერდის უფრო სწრაფ დატვირთვას
- ტექნოლოგიური დამოუკიდებლობა
- დასკვნა
მიკროსერვისების იდეამ ბოლო დროს დიდი ყურადღება მიიპყრო და ბევრი ფირმა იყენებს მას დიდი, მონოლითური საყრდენის მოსაშორებლად.
იმავე მარშრუტის წინსვლა კვლავ გამოწვევაა მრავალი ბიზნესისთვის, მაშინაც კი, თუ ვებ აპლიკაციების სერვერის მხრიდან აგების ეს განაწილებული მეთოდი მეტ-ნაკლებად საიმედოა კვლევისა და შესრულების თვალსაზრისით.
მჭიდრო დამოკიდებულების გამო, კლიენტის მხარის მონოლითი, როგორც წესი, ართულებს ახალი ფუნქციების ინტეგრირებას, ახალი ტექნოლოგიების მიღებას და ინდივიდუალური კომპონენტების მასშტაბურობას.
ამ და სხვა გამოწვევებმა აიძულა frontend-ის დეველოპერები გამოიკვლიონ მიკროსერვისების გამოყენებით.
შედეგად, შეიქმნა სრულიად ახალი არქიტექტურული სტრატეგია, რომელიც ცნობილია როგორც მიკრო ფრონტენტი, ვებსაიტების და ვებ აპლიკაციების წინა ფენის შესაქმნელად.
ტერმინი პირველად 2016 წელს გამოიყენეს და მას შემდეგ დიდი ყურადღება მიიპყრო კარგი მიზეზის გამო.
ეს სტატია მისცემს ზოგად გაგებას იმის შესახებ, თუ რა არის მიკრო ფრონტენტები და რა საკითხებს ეხება ისინი. ის მუშაობს, ისევე როგორც დადებითი და უარყოფითი მხარეები.
შესავალი მიკრო ფრონტ-ენდის არქიტექტურაში
ფრონტ-ენდის განვითარების თანამედროვე მეთოდი, რომელსაც მიკრო-ფრონტენდის არქიტექტურა ჰქვია, იყოფა ა ვებ აპლიკაცია პატარა, დამოუკიდებელ ნაწილებად.
საბოლოო მომხმარებლისთვის ეს ნაწილები ერთ ერთეულად გამოიყურება, მაშინაც კი, თუ ისინი დამოუკიდებლად აშენდა და შემდეგ ერთად იყო.
იმ განსხვავებით, რომ მიკრო ფრონტენტები ეხება ონლაინ გადაწყვეტილებების კლიენტს და არა სერვერის მხარეს, მათი საფუძველი იდენტურია მიკროსერვისების.
დახვეწილი ვებ პროდუქციის დამზადება ყველაზე ლოგიკურია მიკრო ფრონტენდის მიდგომის გამოყენებისას.
მიკრო ფრონტენტები, განსხვავებით უფრო ჩვეულებრივი ფრონტ-ენდის მონოლითისგან, საშუალებას აძლევს ბევრ გუნდს ცალკე ითანამშრომლოს სხვადასხვა პროგრამულ პროექტებზე.
პროგრამისტებს შეუძლიათ შექმნან ვებ აპლიკაციები უფრო სწრაფად და უფრო დიდი მასშტაბურობით და შენარჩუნებით ამ არქიტექტურული დიზაინის გამოყენებით.
მარტივად რომ ვთქვათ, თითოეული მიკრო წინა ნაწილი არის მხოლოდ კოდის ნაწილი ვებ გვერდის ცალკეული კომპონენტისთვის.
ამ მახასიათებლებს აკონტროლებენ ცალკეული გუნდები, რომელთაგან თითოეული სპეციალიზირებულია გარკვეულ ინდუსტრიაში ან ობიექტზე.
მონოლითური vs Microservices vs Micro frontend არქიტექტურა
იფიქრეთ გადაადგილებაზე. თქვენთვის უფრო მარტივი იქნება ყველაფრის ორგანიზება რამდენიმე პატარა, პროფესიონალურად მონიშნულ ყუთებში და თითოეულის ცალკე გადატანა ან მთელი პერსონალის ერთ უზარმაზარ ყუთში ჩალაგება და ახალ ადგილას გადატანა?
აშკარა გამოსავალი არსებობს.
ეს ანალოგია ადარებს ორ განსხვავებულ ვებ აპლიკაციის არქიტექტურას, მონოლითებსა და მიკროსერვისებს (ასევე ცნობილია როგორც მიკრო ფრონტენტები).
მონოლითური არქიტექტურა
თქვენ შეიძლება გაიხსენოთ „ძველი კარგი დღეები“, როდესაც შეიქმნა სრული აპლიკაცია, როგორც ერთიანი, შეკრული ერთეული. ასეთ მეთოდს მონოლითი ეწოდება, რაც ძველი ტერმინია დიდი ქვის ბლოკისთვის.
ეს აზრი აქვს.
მონოლითურ სისტემებს აქვთ ურთიერთდამოკიდებული ელემენტები. ამიტომ, თუ გსურთ რაიმეს შეცვლა ან ახალი ფუნქციის დამატება, შესაძლებელია მთელი სისტემა დაირღვეს.
მიუხედავად იმისა, რომ ის მოძველებულია, ზოგჯერ მაინც არსებობს. დიახ, ჩვენ ვიცით თქვენი ამჟამინდელი გამოხატვის შესახებ.
კოდების ბაზის კონცეპტუალური დაყოფა ორ განსხვავებულ კომპონენტად - წინა ნაწილი (კლიენტის მხარე) და უკანა ნაწილი (სერვერის მხარე) - გარდაუვალი გახდა ახალი ტექნოლოგიების განვითარებისა და პროგრამული პროდუქტების გართულების გამო.
ოპერაციის ყველაზე პოპულარული მეთოდი ახლა არის შეშფოთების გამიჯვნა პრეზენტაციის ფენას შორის, რომელთანაც საბოლოო მომხმარებელი ურთიერთობს და ყველაფერს, რაც ხდება ფონზე.
მას ესაჭიროება ორი პროგრამული უზრუნველყოფის ინჟინერიის გუნდი, წინა ჯგუფის გუნდი, რომელიც აშენებს ვიზუალურ კომპონენტებს, ხოლო უკანა გუნდის გუნდი აშენებს ვებ სერვისებს, ბიზნეს ლოგიკას, მონაცემთა წვდომას, ინტეგრაციას და ა.შ.
თუმცა, მიუხედავად ამ განცალკევებისა, ეს სტრატეგია ბუნებით მაინც მონოლითური რჩება.
მთავარი ცვლილება ის არის, რომ ჩვენ ახლა გვაქვს ორი მნიშვნელოვანი კოდის ბლოკი - წინა ნაწილი და უკანა ნაწილი - ერთი უზარმაზარი აპლიკაციის ნაცვლად. მონოლითური არქიტექტურა არ უნდა იყოს საშინელი; მათ აქვთ რამდენიმე სარგებელი, მათ შორის
- მარტივი და სწრაფი განვითარება პაწაწინა აპლიკაციებისთვის ერთი წყაროს კოდის ბაზით და ძალიან მარტივი დიზაინით;
- ტესტირება და გამართვა ძალიან მარტივია, რადგან ყველა კოდი არის ერთ ადგილას, რაც აადვილებს გუნდს მოთხოვნის ნაკადის თვალყურის დევნებას და შეცდომების იდენტიფიცირებას;
- აპლიკაციის შემუშავების დასაწყისში ხარჯები უფრო იაფია, რადგან არც ინფრასტრუქტურის და არც განვითარების ხარჯები არ არის გაწეული ახალი ფუნქციების დამატებამდე.
ამ სტრატეგიის ნაკლოვანებები აისახება
- შეზღუდული განლაგების მოქნილობა – გუნდებმა უნდა დაიცადონ, თუ პროექტზე მუშაობენ მხოლოდ რამდენიმე მათგანი და ახალი განლაგება საჭიროა ყოველ ჯერზე, როდესაც თქვენ განაახლებთ კოდს;
- ახალი ტექნოლოგიების მიღება რთულია, რადგან ამის გაკეთება მოითხოვს მნიშვნელოვანი ნაწილის გადაწერას, თუ არა მთელი პროექტის.
- როდესაც დეველოპერების რაოდენობა იზრდება, კოდის სისტემა ხდება მჭიდროდ დაკავშირებული, გართულებული და ძნელი სამართავი და გასაგები.
- ორგანიზაციული საკითხები - გუნდის თითოეულმა წევრმა უნდა გამოიყენოს ბიბლიოთეკების ერთი და იგივე ვერსია და მოახსენოს ნებისმიერი ცვლილება, თუ ბევრი გუნდი მუშაობს მონოლითურ პროექტზე.
- შეშფოთება მასშტაბურობასთან დაკავშირებით – რადგან პროექტის კომპონენტები ურთიერთდაკავშირებულია, მათი ცალ-ცალკე მასშტაბირება წარმოშობს სირთულეებს, რაც იწვევს მნიშვნელოვან შეფერხებას და უფრო დიდ ხარჯებს.
- პროექტის რთული ლოგიკის გაგება შეიძლება რთული იყოს გუნდის ახალი წევრებისთვის, განსაკუთრებით იმ შემთხვევაში, თუ ინჟინრები, რომლებიც თავდაპირველად მუშაობდნენ მასზე, აღარ არიან დასაქმებულები.
მიკროსერვისების და მათი ახლო ნათესავების და მიკრო ფრონტენდების განვითარებამ მონოლითური სისტემების პირველადი პრობლემები გადაჭრა.
მიკროსერვისების არქიტექტურა
არქიტექტურული მეთოდი, რომელიც ცნობილია როგორც მიკროსერვისები, საშუალებას გაძლევთ შექმნათ მრავალი თავისუფლად დაკავშირებული და დამოუკიდებლად განლაგებული პატარა კომპონენტი ან სერვისი, რომლებიც ქმნიან აპლიკაციის ფონს.
ყველა სერვისს აქვს საკუთარი კოდების ბაზა, CI/CD მილსადენები, DevOps პროცედურები და მათი გაშვების პროცესები.
თქვენ ხედავთ, რომ მონოლითური ბექენდის გუნდი დაყოფილია ცალკეულ გუნდებად ზემოთ სურათის დათვალიერებით.
თითოეული ინდივიდუალურად ფოკუსირებულია აპლიკაციის სხვადასხვა ასპექტზე (როგორიცაა პროდუქტის სერვისი, საძიებო სერვისი და გადახდის სერვისი).
სერვისებს შორის კომუნიკაცია ხდება დადგენილი პროტოკოლების მეშვეობით, რომლებიც ცნობილია როგორც API, როგორიცაა მსუბუქი REST API პროტოკოლი, რომელიც იყენებს სინქრონულ მოთხოვნა-პასუხის შაბლონებს.
კიდევ ერთი ვარიანტია ასინქრონული კომუნიკაციის გამოყენება კაფკას მსგავსი პროგრამული უზრუნველყოფის გამოყენებით, რომელიც გთავაზობთ გამოქვეყნების/გამოწერის კომუნიკაციის სტრუქტურებსა და მოვლენებს.
მიკროსერვისები ინტეგრირდება ფრონტენტთან წინა ნაწილის (BFF) სერვისის ან API Gateway-ის მეშვეობით ქსელის მეშვეობით. BFF გთავაზობთ მორგებულ API-ს თითოეული კლიენტისთვის, ხოლო API Gateways იძლევა წვდომის ერთ წერტილს მიკროსერვისების კოლექციისთვის.
მაგრამ ავტონომიური საფონდო კომპონენტების და ყველა უპირატესობის გათვალისწინებითაც კი, წინა ნაწილი მაინც მონოლითია.
ამიტომ, სწორედ აქ არის სასარგებლო მიკრო ფრონტენტები.
მიკრო ფრონტენტების არქიტექტურა
მიკროსერვისების მსგავსად, სადაც თავისუფლად დაკავშირებულ კომპონენტებს მართავს რამდენიმე გუნდი, მიკრო წინა ნაწილის არქიტექტურა იყენებს კონცეფციას ბრაუზერზე.
ეს ვებ აპლიკაციის მომხმარებლის ინტერფეისები მიჰყვება ამ სტრუქტურას, რომელიც შედგება გარკვეულწილად ავტონომიური კომპონენტებისგან.
გუნდები ასევე იქმნება კლიენტის საჭიროებებზე ან გამოყენების შემთხვევებზე და არა კონკრეტულ გამოცდილებაზე ან ტექნოლოგიაზე.
შესაბამისად, გუნდები ჩართულნი არიან მიკროსერვისებსა და მიკრო ფრონტენტ პროექტებში.
- ვერტიკალურად გაჭრილი — რადგან იმავე პროექტზე მუშაობენ წინა დეველოპერები, მონაცემთა ექსპერტები, ბექენდის ინჟინრები, QA ინჟინრები და ა.შ., ისინი ქმნიან თავიანთ ფუნქციებს. ინტერფეისი მონაცემთა ბაზებს; და
- ჯვარედინი ფუნქციონალური - გუნდის თითოეული წევრი წვლილს შეიტანს ჯგუფში.
გუნდებს ასევე შეუძლიათ აირჩიონ ტექნიკური დასტა, რომელიც საუკეთესოდ შეესაბამება მათ კონკრეტულ ბიზნესს.
ერთ გუნდს შეუძლია გამოიყენოს React მისი ფრაგმენტის დასაპროგრამებლად. სხვა გუნდი ქმნის ახალ Angular ვერსიას. Vue.js არის ერთ-ერთი ასეთი მაგალითი.
მიკრო ფრონტენტები გამოიყენება დაკავშირებულ მიკროსერვისებთან ერთად იმ პრობლემების გადასაჭრელად, რომლებიც განვითარების გუნდებს ჩვეულებრივ აქვთ მონოლითებთან. სტრატეგია გთავაზობთ შემდეგ უპირატესობებს.
- ტექნოლოგიის თავისუფლება: Frontend-ის ინჟინრებს შეუძლიათ აირჩიონ ალტერნატიული JavaScript ჩარჩოები, გაშვების დრო და მთელი ტექნოლოგიური დასტა კომპანიის საჭიროებიდან გამომდინარე. მოძველებული არქიტექტურის გარდა, შეიძლება გამოყენებულ იქნას ახალი ჩარჩო.
- მოქნილობის უფრო მაღალი ხარისხია შესაძლებელი, რადგან თითოეული მიკრო წინა ნაწილი არის დამოუკიდებელი და შესაძლებელია ცალკე შემუშავებული, ტესტირება, განლაგება და განახლება. შედეგად, თუ ერთი გუნდი მუშაობს მახასიათებლებზე და მოახდინა შეცდომების გამოსწორება, ხოლო მეორე გუნდს უნდა დაემატოს საკუთარი ფუნქცია, მათ არ უნდა დაელოდონ პირველი გუნდის დავალებას.
- ავტონომიური გუნდები და სისტემები: პროდუქტის თითოეულ გუნდს და, შესაბამისად, თითოეულ მახასიათებელს შეუძლია ფუნქციონირდეს სხვებზე მცირე დამოკიდებულებით, რაც საშუალებას აძლევს მას გააგრძელოს მუშაობა მაშინაც კი, როდესაც ახლომდებარე კომპონენტები მიუწვდომელია.
- მრავალჯერადი, პატარა კოდების ბაზა: თითოეულ მიკრო ფრონტენტს ექნება საკუთარი, უფრო მართვადი, პატარა კოდების ბაზა. ნაკლები ადამიანი გაამახვილებს ყურადღებას კონკრეტულ UI კომპონენტზე, გაამარტივებს კოდების მიმოხილვას და გააუმჯობესებს საერთო ორგანიზაციას.
- მარტივი აპლიკაციის სკალირება: მიკრო ფრონტენტების კიდევ ერთი უპირატესობა არის თითოეული მახასიათებლის ინდივიდუალურად სკალირების შესაძლებლობა. მონოლითებისგან განსხვავებით, სადაც მთელი პროგრამა უნდა იყოს მასშტაბირებული ყოველ ჯერზე ახალი ფუნქციის დამატებისას, ეს მთელ პროცესს უფრო ეფექტურს ხდის როგორც დროის, ასევე ფულის თვალსაზრისით.
როგორ მუშაობს მიკრო წინა ნაწილი?
როგორც უკვე აღვნიშნეთ, გუნდები ვერტიკალურადაა ორგანიზებული მიკრო წინა ნაწილის არქიტექტურაში, რაც ნიშნავს, რომ ისინი გამოყოფილია დომენის ცოდნით ან მიზნებით და პასუხისმგებელნი არიან თავიდან ბოლომდე კონკრეტული პროდუქტისთვის.
მას შეიძლება ჰქონდეს ერთი ან ორი საფონდო მიკროსერვისი, ასევე მცირე წინა ნაწილი. უფრო დეტალურად, მოდით განვიხილოთ ამ ვიზუალური ელემენტის მახასიათებლები, ურთიერთქმედება სხვა UI კომპონენტებთან და ინკორპორაცია მთავარ გვერდზე.
მიკრო წინა ნაწილი შეიძლება იყოს
- მთელი გვერდი (მაგ. პროდუქტის დეტალების გვერდი) ან
- გვერდის სექციები, რომლებიც შეიძლება გამოიყენონ სხვა გუნდებმა, როგორიცაა სათაურები, ქვედა კოლონტიტულები და საძიებო ზოლები.
თქვენ შეგიძლიათ დაყოთ დიდი ვებსაიტი რამდენიმე გვერდის ტიპად და თითოეული ტიპი გადასცეთ კონკრეტულ პერსონალს სამუშაოდ.
თუმცა, რამდენიმე კომპონენტი ხშირად გვხვდება მრავალ გვერდზე, როგორიცაა სათაურები, ქვედა კოლონტიტულები, შეთავაზებების ბლოკები და ა.შ. შემოთავაზების ბლოკი, მაგალითად, შეიძლება ჩართული იყოს მთავარ გვერდზე, პროდუქტის დეტალების გვერდზე ან თუნდაც გადახდის გვერდზე.
არსებითად, გუნდებს შეუძლიათ შექმნან ნაწილები, რომლებიც სხვა გუნდებს შეუძლიათ გამოიყენონ თავიანთ გვერდებზე.
თუმცა, მიკრო ფრონტენტები შეიძლება განთავსდეს ცალკე, როგორც სხვადასხვა პროექტები, განმეორებადი გამოყენების კომპონენტებისგან განსხვავებით.
ეს ყველაფერი ფანტასტიურად ჟღერს, მაგრამ ერთიანი ინტერფეისის შესაქმნელად, გვერდები და ფრაგმენტები როგორმე უნდა იყოს შერწყმული.
ეს მოითხოვს წინა ნაწილის ინტეგრაციას, რომელიც შეიძლება განხორციელდეს სხვადასხვა სტრატეგიის მეშვეობით, მათ შორის მარშრუტიზაციის, კომპოზიციისა და კომუნიკაციის (იხ. გრაფიკი ზემოთ).
მარშრუტიზაციის
როდესაც ერთი გუნდის მიერ კონტროლირებადი გვერდიდან სერვისი საჭიროა სხვა გუნდის კუთვნილ გვერდზე წვდომისთვის, მარშრუტიზაცია სასარგებლოა გვერდის დონეზე ინტეგრაციისთვის.
ყველა მიკრო წინა ნაწილი განიხილება როგორც ერთგვერდიანი აპლიკაცია. მარტივი HTML ბმულების გამოყენება შესაძლებელია მარშრუტიზაციის უზრუნველსაყოფად.
მომხმარებელს შეუძლია აიძულოს ბრაუზერი ჩამოტვირთოს სამიზნე მარკირება სერვერიდან და შეცვალოს მიმდინარე გვერდი ახლით ჰიპერბმულებზე დაწკაპუნებით.
აპლიკაციის გარსი არის HTML, CSS და JavaScript-ის მინიმალური მინიმუმი, რომელიც უზრუნველყოფს UI-ს. მაშინაც კი, თუ სერვერიდან მოთხოვნილი კონტენტის მონაცემები ჯერ კიდევ ელოდება, მომხმარებელი დაუყოვნებლივ მიიღებს სტატიკურ გამოსახულ გვერდს. აპლიკაციის ცენტრალური გარსი ემსახურება როგორც მშობელი აპლიკაცია სხვადასხვა გუნდის მიერ შექმნილი ერთგვერდიანი აპებისთვის.
არ აქვს მნიშვნელობა რა ბიბლიოთეკასა თუ ჩარჩოს, რომელიც გამოიყენება, მეტა-ჩარჩოები იძლევა სხვადასხვა გვერდის ერთ ერთში გაერთიანებას.
შემადგენლობა
კომპოზიცია არის ნაჭრების მოწყობის პროცესი, რათა მოთავსდეს ისინი გვერდზე შესაბამის სივრცეებში. უმეტეს შემთხვევაში, გუნდი, რომელიც ავრცელებს გვერდს, დაუყოვნებლივ არ იღებს ფრაგმენტის შინაარსს.
ამის ნაცვლად, ის ათავსებს ჩანაცვლების ადგილს ან მარკერს, სადაც ფრაგმენტი უნდა იყოს მარკირებაში.
განსხვავებული შედგენის პროცესის გამოყენებით, საბოლოო შეკრება სრულდება. კომპოზიცია შეიძლება დაიყოს ორ ძირითად კატეგორიად: კლიენტის მხარეს და სერვერის მხარეს.
კლიენტის მხარის შემადგენლობა: ვებ ბრაუზერი გამოიყენება HTML მარკირების შესაქმნელად და რედაქტირებისთვის. თითოეულ მიკრო ფრონტენდს აქვს შესაძლებლობა შეცვალოს და აჩვენოს მისი მარკირება დანარჩენი გვერდისგან განცალკევებით.
მაგალითად, ვებ კომპონენტები საშუალებას გაძლევთ განახორციელოთ ამ ტიპის მშენებლობა.
გეგმა არის თითოეული ფრაგმენტის გადაქცევა ვებ კომპონენტად, რომელიც შეიძლება დამოუკიდებლად დაინსტალირდეს, როგორც a.js ფაილი, რის შემდეგაც აპებს შეუძლიათ ჩატვირთონ და გადაიტანონ ისინი თემის განლაგებაში მათთვის გამოყოფილ სივრცეებში.
ვებ კომპონენტები დამოკიდებულია HTML-სა და DOM API-ზე, რომელთა გამოყენებაც სხვა ფრონტენდის ფრეიმვერებს შეუძლიათ, ასევე მონაცემთა გაგზავნისა და მიღების სტანდარტულ მეთოდს რეკვიზიტებისა და მოვლენების საშუალებით.
სერვერის შემადგენლობა: ამ დიზაინით, UI ნაწილები გაერთიანებულია სერვერზე, რის შედეგადაც მთლიანად ჩამოყალიბებული გვერდი იგზავნება კლიენტის მხარეს, რაც აჩქარებს ჩატვირთვას.
ასამბლეა ხშირად ხორციელდება ცალკეული სერვისის მიერ, რომელიც მდებარეობს ვებ ბრაუზერსა და ვებ სერვერებს შორის. CDN არის სერვისის (კონტენტის მიწოდების ქსელი) ერთ-ერთი მაგალითი.
თქვენ შეგიძლიათ აირჩიოთ ერთი ან ორი მათგანის კომბინაცია, თქვენი საჭიროებიდან გამომდინარე.
მიკრო ფრონტის კომუნიკაციის ნიმუშები
მიკრო-ფრონტენდის არქიტექტურა საუკეთესოდ მუშაობს მაშინ, როდესაც სხვადასხვა კომპონენტებს შორის მცირე ურთიერთქმედებაა. მიკრო ფრონტენტებს ზოგჯერ სჭირდებათ ერთმანეთთან საუბარი და ინფორმაციის გაზიარება. აქ არის რამდენიმე პოტენციური ნიმუში, რამაც შეიძლება გამოიწვიოს ეს.
- ვებ მუშები: ონლაინ მუშაკი არის მექანიზმი, რომელიც საშუალებას აძლევს ვებ კონტენტს JavaScript-ის ფონზე გაშვება, სხვა სკრიპტებისაგან დამოუკიდებლად და გვერდის სიჩქარეზე ზემოქმედების გარეშე. უნიკალური მუშა API უზრუნველყოფილი იქნება თითოეული მიკრო აპისთვის. ეს უპირატესობა ის არის, რომ შრომატევადი სამუშაო შეიძლება განხორციელდეს სხვა თემაში, რაც საშუალებას აძლევს UI თემას გააგრძელოს შენელების ან შეჩერების გარეშე.
- მოვლენის ემიტერი: ამ შემთხვევაში, ბევრი კომპონენტი ურთიერთობს ერთმანეთთან, უსმენს და მოქმედებს ნებისმიერი მდგომარეობის ცვლილებაზე იმ კომპონენტებში, რომლებზეც ისინი გამოწერილია. სხვა მიკრო ფრონტენტები, რომლებმაც გამოიწერეს ეს კონკრეტული ღონისძიება, პასუხობენ, როდესაც მიკრო ფრონტენდი ახორციელებს ამ მოვლენას. ღონისძიების ემიტერი, რომელიც დანერგილია თითოეულ მიკრო-ფრონტენდში, ამას შესაძლებელს ხდის.
- გამოძახებები და რეკვიზიტები: ამ განყოფილებაში თქვენ განსაზღვრავთ მშობელ კომპონენტს და შვილობილ კომპონენტებს. კომუნიკაცია ორგანიზებულია ხის მსგავს სტრუქტურაში. მშობელი კომპონენტები იყენებენ საყრდენებს, რათა გადასცენ მონაცემები, როგორც ფუნქციები კომპონენტის ხეზე შვილების კომპონენტებამდე. თავის მხრივ, ბავშვს შეუძლია ეფექტურად გააფრთხილოს მშობელი, როდესაც მათ მდგომარეობაში რაიმე ხდება, უკურეკვაზე რეაგირებით. React იყენებს ამ რეჟიმს.
Micro frontend-ის დადებითი მხარეები
განვითარება სწრაფად ავტონომიურ გუნდებში
დამოუკიდებელ გუნდს შეუძლია შექმნას ვებ აპის ან ვებსაიტის თითოეული ნაწილი მიკრო ფრონტენდის მეთოდის გამოყენებისას.
თითოეული გუნდი სრულიად ავტონომიურია, რაც იმას ნიშნავს, რომ იგი პასუხისმგებელია კომპონენტის განვითარების მთელ ციკლზე, კონცეფციიდან გამოშვებამდე და პოსტწარმოებამდე.
გარდა ამისა, ეს გულისხმობს, რომ სხვადასხვა გუნდს შეუძლია შეუფერხებლად ითანამშრომლოს იმავე პროექტზე ერთდროულად მუშაობისას.
აქედან გამომდინარე, გამოშვების ციკლები არსებითად უფრო სწრაფია, ვიდრე წინა ბოლო მონოლითების შემთხვევაში.
ინდივიდუალური მიკრო ფრონტენტების მცირე კოდების ბაზა იწვევს უფრო სუფთა კოდს
მონოლითურ წინა ბოლოებს აქვთ დიდი, უხერხული კოდების ბაზები, რომლებიც დროთა განმავლობაში სულ უფრო ქაოტური და რთულდება.
მიკრო ფრონტენტები ამ პრობლემას აგვარებენ. თითოეული მიკრო წინა ნაწილის წყაროს კოდი უფრო მართვადია, რადგან ის უფრო პატარა, მარტივი და კომპაქტურია.
შედეგად, მთლიანი ვებ გადაწყვეტა სარგებლობს უფრო სუფთა კოდით.
გაუმჯობესებული აპლიკაციის სტაბილურობა ფხვიერი შეერთების გამო
ვებ გადაწყვეტა იშვიათად შეიძლება დაიყოს სრულიად დამოუკიდებელ ნაწილებად. შესაბამისად, მიკრო ფრონტენტები ერთმანეთს ელაპარაკებიან.
თუმცა, კომპონენტებს შორის თითოეული კავშირი მნიშვნელოვანია, მიუხედავად ფხვიერი კავშირისა.
ერთი კომპონენტის წარუმატებლობა არ ახდენს გავლენას ყველა სხვა კომპონენტის მუშაობაზე, რაც უზრუნველყოფს ვებ გადაწყვეტის გაძლიერებულ სტაბილურობას.
ინდივიდუალური მახასიათებლების ტესტირება უფრო მარტივია
ეს სარგებელი გამოწვეულია მიკრო ფრონტენტების მახასიათებლებით. ამ არქიტექტურულ დიზაინზე დაყრდნობით, ვებ გადაწყვეტის კლიენტის მხარე არის მოდულარული და თითოეული მოდული არის ავტონომიური.
შედეგად, მომხმარებლის ინტერფეისის მცირე ნაწილის თავისთავად შეფასება უფრო ადვილია გუნდისთვის, ვიდრე მასიური მონოლითის ტესტირება.
პაკეტის შემცირებული ზომა იწვევს გვერდის უფრო სწრაფ დატვირთვას
ფუნქციებით მდიდარ მონოლითურ ვებ სისტემებში დაგვიანებული დატვირთვის დროის ერთ-ერთი მთავარი მიზეზი არის JavaScript პაკეტის ზომა. მეორეს მხრივ, მიკრო წინა ნაწილის მიდგომა აადვილებს გვერდის დატვირთვის დროის შემცირებას.
ბრაუზერს არ სჭირდება არასაჭირო კოდის განმეორებით ჩამოტვირთვა, რადგან ვებ გვერდი შედგება რამდენიმე პაწაწინა პაკეტებისგან. შედეგად, იზრდება გვერდის შესრულება და დატვირთვის დრო.
ტექნოლოგიური დამოუკიდებლობა
მრავალჯერადი წინა ბოლო ჩარჩოები შეიძლება გამოყენებულ იქნას დეველოპერების მიერ მიკრო-ფრონტენდის არქიტექტურით ერთი ონლაინ გადაწყვეტის შესაქმნელად.
ვინაიდან თითოეული კომპონენტი ავტონომიურია, ის შეიძლება აშენდეს იმ ტექნოლოგიის გამოყენებით, რომელიც საუკეთესოდ შეესაბამება გუნდის ამოცანებს.
ბუნებრივია, პროგრამისტებმა სიფრთხილე უნდა გამოიჩინონ პროგრამული უზრუნველყოფის პროექტისთვის ჩარჩოების არჩევისას, რომლებსაც ისინი ევალებათ და სხვა გუნდებთან კონსულტაციები კვლავ მკაცრად არის რეკომენდებული.
თუმცა, ნულოვანია იმის შანსი, რომ იძულებული გახდეთ გამოიყენოთ ძველი ჩარჩო აპის სიცოცხლის ხანგრძლივობის განმავლობაში.
Micro Frontend-ის უარყოფითი მხარეები
კომპლექსური ვებ გადაწყვეტის ტესტირება მთლიანად
ვებ გადაწყვეტის სხვადასხვა მოდულის ტესტირება მარტივია, როდესაც ის იყენებს მიკრო-ფრონენდის არქიტექტურას. თუმცა, ის განსხვავდება ვებ აპლიკაციის მთლიანობაში შეფასებისგან.
გადაამოწმეთ, რომ ყველა ნაწილი მუშაობს ისე, როგორც ეს იყო დაგეგმილი, სანამ გააგრძელებთ. ეს შეიძლება რთული იყოს, რადგან მიკრო ფრონტენტები დამოუკიდებლად მოქმედებენ და აქვთ მიწოდების ცალკეული პროცესები.
ძვირადღირებული საწყისი ინვესტიციები
მიკრო ფრონტენდის განვითარება, როგორც წესი, მოითხოვს მნიშვნელოვან ფინანსურ ხარჯებს. ძვირია მრავალი ფრონტ-ენდის გუნდის შეკრება და შენარჩუნება.
გარდა ამისა, დაგჭირდებათ მენეჯმენტის პერსონალი სამუშაოს ორგანიზებისთვის, დარწმუნდებით, რომ ყველაფერი კოორდინირებულია და გარანტირებულია შესანიშნავი გუნდური კომუნიკაცია.
განვითარებისა და განლაგების სირთულე
განვითარებისა და განლაგების პროცედურები შეიძლება უფრო გართულდეს მიკრო-ფრონენდის დიზაინის შედეგად.
მაგალითად, ერთსა და იმავე პროექტზე მომუშავე დამოუკიდებელი დეველოპერული ჯგუფების მიერ, გამოსავალი შეიძლება გადატვირთული იყოს ძალიან ბევრი კომპონენტით, რამაც შეიძლება გამოიწვიოს პრობლემები განლაგების ეტაპზე.
ყველა მოდულის სწორად შეკრება და მათი გლუვი ინტეგრაცია საერთო სქემაში ასევე ყოველთვის არ არის მარტივი; ეს ნამუშევარი, როგორც წესი, მოითხოვს ყველა დამოკიდებულების საფუძვლიან გაგებას.
მომხმარებლის გამოცდილებაში თანმიმდევრობის შენარჩუნების პრობლემები
თანმიმდევრული მომხმარებლის ინტერფეისის შენარჩუნება რთულია, როდესაც გუნდები ცალკე მუშაობენ პროგრამული უზრუნველყოფის რამდენიმე ნაწილზე.
ვებ გადაწყვეტა უნდა გაიზიაროს პროექტის ყველა დეველოპერმა. წინააღმდეგ შემთხვევაში, გზაზე შეიძლება ბევრი წინააღმდეგობა იყოს.
დასკვნა
Micro frontends, თანამედროვე არქიტექტურულ დიზაინს, შეუძლია მნიშვნელოვნად გააუმჯობესოს ფართომასშტაბიანი მიკროსერვისზე დაფუძნებული ვებ განვითარების პროექტების შესრულება.
ეს საშუალებას აძლევს პროგრამისტებს დაყოს სრული გადაწყვეტა დისკრეტულ ნაწილებად, რომლებიც შეიძლება შეიქმნას რამდენიმე ავტონომიური გუნდის მიერ. ამას მრავალი სარგებელი მოჰყვება, მათ შორის ფუნქციების უფრო სწრაფი გაშვება, ინდივიდუალური მოდულების უფრო მარტივი ტესტირება და უფრო შეუფერხებელი განახლებები.
მაგრამ არის გარკვეული სირთულეები მიკრო ფრონტებთანაც.
აპლიკაციის ყოვლისმომცველი ტესტირება, მაგალითად, შეიძლება იყოს რთული.
გარდა ამისა, იმის გამო, რომ ინჟინრებისა და ადმინისტრატორების დიდი გუნდია საჭირო, მიკრო ფრონტენდის პროექტები ძალიან ძვირია.
შესაბამისად, გადაწყვეტილების მიღებამდე უნდა გაითვალისწინოთ თქვენი ბიზნეს საქმის ყველა კომპონენტი.
ვლადიმერ ჩამაი
რატომღაც ვერ გავიგე, რა პრინციპით მუშაობს ფრონტენტზე ცალკეულ კომპონენტებს შორის კომუნიკაცია. არ მესმის, როგორ გინდა დააკავშირო კომპონენტები, რომლებიც შექმნილია სხვადასხვა ჩარჩოებში. ამის შესახებ სტატიაში არაფერია. მოვლენათა და მსმენელთა სისტემა დედამიწაზე ჯოჯოხეთად გამოიყურება. როგორ უნდა წარმოვიდგინოთ?