Son birkaç yıldır, ön uç topluluğu "mikro ön uç" (bundan sonra MF olarak anılacaktır) terimini aktif olarak tartışıyor ve kullanıyor. Farklı şirketler böyle bir   çözümü organize etmeye yönelik yaklaşımlarını paylaşıyor, ancak şu ana kadar MF'lerin Web'de çözmek için tasarlandığı sorunların, uygulanabilirlik kriterlerinin ve kullanımdaki sınırlamaların çok az açıklaması var. mimari  Bu yazıda MF'leri organize etmenin farklı yollarını karşılaştırmanın yanı sıra, hangi yaklaşımın nerede kullanılacağına dair öneriler oluşturmaya çalıştım.  Makale, bir projenin mimarisini tasarlarken ve süreçleri düzenlerken hem analistler ve geliştirme ekipleri için hem de MF'lerin tanıtılması daha yönetilebilir bir geliştirme sağlayabileceğinden ürün sahipleri için yararlı olabilir.  Mikro cephe yaklaşımı: nedir ve neden gereklidir?  MF tanımına geçmeden önce projelerde karşılaşılabilecek birkaç soruna bakalım:    . Bir projenin boyutu genellikle subjektiftir ve işlevsellik miktarına ve geliştiricilerin sayısına göre ampirik olarak belirlenebilir. 1-2 ön oyuncuyu bulmacalamak için yeterli işiniz varsa ve aynı zamanda "dirseklerini itmeyeceklerse" - bu küçük bir projedir, 3-6 orta ve 6-8'den fazlası zaten büyük bir projedir . Büyük bir projeniz var    . Yine ampirik olarak, bu 10'dan fazla ön uçtur, geri kalan katılımcılar sayılmaz. Kural olarak, bu büyüklükteki bir ekip, destek için belirli işlevleri üstlenen ve kendi analistlerini, destekçilerini ve QA'sını edinen alt ekiplere zaten bölünebilir. Büyük bir ekibiniz var    Tek bir geliştirici, alt ekibi için yalnızca bir kod parçasının bakımını yapabilir. Kodun geri kalanının iyileştirilmesi, konu alanının bilinmemesi veya üçüncü taraf mantığının uygulanmasının karmaşıklığı nedeniyle pahalı olabilir. Harika bir işlevselliğiniz var.  Sorunlar daha da kötüleşebilir:  yığını değiştirme arzusu;  İlgili projelerden oluşan bir aileyi desteklemek için bir şirket gereksinimi.  Bu kadar çok insan arasındaki ilişkileri nasıl organize edebilirsiniz? Bu ölçekte bir projede süreçleri nasıl inşa edebilirsiniz? Sorumluluk alanlarını nasıl doğru bir şekilde tanımlayabilirsiniz? Ne kadar çok sorun toplarsanız, mikro-ön yaklaşımın uygulamaya konulması o kadar değerli olur. Çünkü bu, kodun ve proje ekibinin ayrışmasına yönelik gelişimdeki evrimsel eğilimin doğal bir devamıdır.   Bu nedenle, MF yaklaşımı, monolitik bir cephenin, ayrı alt ekiplerin erişebildiği, ayrı depolarda saklanan ayrı kod tabanlarına bölünmesidir. Aynı zamanda kendi demo standlarına, testlerine ve yayın döngülerine sahip olabilirler/olmalıdırlar. Buna göre mikro ön kısım, arayüzün çıkarılabilir bir parçasıdır. Sayfaya bölmeye gerek yoktur, işlevsellik uçtan uca olabilir (örneğin kurumsal ui-kit).  Ayrı olarak, MF'lerin büyük bir projede geliştirme karmaşıklığının nasıl yönetileceğine ilişkin daha çok   olduğunun altını çizmek gerekir. MF'ler ön ucu hızlandırmanıza yardımcı olmayacak, hatta bazı uygulamalar tam tersine onu yavaşlatacaktır. Ancak bu yaklaşım, sorumluluk alanlarının tahsisi ve izole testler nedeniyle geliştirmeyi hızlandıracaktır.  organizasyonel bir karar  Mikro Ön Uçlar ve Tembel Yükleme Karşılaştırması  Tersine, MF'lerle karşılaştırıldığında   bahsetmeye değer. Farklı sorunları çözüyorlar, ancak bazen insanlar her şeyin tek bir şeyle ilgili olduğunu düşünüyor çünkü her iki durumda da uygulamayı "bölüyoruz". Tembel yüklemeden  Tembel yükleme, performans sorununu çözer: kullanıcıyı tüm ön uç paketini yüklemeye zorlamamak, gerekenden daha uzun süre beklememek ve istemcide ön tarafı nasıl daha hızlı başlatıp onunla daha erken etkileşime geçmeye nasıl başlanır.  MF'ler performans sorununu çözmez, hatta bazen daha da kötüleştirir. Ancak, yukarıdaki sorunları en aza indirerek, belirli bir alt ekip için daha rahat bir şekilde geliştirmenin organize edilmesine yardımcı olurlar.   Derleme Zamanı ve Çalışma Zamanı  Şimdi MF'leri tek uygulamada birleştirme yaklaşımından bahsedelim. Hangisini seçerseniz seçin, kullanıcıya tek bir uygulama gibi görünmelidir. Kullanıcı tarafında kod yürütme sırasında hem montaj aşamasında hem de dinamik olarak birleştirebilirsiniz.  Bu nedenle, MF'leri organize etmenin tüm yolları, yapım süresine veya çalışma zamanına atfedilebilir. Her birinin artıları ve eksileri vardır.  Yapım Zamanı  Çalışma süresi  Tip kontrolü  +  -  Sürüm oluşturma  +  mantıksız  Bağımsız dağıtım  -  +    modern gelişimde önemli bir rol oynar. Ayrı, bağımsız alt ekipler tarafından yürütüldüğünde zorunluluk haline geliyor. MF'lerin tutarlılığı, verileri doğru şekilde kullanmaları ve doğru formatta aktarmaları vb. nasıl sağlanır? Tip kontrolü  Mikro cepheleri derleme sırasında birleştirerek türleri kontrol etme fırsatından mahrum kalmazsınız. Çalışma zamanı birleşimi durumunda, cephenin üretimde aniden "patlamaması" için entegrasyon testleri yazmanız gerekecektir.    oldukça çelişkilidir: Sürüm oluşturma ve bağımsız dağıtım    diğer takımın MF'sinin herhangi bir sürümünü alabileceğiniz anlamına gelir. Bu, özellikle MF-a'nın diğerlerinden bağımlılıklarını yükseltmek için ek çalışma yapmanız gerektiğinde geçerlidir. Her takım yükseltme için daha iyi bir zaman seçer. Sürüm oluşturma,    ekiplere daha fazla özerklik ve bağımsızlık sağlar. MF'lerin her zaman en son sürümlerini kullanmak önemlidir. Bu geriye dönük uyumluluk gerektirir. Bağımsız dağıtım,  Sürüm oluşturma, çalışma zamanı birleştirmeyle de uygulanabilir, ancak bu pratik değildir. Yalnızca bağımsız dağıtım amacıyla çalışma zamanı ile iletişime geçmek mantıklıdır ve ikincisi sürüm oluşturma ile birlikte var olamaz.  Daha sonra, MF'leri birleştirmeye yönelik her yaklaşımın spesifik uygulamalarının örneklerini göreceğiz.  Mikro ön uçları düzenlemeye yönelik yaklaşımlar   iframe  MF'leri organize etmenin en eski yolu. iframe, ana sitede görüntülenecek kaynağın adresini iletmek için kullanılan özel bir etikettir. Sonuç, site içinde bir sitedir.     , uygulama kolaylığı, mantık ve stillerin tamamen izole edilmesi, bağımsız bir dağıtım yapabilme yeteneği ve çerçevelere bağlanmanın olmaması dikkat çekmeye değer. Avantajlardan  Her bir iframe eklenmesi kaynak yüküne yol açtığından, bu avantajların performans açısından bir maliyeti vardır. Bundan kaçınamazsınız: Bir DOM düğümünde hata ayıklama ve yeniden ekleme girişimleri, önceden yüklenmiş kaynakları kaydetmez; bunları yeniden indirmeniz gerekir. Önbelleğe almayı yapılandırarak performans düşüşünü en aza indirebilirsiniz.  Bunu yapmak için, değişmez kaynaklar için zamana dayalı önbellek geçersiz kılmayı yapılandırmanız gerekir. Neyse ki, toplanan js ve css dosyaları için kutudan çıkan tüm modern cli'ler, isme küçük bir karma ekler. Bu yöntemin   , arama robotlarının sonraki indeksleme için iframe'leri oluşturamamasıdır. dezavantajları  Artıları  Eksileri  Kolay uygulama  Verim  Mantık ve stil izolasyonu  SEO  Bağımsız dağıtım  Çerçeve agnostik   Web Bileşenleri    topluluğu uzun süredir yerel bileşenlerin oluşturulmasını bekliyordu, ancak sonunda çoğu kişinin beklediği kitlesel popülerliği asla kazanamadılar. En popüler üç ön uç çerçeve (React, Vue, Angular) hala bileşenleri kendi yöntemleriyle oluşturmaya devam ediyor. Ön uç  Web bileşenlerinde MF oluşturabilme yeteneğine rağmen bunu pratikte görmedim. Ve bu bir tesadüf değil, çok sayıda engelleyici var:  Ya Lit ya da Stencil kütüphaneleri yeterince popüler değil ve yeterince yaygın değil. Ayrıca piyasada onlarla nasıl çalışılacağını bilen veya öğrenmeye hazır yeterli uzman bulunmuyor.  Açısal öğeler veya vue-custom-element egzotik kalır. Yerel bir ortamda bunları kullanmanın pek bir anlamı yoktur. Uygulamayı zaten sıradan npm paketlerine böldüyseniz, böylece bileşenleri daha sonra istediğiniz gibi bağlayabilirsiniz. Web bileşenlerini diğer çerçevelerle kullanmak mantıksızdır çünkü oluşturulan bileşenlerle birlikte, üzerine yazıldıkları çerçevenin mini sürümünü de bağlamanız gerekir.  Karmaşık işlevsellik parçalarını web bileşenlerine taşımak maliyetli olabilir. Bileşeninizin uygulamanın geri kalanıyla iletişimini yapılandırmanız gerekeceğinden, bir sayfanın tamamını ayrı bir özel bileşene çıkarmak doğru olmayabilir.  Arama robotları bir web bileşeni oluşturamaz ve bu, SEO optimizasyonunu etkileyecektir.  Artıları  Eksileri  Çapraz kesme işlevine uygun  Uygulaması zor  Her çerçeveyle uyumlu  SEO  Mantık ve stil izolasyonu   NPM    geliştirmenin birçok faydası vardır. Geliştiricilerin ihtiyaç duydukları bileşenleri ve dosyaları kütüphaneden içe aktarmaları yeterlidir. Aynı zamanda projede yazım korunur, versiyonlama vardır. Yapı en uygunudur: ağaç sallama işleri (derleme sırasında kullanılmayan kodun kaldırılması) ve geliştiriciler tembel yüklemeyi kolayca ayarlayabilir.  Npm paketleriyle  Ancak bu yöntemin dezavantajları da vardır. Bu durumda, yığının birliğini korumanın yanı sıra MF'lerinizin sürümlerini ve bunların geçişli bağımlılıklarını da korumak zorunda kalacaksınız. Öte yandan, bu bir artı olabilir: paketin yeni bir sürümünü yayınlayarak, diğer ekipler ek işlevsellik eklemeleri gerekiyorsa bağımlılıklarının sürümünü kendileri için uygun bir zamanda yükseltme görevini üstlenebilirler veya tam tersi , bir şeyi kaldırın.  Artıları  Eksileri  Verim  Bağımsız dağıtıma sahip değil  SEO  Tek yığın  Tip kontrolü  Sürüm oluşturma   git alt modülleri (veya Lerna gibi monorepos yapmanın başka bir yolu)  Npm paketlerinde MF'ye alternatif olarak git alt modüllerini göz önünde bulundurun. Aslında bunlar, içinde depoların da bulunabileceği bir depo içindeki depolardır. Alt modüllerde farklı dallar ayarlayabilirsiniz. Örneğin, özellik modülleri içinde hiçbir şey olmayan sahte bir dal içerebilir. Montajın daha hızlı ilerlemesi ve diğer modüllerin yan etki yaratmaması için bu gereklidir. Sahte dallar, yerel geliştirme ve test için çok kullanışlı olabilir.   Avantajları ve dezavantajları açısından bu yaklaşım npm paketlerine çok yakındır. Ayrıca bir şeyi bir paketten değil, komşu bir klasörden içe aktarıyoruz ve kullanıyoruz.   İki yöntem arasındaki farklara bir göz atalım:  NPM paketleri aslında kendi sürümleri ve versiyonları olan sınırlı, orta düzeyde izole edilmiş bir mikro üründür. Her şey yeniden kullanılabilir işlevsellik yaratmaya odaklanmıştır. Ancak uygulama karmaşık/karmaşık ve kokuşmuş olabilir, dolayısıyla büyük bir monolitin paketlenmesi oldukça maliyetli olabilir. Alt modülleri dikkate almanın mantıklı olacağı yer burasıdır çünkü bunlar, klasörü herhangi bir ek hazırlık yapmadan ayrı bir depoya taşıdığımızda depoyu çok kabaca kesmenize olanak tanır.  NPM paketleri yinelemeli olarak iç içe yerleştirilebilir. Alt modüller de vardır, ancak alt modüllerden biri farklı klasörlerde ayrı bir alt modül olarak birkaç kez dahil edilirse montaj düzeyinde işlevselliği çoğaltmaya başlayabilirler. Bu durumda daha düz bir modül yapısı kullanmakta fayda var.  Bir özelliği tüm paketlerde aynı anda hızlı bir şekilde kullanıma sunmanız gerekiyorsa, çapraz paket geliştirme son derece zahmetli olabilir. Alt modüllerde her şey aynı kalsa da diğer alt modülleri etkileyecek düzenlemeler yapabilirsiniz. Bu durumda hata ayıklamak kolaydır. Ancak sonuçta değişiklikleri kendi başınıza birleştirmeyeceksiniz; birleştirme isteği düzeyinde, modülüne dokunduğunuz üçüncü taraf bir ekip, kodu kendi kurallarına uygun hale getirmenizi isteyebilir.  npm  git alt modülleri  Tekrar Kullanılabilirlik  İşlevselliğin kaba kesimi  Keyfi olarak iç içe geçmiş bağımlılıklar  Düz yapı  Platformlar arası geliştirme  Herhangi bir modül sayısıyla geliştirme   tek spa  single-spa aslında diğer çerçeveleri birleştiren bir çerçevedir. Çok sayıda nüansı gizleyen inanılmaz derecede güçlü teknoloji ayrı bir makalenin konusudur.  Şema iframe'e benzer, ancak MF'nin yüklenmesi artık yerel içe aktarma + içe aktarma haritası yoluyla veya çoklu doldurmalara ihtiyaç duyulursa Systemjs aracılığıyla yapılıyor.   MF'leri organize etmenin tüm yöntemlerinden farklı olarak, bu yöntem, farklı çerçeveleri kendi altında birleştirmek için oldukça özel olarak tasarlanmıştır. Ancak teknolojiyi teknoloji uğruna kullanmamak konusunda uyarmakta fayda var. Bir yığınla idare etmek mümkünse onu kullanmanız gerekir. Geliştirme, teknik açıdan karmaşık bir projeyi sürdürmek ve farklı uygulamaların yan etkilerinden kaynaklanan hataları düzeltmekle sonsuza kadar yüklenebilir. Kullanıcı rahatsızlık hissedebilir çünkü. müşteriye indirilecek kod miktarı artırılacaktır (farklı işlevsellik parçaları için farklı çerçevelerin çekirdekleri + tek spa'nın çekirdeği ve eklentileri).  Artıları  Eksileri  Bağımsız dağıtım  Hala tüm durumları kapsamayan büyük belgeler  Çerçeve agnostik  SEO ile ilgili zorluklar  Güçlü CLI  Webpack 5 Modül  Federasyonu  MF'ler oluşturmak için özel olarak geliştirilmiş bir webpack 5 eklentisi. Gelecek vaat eden teknoloji: Çalışma zamanında daha doğru paketleme ve dinamik içe aktarmalar için küçük bir yapı eklentisi.  Şema neredeyse bire bir tek spa'yı tekrarlıyor, ancak artık MF'leri yüklemek için dinamik içe aktarmalar kullanılıyor    Artıları   Eksileri  Bağımsız dağıtım  düşük seviye  Kolay gerçekleştirme  SSR ile uyumlu  Sizin durumunuzda ne kullanılacağını nasıl seçersiniz?  Neyin ne için uygulanabileceğine bir göz atalım:    - uyumsuz kombinasyonlar için tek bir eklenti iframe    - kurumsal bir ui-kit gibi bir çerçeveye bağlı kalmadan uçtan uca küçük bir işlevselliğe ihtiyaç duyduğunuzda web bileşenleri    - projeler arasında yeniden kullanılabilirlik varsa ve/veya derleme sırasında tür kontrolüne ihtiyacınız varsa npm paketleri    - bir projeyi kabaca kesmeniz ve sorumluluk alanlarını dağıtmanız gerektiğinde git alt modülleri    - birden fazla çerçeveyi süresiz olarak, tercihen SSR olmadan birleştirmeye güçlü bir ihtiyaç olduğunda single-spa    - yığının birliğine bağlı olarak MF'lerin kullanımına ilişkin diğer tüm senaryolar. modül federasyonu  Her yaklaşım kendine göre iyidir ve her şeyin kendi yeri olmalıdır. MF'lere geçmeden önce gerçekten ihtiyacınız olup olmadığını düşünmenizi tavsiye ederiz. Hangi yaklaşım seçilirse seçilsin, kaçınılmaz olarak geliştirme, CI/CD veya performans düzeyinde bazı şeyleri karmaşık hale getirecektir. Tek yığın ve yekpare bir uygulama üzerinde kalma fırsatları varsa bu fırsatı memnuniyetle kabul edin.  Ve elbette   . Sonuçta, tüm bağlı çerçeveleri indirirler ve MF'lerin farklı işlevlere yanlış entegrasyonundan kaynaklanan olası hatalara katlanırlar. İşletmeler ise tüm bunların uygulanması ve desteklenmesi için ödeme yapmak zorunda kalacak. kullanıcıları da unutmayın

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Make resilience your competitive advantage

Monoliti Kırmak: Kod Bölme Tekniklerine İlişkin Kapsamlı Bir Kılavuz

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps