2 puan yazan GN⁺ 2025-05-10 | 3 yorum | WhatsApp'ta paylaş
  • Astro ve React Server Components (RSC), sunucu ve istemci kodu ayrımını benzer şekilde hayata geçirir
  • Astro’da Astro Component ve Client Island kendi işlevsel rollerini paylaşır
  • RSC, aynı kavramı Server Component ve Client Component olarak ayırır ve sınırı 'use client' yönergesiyle belirler
  • RSC, Astro’ya kıyasla etkileşimli UI oluşturma ve kod paylaşımı açısından daha esnektir
  • Her iki model de verinin sunucudan istemciye tek yönlü aktığı bir yapıya sahiptir

Giriş ve temel kavramlar

  • Astro, Astro Component ve Client Island olmak üzere iki ana bileşen türü sunar
  • Astro Component, .astro uzantısına sahiptir ve yalnızca sunucuda ya da build aşamasında çalışır; dosya sistemine erişim, DB sorgulama, dahili servis çağrıları gibi istemcide yapılamayan işleri gerçekleştirebilir
  • Client Island, React, Vue vb. için kullanılan bileşenlerdir; tarayıcıda çalışır ve kullanıcı etkileşimini üstlenen kısımdır
  • Astro Component içinde Client Island render edilebilir, ancak Client Island içinden Astro Component çağırmak mümkün değildir
  • Bu yapı, verinin her zaman yalnızca sunucudan istemciye aktığı tek yönlülüğü garanti eder

Kod örneği ve rol ayrımı

  • Örnek kodda PostPreview.astro, sunucuda dosya okur ve başlığı aldıktan sonra ilgili veriyi Client Island’a iletir
  • LikeButton, React ile yazılmıştır; tarayıcı yüklendikten sonra durum değişimi ve kullanıcı tıklama olaylarını üstlenir
  • Astro Component ile Client Island farklı dünyalarda çalışır ve veri aktarımı da yalnızca Astro Component’ten aşağıya doğru gerçekleşir

React Server Components (RSC) ile karşılaştırma

  • RSC’de de Astro’ya benzer şekilde sunucu bileşenleri (Server Component) ve istemci bileşenleri (Client Component) ayrımı vardır
  • React Server Component’te sunucu bileşenleri JavaScript fonksiyonları olarak tanımlanır ve 'use client' yönergesiyle istemci kodunun nerede başladığı açıkça belirtilir
  • RSC’de aynı bileşen dosyası hem sunucu hem istemci rolünü üstlenebilir; Astro’daki gibi dosya uzantısı ya da ayrı bir ayrım olmadan, gerektiğinde yalnızca 'use client' bildirimiyle sınır değiştirilebilir
  • Bir bileşen istemciye özel özellikleri (useState gibi) ya da sunucuya özel özellikleri (DB erişimi gibi) kullanıyorsa, yanlış ortamda kullanıldığında build hatası oluşur ve net geri bildirim alınır
Reklam

Astro ve RSC’nin görsel/yapısal farkları

  • Astro, .astro dosyaları ile JS/TS dosyalarının ayrılması sayesinde net sınırlara sahiptir
  • RSC’de temelde her şey React olduğu için kod paylaşımı ve esneklik çok daha yüksektir
  • Örneğin durum ya da sunucu özellikleri kullanmayan nötr bileşenler (Markdown parser gibi) her iki tarafta da kullanılabilir
  • RSC’de bir bileşenin hangi dünyada çalışacağı, import yoluna göre otomatik olarak belirlenir

RSC modelinin avantajları ve sınırları

  • RSC’nin avantajı, kod yeniden kullanımı ve rol değiştirmedeki esnekliktir
    • Herhangi bir bileşen, ihtiyaç halinde yalnızca 'use client' bildirimiyle sınırlar arasında kolayca taşınabilir
    • Astro’da UI’nin statik/dinamik niteliği değiştiğinde kod dönüştürmek zahmetli olabilir; RSC bunu daha basit şekilde çözer
  • RSC’nin dezavantajı, öğrenme eğrisinin daha yüksek olmasıdır
    • Geliştirici sürekli olarak şu anda “hangi dünyada” olduğunu düşünmek zorunda kalır; ancak hata yapıldığında build hatalarıyla hızlı geri bildirim alır
  • Astro’da UI’nin dinamik kısımları arttıkça yapı karmaşıklaşırken, RSC’de React ağacının tamamı birleşik olduğu için state ve Context aktarımı daha doğal gerçekleşir

