React bir full-stack framework’tür (ya da buna dönüşüyor)
(robinwieruch.de)- Server Components ve Server Actions eklenen React, bir full-stack framework’e evriliyor
2010’da framework savaşlarının başlaması
- 2010’da Backbone, Knockout ve Ember ile başlayan framework savaşlarını Angular ve React hızla takip etti; ortaya çıkacak sonucu ise kimse öngöremedi
- Uzun süre istemci tarafı render edilen (CSR) JavaScript uygulamaları baskındı
- Bu uygulamalar tek sayfa uygulamaları (SPA) olarak da bilinir ve genellikle küçük bir HTML dosyası ile büyük bir JavaScript dosyasından oluşurdu
- Kod bölme yaygınlaşmadan önce durum böyleydi
Frontend ve backend’in ayrılması
- Bu dönemde frontend geliştirme, çeşitli JavaScript framework’leri ve kütüphaneleri tarafından domine edildi
- Backend ise genellikle belirli bir dile bağlı değildi ve REST, API iletişiminin standardı haline geldi
- Ben de serbest çalışan bir web geliştiricisi olarak çoğunlukla .NET, Java, Python ve PHP backend’leriyle çalıştım
- TypeScript/JavaScript’i backend tarafında yalnızca greenfield projelerde ya da backend’i kontrol edebildiğim küçük projelerde gördüm
- Ancak full-stack React’in yükselişi bunu değiştirebilir
- 2010 ile 2020 arasındaki dönemin geliştiriciler tarafından nasıl algılandığının, kariyerlerine ne zaman başladıklarına göre değişmesi ilginç
- 2010’dan önce başlayan geliştiriciler server-side rendering (SSR) ortamına aşinaydı ve sunucu tarafı teknolojilere son dönemdeki dönüşe daha rahat görünüyorlar
- Buna karşılık birçok kişi yaklaşık 10 yıl boyunca yalnızca REST API’lerle çalışan istemci tarafı render edilen (CSR) uygulamalarda çalıştı
- Şimdi ise bu yeni full-stack React dünyasını nasıl karşılamaları gerektiğini bilemiyorlar
TypeScript’in sektör standardı olarak yükselişi
- Son birkaç yılda TypeScript sektör standardı olarak öne çıktı
- TypeScript, frontend geliştiricilere tipli ve güçlü bir programlama dili sundu
- Geliştiriciler TypeScript’i benimsedikçe geri dönüşü olmayan bir noktaya gelindi
- Koddaki küçük değişimlerin hem bireyler hem de tüm sektör üzerinde büyük etkiler yaratabilmesi ilginç
TypeScript ve REST’in zorlukları
- TypeScript’in REST üzerindeki etkisi, çok sayıda geçici çözümü beraberinde getirdi
- OpenAPI (eski adıyla Swagger) REST API dokümantasyonu için vardı, ancak artık çoğunlukla tipli API arayüzleri üretmek için kullanılıyor
- İstemci-sunucu mimarisinde kusursuz tip arayüzleri oluşturmak mümkün olsa da, birçok proje bunu baştan doğru şekilde kurmayı başaramıyor
-
Kişisel not: "OpenAPI tabanlı mimaride iyi deneyim yaşayan geliştiriciler mutlaka vardır, ama ne yazık ki yazar onlardan biri değil"
TypeScript havayı değiştiriyor
- TypeScript’in burada atmosferi nasıl değiştirdiğini görmek oldukça ilginç
- Bir yandan REST kullanan tiplenmemiş SPA’ler (dokümantasyon amaçlı OpenAPI ile) “yeterince iyi” görünüyordu
- Ancak TypeScript standart haline gelip norm olarak görülmeye başlayınca, üretilmiş tip arayüzleri frontend kod tabanında daha yüksek standartlara alışıldığı için rahatsız edici hale geldi
- Üretilmiş tip arayüzlerinin dezavantajları açık:
- her zaman bir üretim adımı içeriyorlar
- üretilen çıktı karmaşık oluyor
- başlangıç ayarlarına bağlı olarak üretilen kod her zaman doğru olmuyor
RPC ve tRPC’nin yükselişi
- RPC yeni bir kavram değil, ancak tRPC sayesinde React ekosisteminde popülerlik kazandı
- 80 bin satırlık bir uygulamada 6 ay boyunca tek başına geliştirici olarak edindiğim deneyime göre, backend’de fonksiyon çağırarak veri okumak ve yazmak adeta aydınlatıcıydı
- TypeScript kullanan bir stack’in her iki tarafında da bundan daha üretken hissettiğim olmamıştı
- Kişisel olarak, birkaç yıl önce yalnızca (üretilmiş) tipli GraphQL mimarisinde buna benzer bir üretkenlik hissetmiştim
- 2023 boyunca tRPC’den daha iyisini hayal edemiyordum
- Backend’de fonksiyon çağırarak veri okuyup yazmak devrimsel hissettiriyordu
- Ama ihtiyacım olan tek şey bu muydu? Hayır
Server Components ve Server Actions devrimi
- Benim için asıl kırılma noktası 2024’te Server Components ve Server Actions ile geldi
- Bunlar yalnızca sunucuyu çağırmakla kalmıyor, diğer tarafta kod yazıp çalıştırabilmeyi de mümkün kılarak sunucuyla aradaki boşluğu kapatıyor
- Server Components, React bileşenlerini sunucuda çalıştırmayı mümkün kılıyor; böylece JSX ile UI döndürmeden önce veri kaynaklarına (ör. veritabanına) doğrudan erişilebiliyor
- Server Actions ise perde arkasında HTTP API endpoint’leri oluşturarak, uzaktan yordam çağrısına benzer şekilde fonksiyonların çalıştırılıp çağrılmasını sağlıyor
- Server Components ve Server Actions, React’i bir full-stack framework’e dönüştürüyor
- Frontend’i full-stack bir ortama dönüştürmek için heyecan verici bir dönem
React’in Server Components ve Server Actions desteği
- React’in kendisi Server Components ve Server Actions için yalnızca yapı taşlarını ve spesifikasyonu sağlıyor
- React üzerine kurulu meta-framework’ler, istemci ile sunucu arasındaki yönergeleri yorumlayan bundler’lar olarak bu boşluğu kapatabiliyor
- Next.js, Server Components ve Server Actions uygulamasına öncülük ediyor
- Next.js daha önce server-side rendering (SSR) desteği sunuyordu, ancak artık Server Components ve Server Actions sayesinde geliştiriciler veritabanları ve mesaj kuyrukları gibi sunucu tarafı kaynaklara erişebiliyor
Full-stack geliştirmenin başlangıcı
- React ile full-stack geliştirme henüz başlangıç aşamasında
- Geliştiriciler Server Components ve Server Actions aracılığıyla veritabanına doğrudan erişmeye başladıkça, basit CRUD uygulamalarının ötesine geçen karmaşıklığı ehlileştirme süreci yaşanacak
- Kapsamlı eğitimle frontend geliştiriciler, katmanlar, tasarım kalıpları ve en iyi uygulamaları kullanarak backend mimarisini uygulamayı yakında ustalaşacak
- Dürüst olmak gerekirse, kimse React bileşenlerinin içinde ORM fonksiyon çağrıları görmek istemez
Paradigma değişimine dair beklenti
- Bu paradigma değişimi konusunda çok heyecanlıyım
- React geliştiricilerinin UI’dan veritabanına kadar dikey işlevler geliştirdiği yeni bir döneme hazırlanıyoruz
8 yorum
Zaten her şeyi full-stack olarak yapıyordu
Uygulama geliştirme gibi başka dillerle uyumluluğu da düşünürsek, tRPC pek de iyi bir seçim gibi görünmüyor. 😅
Bence en iyi seçenek GraphQL.
Next.js Server Action, geliştiricinin kontrol edemediği rastgele API endpoint'lerini public olarak açığa çıkarma sorununa sahip; bence bu oldukça kırılgan bir nokta.
Bahsettiğiniz şeyin hangi güvenlik açığı olduğunu öğrenebilir miyim? Aratınca SSRF güvenlik açığı diye bir şey çıkıyor ama doğru olup olmadığından emin olamadım. Tam da Next.js çalışıyordum, merak ettiğim için sormak istedim.
En başta SPA'yı öne çıkaranların amacı neydi acaba?
jqueryile DOM manipülasyonu yapılan dönemden çok daha iyi ama backend ve frontend tasarımı ile geliştirmesi için gereken kavramlar ortadan kalkmıyor, sanki sadece yer değiştiriyor. Sadece routing'e baksak bile, sunucudan istemciye taşındı, sonra da server-side rendering akımı yüzünden tekrar sunucuya taşınmaya çalışılıyor.3 yıl sonra bile kodlama akademileri ya da kurslarda SPA tarzı React'in öğretilip öğretilmeyeceği şüpheli.
En büyük avantajı sayfalar arası geçişlerin akıcılığı değil miydi (o zamanlar)
Yazının sonu, yazarın yakında açmayı planladığı full-stack web geliştirme eğitim programı The Road to Next tanıtımıyla bitiyor ^^;