React
RSC (React Server Component) Nedir ? Frontend Geliştiricilerini Nasıl Etkileyecek ?
React Server Component’s ın ismi şu dönemde oldukça popüler. Data Fetching alanında ReactQuery, Remix Loader rakip mi, bu kütüphanelerin sonu mu olacak ?
Bundan önceki yazılarda Hydration bahseden bir yazı serisine başlamıştık.
https://onurdayibasi.com/rendering-techniques/ (Hydration)
Bu yazıların sonuncusunda RSC (React Server Component) bir Hydration çözümü olarak karşıma çıksada aslında bundan çok daha büyük bir değişim ve paradigma değişikliği
Öncelikle bu yazıda değineceğim konu RSC teknik detaylarından çok ekosisteme etkisi
Öncelikle React Server Components ne olduğununa kısaca bakalım.
React ekibi tarafından tasarlanan yeni bir uygulama mimarisidir.
React Server Components (or RSC) is a new application architecture designed by the React team. (RSC)
Yani
- Hydration performans optimizasyonu
- bileşenlerin server — client olarak ayrışmasını
- bu bileşenlerin birbiri ile uyumlu çalışması için Stream, Suspense ve RenderTree (VDOM) ve serialization kısmı değişiklikleri
- 3rd party kütüphane bağımlılıklarını azaltmak
- data-fetching altyapısı sunmak
- bundling ve routing yapısında ekstralar
- fullstack geliştirim için sadece React ekosistemi içerisinde kalmak
- Req / Resp mantığının değişmesi
- Framework’ lere bağımlılık
- vb… bir çok konuyu beraberinde getiriyor ?
Düşüncelerim
Sabahtan RSC konuda bir çok video izledim. Ve izlemeye devam ediyorum.
Videolar
- React Server Components with Dan Abramov, Joe Savona, and Kent C. Dodds
- React Roundtable: Server Components, Suspense, and Actions
- Discussion on React server components with Ryan Carniato, Tanner Linsley, & Ben Holmes
- You Might Not Need React Query
- I Was Wrong About React Server Components…
React Server Components Hangi Uygulama Türü İçin Uygun?
Biz uzunca bir zamandan sonra JSP, PHP .. Server Side Rendering → SPA (Client Side Rendering) yöneldik sonradan Mobil’in de gelmesi ile birlikte birçok web uygulamasını API üzerinden Request/Response ile veriyi Client’a çekerek Client Render ettik (jQuery, Backbone, Ember, Knockout, React, Vue, Angular vb…). Yani SPA, CSR için bence RSC yaklaşımı çok uygun değil. Not: Proje çok büyüktür , 3rd Party kütüphaneler çok yer kaplıyordur, çok optimize bir çalışmasını istediğimiz sunucu istekli bir yapı varsa belki
SSG için yani Statik Veri oluşturan örneklerde zaten tüm HTML, CSS, JS sunucuda generate edilip edge üzerine veya HTTP Server üzerine atılıyor yine bu işler için çok mantıklı değil bence..
SSR (Server Side Rendering) — Hybrid uygulamalar yani SEO ihtiyacı olan Sosyal Medya, Market, Pazaryeri, E-Ticaret vb uygulamalar için uygun mu ? Evet Bu tarz uygulamalarda kısımda bir karşılığı var.. Bu alanda farklı farklı yaklaşımlar implement eden Framework ler var..
- SvelteKit
- SolidStart
- Nuxt
- Remix
- Next
Özetle odaklandığımız nokta SSR veya SSR - CSR ortak çalışmasını istediğimiz uygulamalar için geçerli..
React FullStack İçin Bir Meta Framework’e mi Dönüşüyor ?
React’ın ilk popüler olması bir View kütüphanesi olması yani bileşenlerin birbirini compose ederek UI basitçe oluşturması ve bu aşamada JSX sayesinde DX(Developer Experience) üst seviyelerde tutabilmesiydi.
Class Component ’lar ile hayatlarımız güzelken UI geliştirmekten zevk alırken
- Component Life Cycle öğrenmesi zor
- Functional Yapıda değil f(View)
- HoC (High Order Components) ve Render Props karmaşası
- 3rd Party Kütüphanelerin Entegrasyonu zor derken
Karşımıza React Hook çıktı. React Hook asıl etkisi useState, useEffect üzerinden kütüphane geliştiricilerinin Custom Hook yazabilmenize olanak sağlayarak Client Side inanılmaz bir 3rd Party kütüphane oluşturulmasını sağladı.
- Routing
- Animation
- State Management
Bunlar ile ilgili bir çok hazır kütüphaneden herkesin faydalanmasını sağladı.
Şimdide React Server Component’s ile fullstack alanındaki teknolojilere göz dikiyor. Yani bir Server yaşayan ve Serverless Action tetikleyebilen data bileşenleri oluşturmak istiyor.
Bu yapı ile İstemci / Sunucu ayrımı yerine PHP, JSP de olduğu gibi React API JSX üzerinden FullStack uygulama geliştirmeye olanak sağlayacak altyapıyı oluşturmaya çalışıyor.
Tabi bunu tek başına yapması mümkün değil. Öncelikle React 18 üzerinde bir takım geliştirmeler yaptılar,
- Suspense
- Streaming
- React Server Component
- Partial and Selective Hydration
- Transition
Tabi bu işlem basit olmadı, Çünkü React ın bu çalışmalarının başarılı olabilmesi için bu yapıların
- Bundling
- Routing
- Data Fetching
konularında da desteklenmesi gerekiyordu. Burada React ekibinin bir kısmının Next.JS (Vercel) geçtiğini bu kısımda birlikte çalıştıklarını görebilirsiniz
Burada bir diğer deneyim gerektiren konuda Data Fetching, Caching ve bu konularda deneyimli bir ekibin oluşturulmasıydı React Server Component asıl işi veri çekmek üzerine olduğu için Facebook içerisinde Relay / GraphQL kısmında çalışan ekibi de birleşerek bu yeni React’ı oluşturdular.
- React 1 — (View Rendering Kütüphanesi)
- React 2 — (View and Data Fetching Kütüphanesi) ve
State Management / Data Fetching ‘de Nerden Nereye Geldik ? RSC ’ nin Etkisi Ne Olur ?
State Management konusuda bir çok blog yazısı yazmışımdır. (Merak edenler bu linkten blog yazılarına erişebilir)
Sırası ile State Management kütüphanelerinde aşağıdaki şekilde bir gelişim oldu.
- Flux (Redux)
- useState, useEffect, useContext
- Apollo Client (GraphQL)
- React Query , SWR, RTK
- Remix Loader
- React Server Components
Burada 1 yıl öncesine kadar Remix ilk çıkısında Remix routing Loader RSC göre avantajlarından ve performans karşılaştırmalarından bahsetti. Remix aslında bu blog yazısında kendi Route’ lar üzerinden geliştirdiği Loading yönteminin RSC’e göre daha hızlı olduğunu anlatmaya çalıştı. (Ryan Florence)
Ama gelinen noktada Remix
- Progressive Enhancement (Web 1.0 üzerine kurulan Zero JS)
- ve Route Loading sırasındaki paralelliğin getirdiği
hype ve popülerliğini kaybetmiş durumda. Next.JS hem Remix benzer bir Router çıkardı, hem de başından beri React ekibi ile olan uyumu ve React’ın gücünü kullanabilmesi Next.JS React’ın bir tamamlayıcısı haline getirdi .
Buradaki bence en önemli nokta React’ın sadece View Rendering değil aynı zamanda Data Fetching için de bir öneri ile gelmesine neden oldu.
React Server Component Mimariyi değiştirdiği için daha önceden bir çok kütüphanenin ve geliştirici aracının yer aldığı Routing, Bundling, State Management ciddi bir şekilde etkileniyor.
React’ın Framework ve Şirket Bağımlılıklarının Etkileri
Son gelişmeler ile birlikte React olabildiğince Next’e bağımlı hale gelmiştir. Yani Vercel firmasına. Diğer kısımlarda Remix (Shopify), Gatsby (Netlify) , denilse bile React 18 sonrası bence React + Next bir bütün olarak düşünmek gerek.
Enterprise (Kurumsal) dünya React’ı CSR (Client Side Rendering) için kullanmasının nedeni
- (View Rendering) React’ın çok basit sadece View Rendering odaklanmış bir kütüphane olması
- (Bağımsız Olması) Open Source olup, Community Bağımsız olması
- (3rd Party Kütüphane) Animation, Routing, Layout, Bundling, State Management, Animation, UI Component Lib olarak bir çok 3rd Party kaliteli kütüphanenin olması
Geldiğimiz nokta’ da React1 dediğimiz özellikler birçok şirket için tamam iken React2 dediğimiz Framework’ lere bağımlılık birçok kurumsal şirket tarafından tercih edilecek bir konu değildir.
- Kodun çok fazla karmaşık hale gelmesi (Son Kullanıcı Değil ama Altyapı ve Mimari Olarak)
- Framework olarak Vercel, Shopify ve Netlify bağımlı olmak
- 3rd Party ücretsiz kütüphane bağımsızlığını kaybetmesi
- Legacy kodların tekrar rewrite edilme zorunluğu veya test edilme gereksinimleri
Şahsi düşüncem Facebook ve Vercel şirketi bu alanlara ciddi yatırımı ve emeği bulunuyor. Sektör’e uzun zamandır yön veriyorlar ve bu konuda oldukça deneyimliler.
Son dönemde yaptıkları RSC (React Server Component) ise çok ciddi bir paradigma değişikliği bekleyip durumun nasıl gelişeceğini izleyeceğiz.
LearnReactUI.dev
React Ekosisteminde kendi kariyerinizi daha ileriye götürmek için LearnReactUI.dev sitesine üye olmayı unutmayın. Bu site piyasada çalışan(real-world) Web Uygulaması geliştirmek isteyen React geliştiricileri için oluşturulmuş bir web sitesidir.