HTML merkezli Astro ve React ağacı merkezli RSC

  • Astro’nun çıktısı HTML’dir; her sayfa geçişinde tüm sayfa yenilenir ve tam bir SPA deneyimi sunmaz
  • RSC’nin çıktısı React ağacıdır (ilk aşamada HTML, gezinme sırasında ise JSON vb. olarak aktarılır)
    • Bu sayede SPA ile MPA’nın avantajları birleştirilebilir
    Reklam
  • Sunucudan doğrudan yalnızca UI’nin bir bölümünü güncelleyip yansıtabilen kısmi yenileme mümkündür; bu da dinamik veri almayı ve istemci durumunu korumayı kolaylaştırır

Gelişmiş React özellikleri desteği

  • Sunucu-istemci karışık ağaç yapısı sayesinde, React’in ileri özellikleri (ör. <Suspense>, view transition’lar vb.) doğal biçimde entegre şekilde desteklenir
  • İstemci tarafında declarative olarak ele alınan loading state, font/görsel/JavaScript/style gecikmeleri gibi unsurlar da yönetilebilir
  • React’in tüm özellikleri, sunucu-istemci sınırı boyunca uçtan uca çalışır

RSC ve Astro’nun konumu

  • Astro tam teşekküllü bir framework iken, RSC daha çok framework’ler için bir yapı taşı ya da standart niteliğindedir
  • Resmî RSC implementasyonları arasında Next.js App Router ve Parcel RSC bulunur

Sonuç ve öneri

  • RSC’nin geliştirici deneyimi (DX) hâlâ biraz pürüzlü olsa da öğrenmeye değerdir
  • Astro’yu henüz denemediyseniz önerilir; ayrıca Astro, RSC’yi zor bulan geliştiriciler için daha yumuşak bir başlangıç sunabilir
  • Yalnızca istemci tarafı React kullanmış geliştiriciler için bile Astro, beklenmedik problem çözme deneyimleri sağlayabilir

3 yorum

 
hakoiko 2025-05-13

Şu anda eski bir React uygulamasını Astro’ya refactor ediyorum.
Metinde "entegre bağlam" vurgulanıyor. "Entegre bağlam" hızlı servis geliştirmeye yardımcı olur, ancak bir gün teknik borca dönüşebileceğini bilmek gerekir.
Servisin uzun vadeli bakım perspektifinden bakıldığında, "entegre sıkı bağlılık" yerine "bağımsız modüllerin gevşek bağlılığı" daha iyidir.
Ve Astro da bunun için en esnek framework’tür.

 
GN⁺ 2025-05-10
Hacker News görüşleri
  • Benim Astro yerine RSC kullanmamın tek nedeni, adalar (island'lar) arasında context paylaşabilmek olurdu; onun dışında belirgin bir avantajı yok. Bir de küçük bir nokta olarak, keşke bu yazıda Astro'nun "code fence" kavramından açıkça bahsedilip açıklansaydı; bu fikir, React'in use client yaklaşımına kıyasla sunucu ile istemci arasındaki sınırı çok daha net ayırıyor.
    • Bence code fence gerçekten bir sınırı temsil etmiyor; fence'in altındaki kod da yine sunucuda çalışmak zorunda, yoksa oradan Astro bileşenlerine referans veremezdiniz. Benim anladığım kadarıyla fence, sadece "binding vs template" ayrımını ifade ediyor; "sunucu vs istemci" ayrımını değil.
    • Adalar arasında context paylaşmak Astro'da gerçekten çok kolay; şu bağlantıya bakabilirsiniz: https://docs.astro.build/en/recipes/sharing-state-islands/
  • Astro, içerik odaklı web siteleri için bir web framework'ü: https://github.com/withastro/astro
    • Eskiden Gatsby kullananlar, GraphQL üzerinden birbirine bağlanmış o kırılgan görsel işleme hattından kurtuldukları günü hayatları boyunca hatırlayacak. (O sırada bilgisayarlarının başındaydılar.) Kanıtım yok ama Astro'nun net promoter score'unda beş tane 9 olduğu bilimsel bir gerçek.
    • Astro müthiş; birkaç yıldır SSG için varsayılan tercihim ve artık uygulama geliştirmek için de Astro'yu ciddi ciddi değerlendiriyorum. Astro'yu uygulama için kullanma deneyimi olan var mı? Ben Astro ile sadece island tabanlı HTML render edip backend'i non-JS kullanmayı düşünüyorum.
    • "İçerik odaklı web siteleri için bir web framework'ü" ha? O zaman içerikle değil de rastgele sayı üreteçleriyle çalışan siteler de mi var?
  • Astro'yu gerçekten ama gerçekten seviyorum; ilk çıktığından beri kullanıyorum. Kişisel sitemi ve ilk ürünümün landing page'ini Astro ile yaptım. Build süresi hızlı, JS olmadan da dağıtım yapabiliyorsunuz ve istediğiniz herhangi bir frontend kütüphanesini kullanabiliyorsunuz; bu yüzden bence en iyi framework bu.