Hepsiburada Micro Frontends Dönüşümü

Oğuzhan Aslan
Jan 8, 2020 · 12 min read

Nedir Bu Micro Frontends?

Bu yazıda, son zamanlarda oldukça gündeme gelen Micro Frontends mimarisinin ne olduğunu, neden ortaya çıktığını ne gibi problemleri çözüp, ne tür problemler yaratabileceğini ve Hepsiburada’da başladığımız dönüşüm deneyimlerini kendi yorumumla anlatmaya çalışacağım.

Micro Frontends Nedir?

Micro Frontends ile bir karmaşıklık daha ekleniyor gibi görünse de, bu mimari büyük projelerin ve büyük ekiplerin yaşadığı problemleri çözmeyi öneren ve görece karmaşıklığı azaltmaya çalışan bir mimari.

Görsel: 1

Kimler Kullanıyor ?

Micro Frontends; Spotify, Dazn, OpenTable, Ikea, Skyscanner ve Zalando gibi bazı büyük şirketler tarafından farklı teknikler ile birlikte kullanılıyor. Bu teknikleri yazının devamında daha detaylı öğreneceğiz.

Sorunlarımız ?

Hepsiburada Arge organizasyonunda, yaklaşık 17 tane Yazılım ekibi bulunuyor. Bu ekiplerin içerisinde Frontend, Backend, Full Stack, DevOps, QA, Business Analyst gibi alanlarda uzmanlaşmış insanlar bulunuyor. Bunların 12 tanesi direkt sitenin ön yüzü ile etkileşim halinde.

Görsel: 2- Micro Frontends geçişi öncesi de, Hepsiburada’da her ekip kendi sorumluluğundaki sayfalarda Frontend geliştirmesi yapıyordu.
  • Arayüze bir update geldikçe, bu shared componentler için, zaman içerisinde implementasyon farklılıkları oluşabiliyor. Snapshot ve Canlı UI testleri her ne kadar var olsa da, gerçek dünyada bunu takip etmek imkansıza yakın.
  • Legacy monolitik uygulamalara gömülü Frontend App’lerini, modern frameworkler(React, Angular, Vue) ile sıfırdan yazmak büyük bir maliyet. (Microfrontends sayesinde, vakit kaybetmeden parça parça yeniden yazabiliyoruz)

Neden ve Nasıl? 🎉

Micro Frontends, birçok ekibin aynı anda büyük ve karmaşık bir ürün üzerinde çalışabilmesi için, frontend monolitlerini daha küçük, daha yönetilebilir parçalara ayırıyor.

Görsel: 3
  • Birbirinden bağımsız uygulamalar/ekipler sayesinde verimli bir geliştirme ortamı ve hızı
  • Daha ölçeklenebilir bir organizasyon yapısı
  • A/B Testing ve Build süreçlerinin hızlanması

Bağımlılık Yönetimi ☠️

Hepimizin çok duyduğu bir deyim vardır ‘yok öyle üç kuruşa beş köfte’ diye. Bu deyimi burada kullanmadan edemeyeceğim. Bu mimaride kaçınılmaz olarak yaşanacak olan aynı bağımlılıkları tekrar tarayıcıya yükletmek ve yüklenen bağımlılıkların birbirleri arasındaki uyumu takip etmek çok büyük bir maliyet.

Güzel soru.
  • Pre-Build aşamasında Dependecies kontrolü yaparak, ortak olan tüm kütüphaneleri oluşturacağınız vendor(node_modules klasöründeki tüm bağımlılıklar) dosyasından çıkartmak ve ortak dosyalarınızı ayrı bir servis üzerinden sunmak.
  • Cache ile yatıp cache ile kalkılmalı. Bakınız: https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker
  • En büyük dezavantajlardan bir tanesi, X kütüphanesinin farklı versiyonlarını kullanıyorsanız, gereksiz JS dosyası yüklemiş olacaksınız. Aynı kütüphanenin farklı versiyonlarını kullanmayı ekiplere yasaklamayı düşünmek yerine bu iş otomatize edilmeli. Upgrade ve Downgrade süreçlerinde ortak kararlar alınmalı. Yoksa çok can sıkıcı bir duruma dönüşebilir.

