Modern Front-End Yaklaşımı Part-2

Frontend geldiği noktadan hızla bir gelişim gösterdi ve yeni yaklaşımlar ile geliştirme süreçlerini ve yöntemlerini farklı bir boyuta taşıdı.

Part-1 — Serinin ilk yazısını okumak için tıklayın.

Konuyu bir adım ötesine taşıyıp daha ileri seviye yaklaşımlara değineceğiz. Bir önceki yazıda temel prensipler, pratikler üzerinde yoğunlaşmıştık. Bu yazıda yine kendi tecrübelerim, çalıştığım projelerde uyguladığım çözüm yöntemleriyle paralel olarak yine kendi kullandığım teknolojiler etrafından anlatacağım.

🤔 Modern Frontend Yaklaşımı Neden Önemli?

Devamlı bahsettiğimiz gibi web uygulamaları birer frontend uygulamasına evriliyor veya evrilmek üzere. Bu nedenle geliştirilecek uygulamalara mimarisel bir bakış açısı ile yaklaşılması gerekmektedir.

Aslında uygulanan yöntemler frontend dünyası için kısmen modern fakat web geliştirme mimarileri açısından yıllardır sürdürülen prensipleri barındırmaktadır. O nedenle uzun yıllar server-side diller ile geliştirme yapan kişiler için Frontend dünyasındaki yeniliklerin bir kısmı heyecan yaratmaz ancak odağı frontend olan geliştiriciler için adeta aydınlanma içermektedir. 😊


Stillendirme

Stillendirme temel anlamda frontend uygulamalarında birçok yöntem ile çözülüyor. Hangisi daha efektif tartışılır.

Görsel Kaynağı: https://goo.gl/gKiiKQ

Ben bu görseli özellikle çok anlamlı buluyorum. Şu an CSS’in geldiği son noktada çözüm CSS in JavaScript yöntemlerine kaymış durumda. Henüz tam evrim tamamlanmış sayılmaz çünkü mevcut çözümler işleri bir taraftan kolaylaştırdığı gibi bir taraftan da zorlaştırıyor. Ancak faydaları zararlarına göre daha ağır bastığı için şimdilik bir sorun görünmüyor.

CSS in JavaScript Çözümleri:

Şu an getirdikleri yenilik ve çözüm bakımdan kayda değer iki adet başarılı araç mevcut. Elbette tek çözüm bunlar değil ama geldiğimiz noktada karşılaşılan problemleri en iyi çözen araçlar;

styled-components vs glamorous
Neden React? sorusuna bir önceki yazıda yanıt vermiştik. Bana göre component modelinin geldiği son nokta React. Diğer yönlerine değinmiyorum fakat component üretme ve kullanma şekli bakımından oldukça esnek. Benim için React component modeli tam olarak best practice.

Benim CSS in JavaScript tercihim Styled-Components. Built-in tema desteği ile ve kolay söz dizimi ile ideal bir çözüm. Tema desteğini çok basit bir şekilde sağlayabiliyor olmak modern bir web uygulaması için ileriye dönük harika bir özellik bence. Styled-Components için daha detaylı bilgi isterseniz şu yazımı okuyabilirsiniz.


Server-Side Rendering vs Client-Side Rendering

SSR vs CSR

Server-Side Rendering ihtiyacının ortaya çıktığı iki temel gereksinim söz konusu;

  • Daha fazla performans (açılış hızı vb.)
  • Tutarlı bir SEO performansı

Konuyu açmadan önce Client-Side rendering yapıldığında React uygulamasının başından geçen süreçleri inceleyelim;

Client-Side Rendering:

Client-Side rendering’de önce sunucu tarafından bir istek başlatılır, browser bu isteği aldıktan sonra bundle’ın olduğu JavaScript dosyasını indirir, indirme işlemi tamamlandığında bu dosyayı çalıştırmaya başlar. İşte bu noktadan sonra web sayfası görüntülenir ve kullanıcı ile etkileşime geçilir.

Bu süreçte sıkıcı loading gif’leri göstermemiz gerekiyor. Performans açısından incelediğimizde bir bekleme söz konusu. Eğer bir eticaret sitesi geliştiriyorsanız ve ziyaretçileri potansiyel müşterilere dönüştürmek istiyorsanız sayfa girişinde bekletmek istemezsiniz.

Peki hem kullanıcıyı daha az bekletip, hem de seo performansımızı nasıl artırabiliriz?

Server-Side Rendering:

React’ın server’da render edilerek browser’a gönderilme işlemini biz server-side rendering olarak adlandırıyoruz. Elbette temel tanımı bu değil, bir php ile geliştirilen uygulamada server’da render edilerek browser’a gönderilir.

Server-Side rendering işin içerisine dahil olduğunda düşünülmesi gereken başka konularda ortaya çıkıyor. Bunlara değinmeyeceğim o nedenle daha güzel bir çözümden bahsedeceğim.


Framework for server-rendered React apps

Next ile hızlıca server-side rendering desteği olan bir uygulama ayağa kaldırabilirsiniz. Create-React-App ile birlikte yaygınlaşmaya başlayan zero configuration mentalitesi next geliştirilirken de uygulanmış. Ek konfigürasyonlarla boğuşmadan çok hızlı bir şekilde kod yazmaya geçebiliyorsunuz.

Daha öncede söylediğim gibi CSS in JS kavramı yaygınlaşmaya başladı ve bir süre daha böyle gidecek gibi görünüyor. Next’de CSS in JS’i benimseyen bir framework ve bunun için kendi geliştirdiği styled-jsx’i kullanıyor.

Next otomatik olarak server rendering ve code splitting desteği sunuyor. Normal şartlarda code splitting için ekstra efor sarf etmeniz gerekiyor. Varsayılan olarak bu özelliklerin kullanılabiliyor olması zero configuration’ın hakkını verdiğini gösteriyor sanırım. Ek olarak deployment konuları da oldukça basit. Server-side rendering ihtiyacı olan bir React uygulaması geliştirecekseniz ilk bakmanız gereken Next.js olmalı. 😉

API

Frontend uygulamaları bir şekilde data ile beslenirler. Genellikle datayı bir REST API üzerinden alırız ve anlamlandırırız. Bir süredir geliştirme yöntemlerinin ve uygulanan mimarilerin özellikle bu kısmı oldukça tartışılmaya başlandı.

API kısmı yerine göre frontend developer’ı ilgilendirir yerine göre datayı üretmekle yükümlü backend developer’ı ilgilendirir. Ancak geldiğimiz noktada yeni bir API standardı var. Farklı bir yaklaşım ile bazı alışkanlıkları değiştirerek yeni deneyimler geliştirilmesine yardımcı olan bir standarttan bahsediyoruz.

Modern frontend uygulamalarında declerative data fetching, tek bir endpoint üzerinden data alış-verişi gibi konular haliyle önemli olmaya başladı.

A query language for your API

GraphQL’in ortaya çıkış noktasından geldiği noktaya bakıldığında REST için daha verimli bir alternatif olduğu rahatlıkla söylenebilir. Öncelikle belirtmek gerekir ki GraphQL sadece React geliştiricileri için kullanılabilir bir çözüm değil. Facebook ilk olarak 2012'de native mobile uygulamalarda kullanmaya başladı bu yaklaşımı. Ancak ilk olarak 2015'de ki React Conf’da public olarak lanse edildi ve böylece hayatımıza girmiş oldu.

Netflix’in geliştirdiği Falcor da GraphQL ile benzerlik gösteriyor. Hatta birçok şirket bu konuda çalışma yapıyordu. Yine benzer şekilde Coursera da bu tarz bir proje geliştiriyordu. GraphQL ortaya çıktıktan sonra bu projeyi sonlandırıp altyapılarını GraphQL’e taşıdılar ve bence doğru bir adım attılar.

Github, Twitter, Courseara vb. birçok şirket GraphQL’e geçiş yaptılar ve bunun nedeni elbette REST’ten daha iyi olmasıydı. 🙂

Bu yaklaşımı güzelleştiren ise herhangi bir dil veya framework ile birlikte kullanılabiliyor olması.

Özellikle mobil trafiğin arttığı bir dünyada verimli data kullanımı önemli bir konu haline gelmeye başladı. Bu tür problemleri çözmek için geleneksel yöntemlerde mobil için ayrı bir servis yazılırdı. Mobil uygulama, websitesi farklı bir servisi kullanır, masaüstü websitesi farklı bir servis kullanırdı.

Özellikle bir sayfada bulunan birden fazla feature için yine birden fazla servise istek atılır ve bir request kuyruğu oluşurdu. Bunları sayfa sayfa talep ettiğinizde servislerden dönen data birleştirilerek gönderilir fakat içerisindeki her field’a ihtiyacınız olmayabilir.

GraphQL ile aynı anda birden fazla servise istek atabilir sadece talep edilen field’lar alınır ve tek bir request ile bir sayfa için gerekli tüm data elde edilebilir üstelik bunu yapmak gerçekten basit.

GraphQL Temel Çalışma Prensibi — Görsel Kaynağı: howtographql.com

