Micro Frontend Mimarisi (1. Bölüm)
Şu anki çalıştığım şirketteki projede yaklaşık 5 yıldır geliştiriliyor ve gün geçtikçe de daha da büyüyor. Proje büyüdükçe sayfaların ve bileşenlerin birbiri ile ilişkiler artıyor. Arttıkça da üzerinde çalıştığın bir bileşen başka bir yeri bozabiliyor ve bu da test etmesini zor bir hale getiriyor. Ayrıca kısa sürede release çıkmak için de test edilebilir olmasını kolaylaştırmamız gerekiyor. Ve bunun gibi birkaç sorun daha... Velhasıl, bundan dolayı yeni bir çözüm arayışına girdik.
Projedeyi birkaç ayrı uygulamalara bölerek daha yönetilebilir bir yapı haline getirmesini çalışacağız. Her uygulamadan sorumlu bazı arkadaşlar olacak ve ilerleyen zamanlar da oluşabilecek herhangi bir sorun veya geliştirme konusunda hızlı bir şekilde aksiyon alabilecekler. Böylelikle o proje içerisinde daha donanımlı haline gelmiş olacak.
Bu yazımda Micro Frontend hakkında yaptığım araştırmaları derleyip öğrendiğim şeyleri daha kalıcı hale getirmeyi planlıyorum. Hem de sonraki zamanlarda dönüp baktığımda hatırlamamı da sağlamış olacak. Buyrun başlayalım...
Micro Frontend
Bir web uygulamasını bağımsız olarak geliştirilebilen, dağıtılabilen ve çalıştırılabilen küçük frontend projelerine ayırma yaklaşımı olarak özetlenebilir. Böylelikle uygulamaları daha sağlıklı yönetebiliyor ve geliştirebiliyoruz. Lego gibi düşünebilirsiniz, her parça bağımsız ama birleştiği zaman ortaya bir şey çıkıyor. Bunların dışında bize sağladığı diğer avantajları.
- Eğer takım ile çalışıyorsak kişileri projelere göre dağıtabilir ve sorumluluk tanımlayabiliriz. Böylelikle bir sonraki geliştirmelerde veyahut sorunlarda o ekip daha hızlı ve kontrollü bir müdahale edebilecektir. Diğer türlü daha önce tecrübesi olmayan bileşenlerde ya da sayfalarda çalışma yapan arkadaşlar, beraberinde birkaç sorunu da getiriyor ve işin bitiş süresi uzuyor.
- Eğer proje içerisinde birden fazla teknoloji kullanmak istiyorsak bunu mümkün hale getiriyoruz. Micro Frontend mimarisinde her alt proje özelinde yeni bir proje oluşturmak gerektiği için bu teknolojileri seçme özgürlüğümüz bulunuyor. Ayrıca şöyle bir şey de olabilir; bir projede React 17 kullanıyoruz ama diğer projede React 18 kullanabiliyoruz. Her parça kendi iş mantığını içerir. Böylelikle hepsini ayrı proje olarak düşünebiliriz.
Şimdiye kadar olumlu yanlarından bahsettik. Bununla birlikte gelen olumsuz yanları da mevcut.
- Tekrar eden kodlar. Farklı takımlar farklı projelerde çalışacağız için benzer kodları birden fazla yazmak gerekebilir. Bu gibi durumlarda gereksiz bir kod yığını oluşacaktır.
- Entegrasyon zorlukları. Micro frontend'lerin birbirleriyle iletişim kurması için ek mekanizmalar gerekebilir. (veri alıp gönderme vb.)
- Karmaşıklık artışı. Her micro frontend bir proje olduğundan dolayı gün sonunda çok fazla proje ile uğraşmak gerekebilir.
Micro frontend mimarisi için kullanabileceğiniz bazı araçlar ve frameworkler bulunuyor. Bunları inceleyerek size uygun olan birisiyle başlayabilirsiniz. Ben kısaca değineceğim.
- Webpack Module Federation. Webpack 5 ile tanıtılan bir özellik. Micro frontend’lerin dinamik olarak yüklenmesini ve paylaşılmasını sağlar. Modern framework'ler ile uyumlu, esnek ve performanslı.
- Vite. modern bir build aracıdır ve Module Federation benzeri özelliklerle micro frontend desteği sunmaya başlamıştır. Hızlı geliştirme ve build süreleri, modern Javascript ekosistemiyle uyumlu
- PuzzleJs Framework. Trendyol'un geliştirmiş olduğu bir framework. Teknoloji bağımsızdır, ölçeklenebilir ve güvenilir.
Genel Yorumum
Micro frontend mimarisi aslında projeyi daha da büyütmeyi ve karmaşık hale getirdiğini düşünüyorum. Ama yanında getirdiği avantajları sayesinde yönetmek tek bir projeden daha kolay gibi geliyor. Henüz projemizi geçirmedik. Biraz araştırmalarım ve denemelerimden dolayı bunu söyleyebiliyorum. Neyi, nerede ve nasıl aradığını bilirsen feature ya da sayfa bazında çok daha kaliteli geliştirmeler yapılabilir. Böyle olursa da release süreleri kısalır ve müşteri mutlu olur :)
Ne var ne yok hepsini bölmek yerine üstüne düşünüp doğru ve mantıklı ayırmalar yapılmalı. Birbirleriyle ilişkili olan kısımlar dökülmeli ve ona göre micro app'lere dağıtılmalı. Üstte yazdığım gibi aynı kodlardan birden fazla defa yazma durumu söz konusu olabilir. Fikir olarak söylüyorum ki bu gibi durumlarda reusable olan bazı fonksiyonlar için ve hatta redux için bile ayrı bir app oluşturup oradan yönetilebilir. Böyle olursa belki benzer kodların bir nebze de olsa önüne geçmiş olabiliriz.
Yapılan her değişiklik sonrasında PR incelemeleri dikkatli bir şekilde kontrol edilmeli. Böylelikle oluşabilecek olası mantık hataları önceden giderilmeli. Çünkü mimariyi bir kere kurduktan sonra eğer yamalar yapılırsa projenin amacından çıkılabilir. Bu istenmeyen bir şey. O yüzden PR incelemeleri sert bir şekilde olmalı.
Hazır micro app'ler yaratılırken eğer mümkünse versiyon güncelemeleri ile teknolojileri günceleyebiliriz. Ayrıca bunu yönetmek de kolay olacaktır. Çünkü etki edebileceği yer küçük olacağından dolayı sağlıklı bir şekilde test edebilirsin.
Bir sonraki yazı ile örnek bir proje üzerinden biraz daha derine inmeyi düşünüyorum. Benim için güzel bir challenge olacak.