Nasıl Çözdük?

Biz bu sorunu, ortak kullandığımız kütüphaneler için bir uygulama geliştirerek çözmeye çalıştık. Bu uygulamanın tek görevi ortak kullanılan kütüphaneleri bir araya getirip bir bundle oluşturmak.

Görsel: 5
Görsel: 6

Otonom Takımlar ve Bağımsız Deploymentlar

Mikroservisler de olduğu gibi, bu mimaride birbirinden bağımsız Frontend uygulamalarının kullanılabilmesi çok önemli.

Görsel: 7
Görsel: 8

Fragment Nedir ?

Micro Frontends mimarisinde, geliştirip dışarıya açtığımız her uygulama Fragment olarak adlandırılıyor.

Görsel: 9

Nasıl Çalışmalı?

Bizim senaryomuzda Fragment’lar, HTML çıktısı ve asset dosyalarının path’lerini sunan bir HTTP servisi. Genel kullanım bu yönde.

  • Zorunlu bir kural veya direktif değil fakat Fragment kendi içerisinde başka bir Fragment kullanmamalı. (bence)
  • Dışarıdan parametre alabilmeli ve birden fazla yerde başka amaçlarla kullanılabilmeli.
  • UI componentleri birer fragment değildir.
  • SSR yaptığımızı varsayarsak, in-memory veya Redis gibi araç ile kolay bir şekilde cache’lenebilir olmalı. Defalarca renderToString çalıştırmaktan kaçınmalıyız.

Nasıl Bir Araya Geliyorlar?

Daha sonra bu Fragment’ları Layout Service ismini verdiğimiz bir uygulamada kullanıyoruz. Temel anlamda Layout Service katmanını, bu Fragment çıktılarının birleştiği sayfa olarak düşünebilirsiniz. Fragment çağrıldığında html, js, css çıktısını dönerken, Layout uygulaması kullandığı fragment'lara bağlanıp bunları birleştiriyor.

Görsel: 10

Layout Services

1- Iframe

iFrame, her ne kadar çok eski bir teknoloji olsa da, eğer Arama Motoru dostu sayfalar yaratma ihtiyacınız yoksa ve uygulamalarınızı Server’da render etmiyorsanız, benim düşünceme göre başınızı çok fazla ağırtmadan kullanılabilecek en kolay yollardan birtanesi.

  • Iframe uygulamaları iletişim için, postMessage kullanılıyor. iframeEl.contentWindow ise sıklıkla başvurabileceğiniz bir method.

2-Server Side Application

Arama motorlarından yüksek trafik alan bir uygulamanız söz konusuysa, Frontend uygulamanızın SSR yaptığını veya Pre-Rendering tekniklerini muhakkak kullanıyorsunuz demektir. Zira arama motorlarının botları, JavaScript ile oluşturulmuş içerikleri hala tam sağlıklı bir şekilde okuyamıyor.

  • Server tarafında ortak bir Router kullanımı işlerinizi oldukça kolaylaştırıyor.
  • Fragment’lar arası iletişim için, uygulamalarda sıklıkla kullanılan EventBus mekanizmasından faydalanabilirsiniz.

3-OpenComponents

OpenComponents, bir yöntemden daha çok açık kaynak olarak geliştirilmiş hazır bir araçtır. MicroFrontends için hemen hemen çoğu şey için çözüm sağlamakta. OpenComponents’i bir JavaScript framework’ü olarak değil, Frontend fragment’larını hızlı bir şekilde geliştirmek ve yayınlamak için geliştirilmiş bir tool veya pattern olarak tanımlıyor.

