Daha İyi Bir Front-End Seri-Ⅰ

Bu yazımda büyük ölçekli bir front-end applicationu için nasıl bir mimari kurmalıyız, tasarım kalıplarından nasıl faydalanabiliriz, componentler nasıl olmalı ve hata yönetimini nasıl yaparız gibi başlıklara değineceğim.

Biliyorsunuz ki bundan 5-10 yıl önce tüm business logic backendde tutulur front-end ise sadece datayı renderlamaktan sorumlu olurdu. SPA’nin hayatımıza girmesiyle beraber bussiness logic in sorumluluğu front-ende kaymaya başladı.

SPA kullanmamızdaki en önemli nedenlerden biri de component base yapısıdır peki bir component nasıl olmalı?

Component

Bir componentin ilk kuralı küçük, kısa olmaları gerektiğidir. İkinci kural ise daha da kısa olmaları gerektiğidir.

Her yazılımcının mutlaka bilmesi gereken SOLID prensiplerini component tasarlarken de göz önünde bulundurmalıyız.

• Bir component olabildiğince tek bir iş için çalışması
• Componentin davranışını değiştirmiyor ve yeni özellikler kazanabiliyor olmalıdır.
• Componentlerde yaptığımız değişiklik diğer componentleri etkilememesi gerekmektedir.
• Componentler arasındaki bağımlılık olabildiğince az olmalıdır.

Componentlerimizi ne kadar prensiplere göre oluştursak da component sayısısı ve bu componentleri kullanan ürün/takım sayısı arttıkça bunları yönetmek bir hayli zor oluyor. Bu karmaşayı ortadan kaldırmak için de Design System den faydalanıyoruz.

Design System

Bu büyüme, şirketlerin tasarım tarafında UI çalışmalarını daha düzenli yürütmeleri ve düzene koymaları ihtiyacını doğuruyor.

Neden design system?

• Sayfalar içinde kullanılan componentlerin tutarlı olmasını sağlar
• Var olan componentlerden bir sayfa hazırlandığı için daha hızlı UI geliştirmesine olanak sağlar
• Tasarımcı ile developer arasında ortak bir dil olur
• Tekrarlayan componentlerin önüne geçilmesini sağlar

We’re not designing pages, we’re designing systems of components.
- Stephen Hay

Componentlerimizi oluşturduk ve bu parçaları birleştirip bir sayfa yaratmak istiyoruz bunun için de bir mimari düzene ihtiyacımız var bu noktada Brand Frost un Atomic Design methodolojisinden faydalanacağız.

Atomic Design
Atomic design metodolojisi tam olarak tekrar kullanılabilir parçalar üretmek için tasarlanmış bir mimari modeldir. Bu mimari model ismini maddenin en küçük yapı taşı olan atomlardan alır. Componentleri de en küçük parçalarına kadar ayırmayı hedefler.

Bir web sayfasının 5 ana yapıdan oluşması gerektiğinden bahseder. Atomlar, moleküller, organizmalar, templateler ve pageslardan oluşmalıdır. Atomic designın detayına da girmeden neden kullanmalıyız ne faydaları var ondan bahsetmek istiyorum. Tabii ki her metodolojinin çözdüğü sorunlar olsa da aynı zamanda getirdiği bazı sorunlar da olabiliyor.

Neden atomic design?

• Componentlerin tekrar kullanılabilirliğini artırır
• Component ve code tekrarının önüne geçer
• Daha hızlı development

UI olarak projemizin nasıl bir mimaride olması gerektiğinden bahsettik tabii ki bu componentler bir bussiness logic ile birleştiğinde bir ürün ortaya çıkmış oluyor ve bu business logicleri de yönetmek için belirli stratejilere ihiyacımız var.

Pure JavaScript Classları

Componentleri olabildiğince sade ve business logicden uzat tutmamız gerektiğinden bahsetmiştik. Tabii ki bir component kendi içinde bu business logice sahip olabilir ama bir component birden fazla iş akışına sahip olduğunda ya da aynı iş akışı birden fazla component için de geçerli olduğunda componenti ve kodu yönetmek zor bir durum alıyor. Bu durumda JS classlarından faydalanmamız gerekiyor.

Neden ihtiyacımız var?

• Object Oriented yaklaşımları JS Classlarında kolaylıkla uygulayabiliriz.
• Yıllardır belirli sorunlara çözüm olarak geliştirilen tasarım kalıplarından faydalanabiliriz.
• Vue, React, Angular gibi kütüphane ya da çatılara bağımsız bir iş akışına sahip olduğumuzdan teknolojiler arası geçişimizi kolaylaştırır.
• Component business logicden bağımsız çalışacağı için aynı componenti farklı business logicler için de rahatlıkla kullanabilmemize olanak sağlayacaktır.

Componentlerimizi oluşturduk, mimarimizi kurduk ve artık çalışan bir ürünümüz var. Tabii ki her kod gibi bizim kodumuzun da hatalı parçaları olması kaçınılamaz bir durum. Hatanın her zaman olabileceğini kabul edip bunlara en erken çözümleri getirebilmek için çözümler üretmeli ve bu hataların handle ediyor olmamız gerekir.

Serinin ikinci kısmında aşağıdaki başlıklara değineceğim:

• Unit/Integration/Automation Test
• Hata yönetimini nasıl yapılmalı
• Monitoring tooları
• GitHub actionlarından nasıl faydalanılır
• Bazı gerekli kütüphaneler