Photo by Ricardo Gomez Angel on Unsplash

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 ?

Onur Dayıbaşı

Published in

Frontend Development With JS

5 min readJul 2, 2023

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 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.