Burada görüleceği üzere GraphQL’in bir server bir de client ayağı var. Server tarafı datayı toplayacağı bir database’e bağlanabilir veya kendisine verilen REST API’ları wrap ederek kendisine data sağlar. Her iki durumda da datayı aldığı nokta ile client arasında bir köprü görevi görmektedir.

GraphQL client-server iletişiminde daha fazla esneklik ve verimlilik ihtiyaçları ile baş edebilmek için ortaya çıkmış bir yaklaşım. Özellikle client tarafında hızla değişen istekler REST’in statik yapısında karşılanması zamanla geliştirme maliyeti olmaya başlamaktadır.

Ek olarak frontend ve backend ekiplerinin birbirinden bağımsız çalışması için de güzel bir ortam sağlamaktadır. GraphQL ile API versiyonlama gibi ihtiyaçlarda tamamen ortadan kalkıyor. Schema Definition Language (SDL), Realtime Update için Subscription’lar gibi özellikler ise gerçekten güçlü olduğu yanlarını ortaya çıkarıyor.

GraphQL Client

GraphQL server tarafında datanın bağlandığı farklı use case’ler uygulanabilir demiştik. Bunlar;

1- GraphQL Server doğrudan database ile konuşarak (java, php, nodejs vb. bir dil ile) data toplar ve sunar (klasik api üretme senaryosu).

2- Mevcut kaynakları kullanarak data toplar ve sunar (mevcut api üzerinden iletişim kurar).

Datanın toplanma kısmı 1. senaryo ile gerçekleştirilecek ise burası daha çok backend geliştiricileri ilgilendiren bir kısım olduğu için frontend geliştiriciler client tarafına odaklanır.

Ancak client da hiçbir zaman datanın nereden geldiğini umursamaz client her zaman tek bir endpoint’e query’sini atar ve istediği datayı alır. Bu aradaki haberleşme schema vasıtası ile yerine getirilir. İşin bu şekilde client ve server olarak ayrılması frontend tarafında farklı abstraction’lar oluşturulmasına imkan sağlıyor.

Imperative ve declarative data fetching konusuna bu noktada biraz değinmek gerekiyor sanırım. GraphQL declarative data fetching yaklaşımını benimsemektedir.

Imperative Fetching:

  • Bir http isteği oluşturulur.
  • Yanıt alındıktan sonra dönen response ayrıştırılır.
  • Alınan data store’a yazılır (opsiyonel).
  • Data UI’da gösterilir.

Declarative Fetching:

  • Gerekli olan veri tanımlanır.
  • Data UI’da gösterilir.

Flexible, Production ready GraphQL Client for React and native apps.

GraphQL’in bizi daha çok ilgilendiren tarafının client olduğundan bahsetmiştik. Bu ayrımın olmasının client tarafında farklı abstraction’lar kurulmasına imkan tanıdığınıda eklemiştik. Apollo şu an için bana göre GraphQL ile birlikte kullanılabilecek en iyi client. Oldukça esnek, basit ve gerçekten harika özellikleri var.

dev.apollodata.com

Bilenler için meteor’u geliştiren ekip Apollo’yu geliştiriyor ve aynı zamanda ciddi anlamda GraphQL’e contribution yapıyorlar. GraphQL’in gelişmesinde ve yaygınlaşmasında bence önemli bir yere sahipler.

Apollo dışında client olarak bir de Facebook tarafından geliştirilen Relay var. Daha light-weight client’larda çıkmaya başladı ancak Apollo ve Relay kadar kapsamlı değiller.

Ben tercihimi Apollo’dan yana kullanıyorum. Relay’i incelemek isteyenler için yazının sonunda gerekli kaynakları paylaştım oradan faydalanabilirsiniz.

Apollo bize bir Client olarak neler sunuyor?

  • Fetching
  • Caching
  • Prefetching
  • Subscription
  • Pagination
  • Optimistic UI
  • Normalization
  • Query Splitting

Bu özelliklerin hepsini tek tek açmayacağım ancak bir iki püf noktayı detaylandırmak isterim. 😊

Benim en beğendiğim özelliklerinden bir tanesi fetch policy. Basitçe açıklamak gerekirse bir fetch isteği yapıldığında bazı seçenekler arasından seçim yaparak bir policy tanımlayabiliyorsunuz. Bu işlem için sadece fetch policy seçeneklerinden bir tanesini kullanmak yeterli oluyor.

💉 Fetch Policy Seçenekleri:

  • cache-first: Her zaman bir fetch isteği yapıldığında veriyi cache’den okur.
  • cache-and-network: Eğer data cache’de varsa önce cache’den getir yoksa bir network isteği yapar ve datayı getirdikten sonra cache’ler. Burada cache ve network isteğini yarıştırabiliyoruz. Yani cache’den daha hızlı gelirse cache datası, network’ten daha hızlı gelirse network datası kullanılabiliyor (evet harika bir şey 😍)
  • network-only: Hiçbir zaman cache’den getirme, her zaman network isteği yap. (Devamlı değişken bir datanız varsa örneğin: son yapılan işlemler listesi gibi burada kullanmanız uygun.)
  • cache-only: Her zaman cache’den getirir.