Hepsiburada’da Neler Yaptık?

Voltran ismini verdiğimiz bir proje ile start verdiğimiz dönüşüm sürecinde, Voltran componentlarımızı(fragment) paylaşmamızı sağlayan, React ve Node.JS kullanılarak hazırlanmış bir framework.

Görsel: 11
Görsel: 12

Layout Engine tarafında neler yaptık?

Hepsiburada’da başladığımız Micro Frontends dönüşümünde, aslında ekranlarımızın küçük bir kısmını geçirmeyi tercih ettik. Geçiş sürecini en zararsız şekilde atlatabilmek hem de daha yönetilebilir bir yapı oluşturmak için adım adım ilerlemeye özen gösterdik.

Mevcut Projelere Uyum

En önemlisi geliştirdiğimiz fragment’ları ilk aşamada, şu an ki deployment sürecimizi ve yükümüzü arttırmadan mevcut uygulamalarımızın içinde çalıştırmamız gerekiyordu.

Görsel: 13

Componentler Arası İletişim

Componentler arası iletişimi ise Event Bus patternini kullanan bir JavaScript kütüphanesi ile sağlıyoruz. Bunun gibi farklı farklı ekiplerin kullanması gereken fonksiyonları veya değişkenleri, özel bir fragment’tan sunmayı tercih ettik.

Görsel: 14 — ProductList uygulaması addToCart isimli bir event ile sepet totalinin 15 olacağını bildiriyor.
Gösel: 15 — Sepet uygulaması ise bu event’e gelen istekleri dinliyor ve kendini state yapısını güncelleyerek görünen değeri güncelliyor.

Artılar — Dezavantajlar ve İpuçları

  • Prefix: Geliştirme esnasında browser tarafından paylaşılan kaynaklarda prefix kullanmazsanız, büyük bir karmaşıklığın içine düşmeniz kaçınılmaz olacaktır. Global Eventler, Local Storage&Cookie gibi kaynakları kullanırken hangi ekibin o kaynağı oraya yüklediğini veya kullandığını bulabilmek için isimlendirme yaparken, Prefix kullanmak hayat kurtarıyor.
  • Bundles&Chunking: Aynı kaynakları tekrar tekrar kullanıcıya yüklemekten kaçınmanız gerekiyor. Bunun için Fragment’larınızın fragment based çıktı vermesi önemli. Biraz daha küçük bir çıktıya sahip olmak için, daha sonra bu kaynakları Layout Engine tarafında birleştirebilirsiniz. Fakat bu herhangi bir ekibin deployment çıktığında, tekrardan başka bir uygulamanın da deployment çıkması anlamına geliyor.
  • Aynı kütüphanenin farklı versiyonları mecburen yükletmek kaynaklarımızın boyutunu yükseltecek. İlk yükleme ve Performans kayıpları yaşanabilir. Bunu kısıtlamak sizin elinizde.
  • Delegasyon Kısıtı: X ekibinde çalışan geliştiriciyi, Y ekibine taşımak biraz zorlaşabilir. Zaman içerisinde ekiplerin geliştirdiği micro frontends projeleri, codebase olarak büyük farklılıklar gösterebilir. Ekipler arasındaki değişim yeni bir onboarding süreci anlamına gelebilir. Bunu yönetebilmek önemli.

Geri Bildirim 📭

Yazı ile ilgili tavsiye, öneri, eleştiri ve düzeltmeleri dikkate alıyorum. Geri bildirim ve iletişim için:

Kaynaklar:

Teşekkürler ❤

Bu süreçte yazıyı düzenlerken bana destek olan Ahmet Turan, Fatih Burak İlk, Volkan Tağal ve Yasin Uysal’a teşekkür ederim.

hepsiburadatech

hepsiburada technology

hepsiburadatech

hepsiburada technology

Oğuzhan Aslan

Written by

Software Developer, Music Producer

hepsiburadatech

hepsiburada technology