Photo by Chris Lawton on Unsplash

Frontend Kapsam

Kısaca Rendering Örüntüleri ve Framework Destekleri

Amacım Rendering Örüntülerinden kısaca bahsetmek sonrasında, framework’ lerin kendilerini hangi örüntüye göre konumlandırdığını anlatmak.

Bu konu önemli çünkü Framework leri birbirinden ayrıştıran aslında bu arkaplanda seçtikleri ve kendilerini konumlandırdıkları Rendering Örüntüleridir. Bu konuyu anladığınızda daha doğru tercihler yapabilirsiniz.

Rendering Örüntülerini anlamaya çalışırken DOM elemanlarının nerede oluşturduğuna dikkat edin. (Not: Bu konuyu anlamak için bu linkte bulunan blog yazılarından veya E-Kitap’tan faydalanabilirsiniz.)

Rendering Örüntüleri

• Static Site: İçerisinde HTML, CSS ve JS dosyalarının baştan oluşturulduğu ve sunucuya atıldığı, DOM oluşumun tekrar gerekmediği, etkileşim ve JS işletiminiz az olduğu web sayfalarıdır.
• MPAs (Multi-page Apps): DOM’un sunucuda dinamik olarak oluşturulduğu yöntemdir. Kullanıcı session bilgileri ve istekleri doğrultusunda veritabanından çekilen veri o an içerisinde sunucuda işlenerek DOM nesnelerine dönüştürülür ve ilgili sayfa için geri döndürülür.
• SPA (Single-page Apps): DOM’un tamamiyle tarayıcı üzerinde oluşturulduğu uygulamalardır. İlk başta ufak bir HTML dosyası içerisinde root elemanı olan bir dosya iner, bunun yanında bundle edilmiş JS, CSS dosyaları inerek tüm DOM nesneleri tarayıcıda oluşturulur. Etkileşim, Animasyon yeteneklerinin çok yüksek olduğu uygulamalar oluşturmanızı sağlar.
• SSG (Static Site Generation): Bu yöntem GitHub, CDN ve S3 gibi storage , cache yapılarının ucuz ve yaygın kullanılması ile popülerleşen bir yöntem. Static Site oluşumunun Modern Framework ve Geliştirici araçları ile yaptığımız ve sonrasında build edilirken HTML, CSS ve JS dosyalarına dönüşüp ilgili Storage otomatik atıldığı yöntemdir. Veri build sırasında alınarak web sayfaları statik olarak oluşturulur. JS etkileşimi azdır.
• ISR (Incremental Static Regeneration): Bu yöntem SSG ile sadece build zamanında gerçekleştirilen üretimi daha dinamik hale getirip arka planda veri ile ilgili koşulların değişimin kontrol edilip tekrar ilgili parçanın üretiminin gerçekleşip, cache veya storage atıldığı yöntemdir. Bu yöntem tüm sayfaların tekrar üretilmesi yerine hem ilgili parçanın üretilmesi, hemde bunun dinamik olarak o anda yapılıyor olması büyük avantajlar sağlar.
• SSR (Server Side Rendering): SPA uygulamarıda API çağrımları hep tarayıcıdan yapılarak elde edilen veriler tarayıcıda DOM nesnesine dönüştürülüyor bu Performans ve SEO açısından problem oluşturuyor. MPA uygulamarında ise genelde UI Framework lerinden farklı framework ler kullanılır, buda Component — Compose yapısını bozan bir durum oluşturur. Yani Express, Spring vb.. MPA sağlayan yapılar React Component yapısını devam ettirmez. Burada SSR aslında React , Vue gibi kütüphanelerin sunucu tarafında veriyi oluşturup DOM oluşturması imkanıdır. Bunu React/ Vue Component yapısı içerisinde yapmanıza imkan sunar. (Not: Burada Modern UI Framework’ lerin Backend DOM oluşturma işini ellerinden alma çabasını görüyorum)
• Partial Hydration : Modern Framework ler SPA ile popülerleşti, SSR desteği ile tarayıcıda oluşturulan DOM işlemlerini sunucuda yapma imkanı sağladı , fakat bu durumda sunucudaki DOM ile JS arasındaki bağlantıların eksik olduğu durumlar oluşur yani oluşan sayfayı interaktif yapmak için Örneğin ilgili düğmenin JS içerisinde bulunan onClick event ile bind edilmesi gerekir. İşte sunucudan tarayıcıya gönderilen DOM elemanların üzerinde gezip ilgili JS binding yapılması işlemine Partial Hydration denir. (Not: Her yöntemin bir problemi oluyor yani SPA → SSR geçiş direk çözüm sağlamadı bunun yani SSR + Partial Hydration gibi bir yöntem eklenerek çözümler sunulmaya çalışıldı. Ama burada Partial Hydration bir maliyeti ve getirdiği kompleks yapı bulunuyor)
• Island Architecture: Yukarıda görüleceği üzere SSR ve Partial Hydration işleri olduğundan biraz kompleks hale getirdi. Halbuki bazı web sayfaları varki uygulamadaki bir çok bileşen static iken , bazı bileşen kısımlarında etkileşim ihtiyacı bulunuyor. Peki biz en baştan sunucuda Sayfa Template oluşturulurken , sayfayı ilgili adacıklara ayırsak ve bunların Rendering farklı farklı tanımlayabilsek. İşte Island Architecture tam da bunu yapmanızı sağlıyor, baştan bu adacıkları tanımlayıp, bunların hangileri statik , hangileri dinamik, hangileri ssr + partial hydration olabileceğini tanımlamanıza olanak sağlıyor.
• Resumable: Bu konuyu Hydration üzerinden anlatacağım. SSR ile sunucuda DOM oluşturduk fakat JS ile bind etmek için Hydration çalıştırmamız gerekiyor. Bu da HTML ve JS tarayıcı tarafında indirilmesi daha sonrasında Parse edilerek işletimesi ve JS listener’ların ilgili DOM elemanlarına bağlanması ile gerçekleşir.

Resumable vs. Hydration

Fakat bu işlem maliyetlidir. Island Architecture sayfayı baştan parçalara ayırarak bu problemi küçülterek daha yönetilmesi kolay DX (Developer Experience) sunmaya çalışır.

Resumable ise DOM sunucuda oluşturulurken Örneğin Düğme oluşturulurken hangi chunk içerisinde hangi fonksiyon olduğu belirlenir.

<button on:click="./chunk.js#handler_symbol">click me</button>

Ve kullanıcı bu düğmeye bastığında Loader ilgili chunk lazy olarak download ederek işletir. Bu durumda ilgili DOM elemanı devreye girmeden JS yüklenmesini ve tüm DOM ağacını Client gezilmesini engeller.

• Streaming SSR: Server Side Rendering , Modern framework lerin istekler sonucunda DOM elemanlarını HTML dönüştürme işleminin bitmesini beklemeden oluşan chunk parçalarını ufak ufak tarayıcıya gönderme örüntüsüdür. İlgili sayfanın parçalar halinde tarayıcıda birleştirilmesi performans açısından bir çok avantajlar sağlar. Veya daha canlı sistemler geliştirmemize olanak sağlayacak altyapıyı sunar. (Not: Nasıl Static Sayfa üretimini ISR ile daha ufak update edilebilir hale getirdiysek, burada SSR daha ufak parçalar ile update edebilir hale getiriyoruz, tabi buradaki parçalama Island Architecture gibi bileşenleri statik/dinamik diye ayırmak değil. Sayfa bileşen parçalarının stream edilmesi.
• RSC (React Server Components) : Bu yöntem React’a has bir rendering örüntüsüdür. SSR ile sunucu tarafında gerçekleştirilen Rendering ‘den kaynaklanan sorunları aşmak için (Partial Hydration, Resumable, Island Architecture ve Streaming) yöntemleri geliştirildi fakat tüm bunlar React Component — Compose yapısında Boundary çözebilmiş bir durum sağlamıyordu. İstedikleri bir Web Uygulaması yazdıklarında bileşenler tarayıcı env dışında sunucuda da çalışabilir hale gelsin isteniyor, bu durumda Fetching, Data Processing işlemleri o bileşenlerin içerisinde yapılabilecek yani React’ın bileşen çıktısı JSX → Virtual DOM gelen çıktının sunucu tarafında Serialized olarak oluşturulması ve Streaming ile tarayıcıya aktarılıp Virtual DOM içerisine entegre edilmesini içeren karmaşı bir süreci içerir. (Not: Tabi DX (Developer Experience) açısından bu karmaşıklıklar geliştiriciye yansıtılmaz ise büyük avantajları olabilir, teoride böyle altyapıda ki her karmaşıklık eninde sonunda geliştiriciye bir zorluk çıkarır)

Framework’ lerin Konumları

• Static Page: Framework Gereksinimi bulunmaz
• MPAs (Multi-page Apps): Express/EJS, Flask, Spring Boot, .NET, JSP
• SPA (Single Page App): React, Vue, Angular
• SSG (Static Site Generation): Nextjs, Gatsby, Hugo, Jekyll
• ISR (Incremental Static Regeneration): Next, Nuxt
• SSR (Server Side Rendering): Next, Nuxt
• Partial Hydration : React, Vue
• Island Architecture: Astro
• Resumable: Qwik
• Streaming SSR: Next, Nuxt
• RSC (React Server Components) : Next, (Remix in progress)

Bir önceki yazımda bahsettiğim gibi Framework’ ler gelecekte daha önemli hale gelecekler, çünkü bu karmaşıklıktaki yapıları biz geliştiricilerin implement etmesi oldukça zor, büyük şirketlerin hazırladığı bu soyutlamalar üzerinden parametreleri değiştirerek arkaplanın nasıl çalıştığını anlayarak çalışma detaylarını Framework’ lere bırakacağız. Bundan dolayı bu döneme Framework’ler dönemi diyebiliriz.

Referanslar

• Rendering Patterns for Web Apps — Server-Side, Client-Side, and SSG Explained
• The Top Ten Rendering Patterns In Modern Web Development