Bunların dışında bir fetch isteği yapıldığında loading, error, fetching gibi durumları geri dönerek bu bilgilere göre reaksiyon gösterebilmemizi sağlıyor.

Son olarak harika bir chrome dev tools eklentisine sahip. Dahili olarak GraphiQL içerisinde geliyor ve buradan istediğiniz gibi sorgularınızı atıp deneme yapabiliyorsunuz.

Apollo Dev Tools

Bu arada yine Apollo’nun sunduğu Optics adında harika bir GraphQL performance monitoring aracı var. 1 milyon request’e kadar ücretsiz kullanabiliyoruz. Daha fazla request için ücretli paketlere geçiş yapmanız gerekiyor.


Buraya kadar özetlemek gerekirse, stillendirmenin evriminden bahsettik, API’ların değişimini ve GraphQL’in getirdiği yaklaşımı gördük. Üstüne Apollo ile GraphQL’den maksimum verimi nasıl alabildiğimize değindik.


Şimdi type konusundan devam edelim;

Type konusu gündeme geldiğinde genellikle ilk ön plana çıkan şey TypeScript oluyor. TypeScript bencede oldukça güzel ancak ben ES yazmayı sevenlerdenim. Bu nedenle type safety konusunu flow ile çözmek benim için daha uygun oluyor.


Pluggable JavaScript linter

ESLint JavaScript’i belli kurallar bütününe uygun olarak yazmak için kullanılan ve hataları development aşamasında dahil olmak üzere gösteren oldukça faydalı bir linter aracı. Ekip halinde geliştirilen projelerde özellikle yazılan kodların tek bir tipte yazılması sizin kodunuzu başka biri maintain etmek istediğinde önemli bir hale gelebiliyor.

Bu nedenle bir projeye başlamadan önce ESLint ilk ayarlanması gereken araç. ESLint’i isterseniz CI sürecinizede dahil edebilirsiniz. ESLint için farklı config’ler kullanabiliyoruz. Örneğin AirBnB stilini veya Google stilini kabul ederek geliştirme yapabilirsiniz. Bu farklı config’ler kod yazımı için best practice’leri kapsamakta. Ben config olarak bir süredir AirBnB kullanıyorum.

Prettier:

Prettier bir kod formatlama aracı. Şu an için JavaScript(es2017 dahil), Jsx, Flow, TypeScript, Css, Less, Sass, Json ve GraphQL destekliyor. Daha basit anlatmak gerekirse yazdığınız kodu standartlara uygun hale getiriyor. İsterseniz editörünüze eklentisini de kurabilirsiniz. Her save’de kodumu formatla diyebilirsiniz mesela. Veya lint-staged ile her git commit öncesi kodu prettify edebilirsiniz. Prettier özetle yazdığınız saçma kodları daha mantıklı bir formata dönüştüren çok faydalı bir yardımcı. 🙏


PWA Extension

Lighthouse Chrome için Google tarafından geliştirilmiş bir extension. Progressive web uygulamaları için bir analiz aracı olarak düşünebiliriz. PageSpeed gibi bir puanlama yapıyor ve başarılı, eksik, düzeltmeniz gereken konular için size ipuçları sunuyor. Bu ipuçları sayesinde web uygulamanızı daha performanslı hale nasıl getirebileceğinizi öğrenebiliyorsunuz. Kullanmanızı şiddetle tavsiye ederim.


Kapanış

Frontend geldiğimiz noktada bir evrim geçiriyor ve baş döndürücü hızda ilerleme kaydediyor. Çıkan yenilikler, yöntemler hızla hayatımıza giriyor ve hızla hayatımızdan çıkabiliyor. Amacım önceki yazıda ele aldığımız temel konuların bir adım daha ötesine gitmekti.

Anlatılmamış birçok püf nokta bulunuyor ve bunları araştırmak, öğrenmek ve en çokta geliştirirken keşfetmek gerekiyor. Modern Frontend kavramı biz geliştiricilerin hayatında çok sayıda değişikliğe neden oldu ve olacak.

Umarım faydalı ve tamamlayıcı bir etkisi olur. 😊

Her türlü soru, eleştiri ve öneri için oguzz.kilic@gmail.com adresinden bana ulaşabilirsiniz.

Sevgiyle kalın, iyi uçuşlar. 🚀

Kaynaklar:

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.