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

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 mimari çö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.

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:

1. Büyük bir projeniz var . 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 .

   
   

2. Büyük bir ekibiniz 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.

   
   

3. Harika bir işlevselliğiniz 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.

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 organizasyonel bir karar 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.

Mikro Ön Uçlar ve Tembel Yükleme Karşılaştırması

Tersine, MF'lerle karşılaştırıldığında Tembel yüklemeden 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ü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.

Tip kontrolü 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?

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.

Sürüm oluşturma ve bağımsız dağıtım oldukça çelişkilidir:

• Sürüm oluşturma, 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.

  
  

• Bağımsız dağıtım, 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.

  
  

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.

Avantajlardan , 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.

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 dezavantajları , arama robotlarının sonraki indeksleme için iframe'leri oluşturamamasıdır.

Web Bileşenleri

Ön uç 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.

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.

NPM

Npm paketleriyle 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.

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.

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.

  
  

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).

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

Sizin durumunuzda ne kullanılacağını nasıl seçersiniz?

Neyin ne için uygulanabileceğine bir göz atalım:

• iframe - uyumsuz kombinasyonlar için tek bir eklenti

• web bileşenleri - kurumsal bir ui-kit gibi bir çerçeveye bağlı kalmadan uçtan uca küçük bir işlevselliğe ihtiyaç duyduğunuzda

• npm paketleri - projeler arasında yeniden kullanılabilirlik varsa ve/veya derleme sırasında tür kontrolüne ihtiyacınız varsa

• git alt modülleri - bir projeyi kabaca kesmeniz ve sorumluluk alanlarını dağıtmanız gerektiğinde

• single-spa - birden fazla çerçeveyi süresiz olarak, tercihen SSR olmadan birleştirmeye güçlü bir ihtiyaç olduğunda

• modül federasyonu - yığının birliğine bağlı olarak MF'lerin kullanımına ilişkin diğer tüm senaryolar.

  
  

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 kullanıcıları da unutmayın . 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.