Next.js'de SSR vs SSG – CTO'lar ve geliştiriciler için pratik bir genel bakış - Source Software
bekleyin
×
Next.js'de SSR vs SSG – CTO'lar ve geliştiriciler için pratik bir genel bakış

İlk olarak, JavaScript'i aldık. Sonra Tek Sayfa Başvurularımız oldu. Sonra, biz var ... baş ağrısı. Bunun nedeni, güzel ve son derece etkileşimli web uygulamalarımızın yavaşlaması ve hem arama robotlarını hem de insanları etkileyen bir dizi kullanılabilirlik sorunundan geçmesidir. Geliştiriciler çılgınca çözümler aradılar. Sunucu Tarafı İşleme ve Statik Site Oluşturma çözüm mü? Öğrenmek için, en popüler SSR / SSG çerçevelerinden biri olan Next.js'a bir göz atalım.

Yazılım geliştirme dünyasında o kadar çok süslü moda kelime var ki, gerçekten isteseydim, tüm makaleyi yazılım teknolojisi ve iş dünyası arasındaki kavşakta bulunan güzel terimlerin uzun bir listesinden başka bir şeyle dolduramazdım.

Ancak SSR ve SSG gerçekten öne çıkıyor. Yazılım yapımında yer alan herkes için gerçek ve pratik öneme sahiptirler - geliştiricilerden tasarımcılara, UX uzmanlarına, test uzmanlarına, web analistlerine, SEO uzmanlarına, metin yazarlarına ve daha fazlasına.

SSR ve SSG'yi ustaca kullanmanın faydaları, tüm bu alanlarda büyük bir fark yaratmaktadır. Bunu henüz bilmiyorsanız, eminim ki işleri toparladığımda bunu göreceksiniz.

Bugün, SSR ve SSG hakkında pratik bilgiler edineceksiniz. Ayrıca onları kullanmayı gerçekten kolaylaştıran bir çerçeve sunacağım – Next.js.

Bu makale nedir:

  • Temel SSR ve SSG kavramlarına ve her iki yaklaşımın faydalarına genel bakış,
  • Next.js ve iş için faydalarına giriş,
  • Next.js kullanarak SSR ve SSG'nin nasıl uygulanacağına dair pratik ve anlaşılması kolay bir açıklama,
  • Belirli senaryolarda (artıları, eksileri ve alternatifleri) Next.js ile SSR ve SSG kullanımı için ve buna karşı bir iş örneği.

Bu makale ne değildir:

  • Next.js tabanlı SSR ve SSG'nin derinlemesine teknik analizi.

Bazı kodlara girecek olsam da, işleri daha geniş bir kitle için ulaşılabilir tutuyorum. SSR ve SSG'nin günümüz yazılım geliştirmedeki işletmelerin ihtiyaçları ile nasıl ilişkili olduğunu gerçekten göstermek istiyorum.

Tarihe hızlı bir bakış – neden SSR ve SSG'ye ihtiyacımız var?

SSR ve SSG'ye olan ihtiyacı daha net anlamak için, geçmişe büyük bir sıçrama yapalım. 4 Aralık 1995'te yağmurlu ve soğuk bir öğleden sonra...

JavaScript'in ilk günleri

... Brendan Eich, JavaScript'in ilk sürümü üzerindeki çalışmalarını yeni tamamlıyor. Netscape tarafından Netscape'in Navigator tarayıcısının bir parçası olarak gönderiliyor.

JavaScript, istemci tarafında bir komut dosyası dili olarak hızla popülerlik kazandı. Eski günlerde, çoğunlukla tipik bir HTML sayfasında form doğrulama ve temel sayfa etkileşimi için kullanılıyordu. Sonraki yıllarda her türlü yeniliğe tanık olduk.

İlk olarak, Node.js ortamı, sunucuda JavaScript'i tam teşekküllü bir arka uç dili olarak kullanmanın bir yolunu sağladı. Daha sonra, React veya Vue.js gibi modern web çerçeveleri ve kütüphaneleri, kullanıcı etkileşimi desteği açısından JavaScript'in yeteneklerini oldukça genişletti. Sonuç olarak, geliştiriciler yerel masaüstü ve mobil uygulamalara çok benzeyen bir web sayfası veya uygulama oluşturabilir. Gerçekten hızlı çalıştılar ve tarayıcıda çok az veya hiç yeniden yükleme gerektirmediler. Kullanıcılar onu sevdi. Geliştiriciler onu sevdi ve çağırdılar ...

... Tek Sayfalık Uygulamalar

Yerli benzeri performans, SPA'ları o zamanın modern web geliştirmesinde popüler hale getirdi, ancak herkes coşkuyu paylaşmadı. SPA'lar kesinlikle arama motorlarının sevgisini kazanmadı.

İstemci tarafında işlenen HTML içeriği yalnızca tarayıcıda yürütüldükten sonra kullanılabilirdi. Sonuç olarak, arama motorları tarafından gönderilen otomatik tarayıcılar çoğunu kaçırdı. Bu, SPA'ların düzgün bir şekilde indekslenmesini çok zorlaştırdı. Buna karşılık, web siteleri organik trafiğinin büyük bir bölümünü kaçırdı - arama motoru optimizasyonu açısından büyük bir sorun. Tam da SEO, 21. yüzyılın ilk on yılında gerçekten büyürken...

SSR vs SSG – teori

SSR ve SSG, bu sorunu çözmek için yazılım geliştirme topluluğunda gelişen iki tekniktir. Nedir bunlar?

Sunucu Tarafı İşleme Nedir?

SSR ile, JavaScript kodunu sunucuda oluşturabilir ve kullanıcıya dizine eklenebilir HTML gönderebilirsiniz. Böylece HTMLçalışma zamanı sırasında oluşturulur, böylece arama motorlarına ve kullanıcılara aynı anda ulaşabilir.

Next.js ortaya çıkmadan önce, böyle bir işlem çok fazla ince ayar gerektiriyordu ve sunucu yükü, isteğe bağlı içerik, önbelleğe alma ve hatta uygulama mimarisinin kendisi ile ilgili sorunlarla birlikte geliyordu. Beni yanlış anlamayın - kesinlikle yapılabilirdi, ama tüm bu zamanı bunun yerine iş mantığı geliştirmeye adayabilseydi güzel olurdu ...

Statik Site Oluşturma Nedir?

SSR ve SSG arasındaki en büyük fark, SSG durumunda, çalışma zamanı sırasında değil, HTML'nizin derleme süresi boyunca oluşturulmasıdır. Bu tür web siteleri son derece hızlıdır, çünkü HTML içeriği siz bir istekte bulunmadan önce bile sunulur. Öte yandan, her değişiklik yapıldığında web sitesinin yeniden oluşturulması ve tamamen yeniden yüklenmesi gerekir. Sonuç olarak, SSG tabanlı web siteleri, SSR'ye güvenenlerden çok daha az etkileşimli ve yerel benzerdir. Bunlar büyük ölçüde dinamik içeriği çok az olan veya hiç olmayan statik sitelerdir.

SSR ve SSG'nin arkasındaki temel fikirSSR ve SSG – başlıca faydaları

Hem SSR hem de SSG, işletmeler için bazı önemli avantajları paylaşır.

  • SEO

Kolayca dizine eklenebilir sayfalar ölçülebilir faydalara dönüşür - daha fazla organik trafik. SEO'yu pazarlama ve satış için stratejik olarak önemli gören web uygulamaları için, daha da gelişmiş karlara ve genel olarak alt satıra dönüşebilir. SEO ajansları tarafından hazırlanan raporlar, bu e-ticaret mağazasının organik trafikteki artış nedeniyle satışlarını% 67 oranında artırdığını doğrulamaktadır.

  • Performans

Google tarafından yapılan UX araştırmasısayfa yüklemesi 1 ila 3 saniye arasında giderse hemen çıkma oranının% 32'ye kadar arttığını göstermektedir. SSR ve SSG, istemci tarafında işleme ile karşılaştırıldığında yükleme süresini iyileştirir. Bunun nedeni, SSR'nin tarayıcının böyle bir istekte bulunmasını beklemeden tüm verileri toplamasıdır. SSG daha da ileri giderek, uygulamayı oluştururken tüm verileri toplar.

  • Kullanılabilir -lik

Ağır işlerin daha fazlasını tarayıcıda değil, sunucuda yaparak, istemci tarayıcılarını ve cihazlarını rahatlatırsınız. Sonuç olarak, SSR ve SSG, eski cihazlara ve daha yavaş internet bağlantılarına sahip kullanıcıların bir web uygulamasını görüntülemesini kolaylaştırır. Bu, özellikle mobil dönüşümler için önemli olabilir – mobil kullanıcıların% 73'ü yavaş yüklenen web siteleriyle mücadele etti.

Think With Google, SEO ve UX analizlerinin mükemmel bir kaynağıdır – sonuçta, Google arama motoru, SEO bilinçli geliştiricilerin ve pazarlamacıların en çok memnun etmeye çalıştığı şeydir.

Şimdiye kadar, SSR ve SSG'nin faydalarını görebileceğinizden eminim. Next.js kullanarak bunları nasıl gerçekleştirebileceğinizi öğrenelim.

Next.js ile sunucu tarafı işleme

SSR sayfaları her istek üzerine oluşturulur. SSR'nin arkasındaki mantık yalnızca sunucu tarafında yürütülür. Tarayıcıda asla çalışmaz.

Next.js tabanlı SSR nasıl çalışır?

Bir sayfadan getServerSideProps adlı bir işlevi dışa aktarırsanız, Next.js, getServerSideProps tarafından döndürülen verileri kullanarak bu sayfayı her istekte önceden oluşturur.

getServerSideProps yöntemi iki senaryoda çağrılır:

  • Bir kullanıcı sayfayı doğrudan istediğinde,
  • veya bir kullanıcı next/link veya next/router kullanarak istemci tarafı geçişinde sayfayı istediğinde.

getServerSideProps işlevi her zaman aşağıdaki özelliklerden birine sahip bir nesne döndürür:

  • props – bir sayfayı oluşturmak için gereken tüm verileri içerir.
  • notFound – sayfanın 404 durumu ve 404 Sayfası döndürmesine izin verir.
  • redirect – kullanıcının iç ve dış kaynaklara yönlendirilmesine izin verir.

İlginç bir şekilde, Next.js, getServerSideProps'ta kullanılan kodun tamamının, sunucuyla ilgili ve istemciyle ilgili kod oluşturabilmeniz için istemci paketinden kaldırılması gerektiğini iddia ediyor. Bu her zaman doğru değildir. Bir yanlış içe aktarma veya bağımlılık ve paketleme beklendiği gibi çalışmaz. Uygulamanızın yapısı ne kadar basit olursa, uygun davranışı elde etmek o kadar kolay olur.

Bir uygulama örneği:

import { GetServerSidePropsContext, GetServerSidePropsResult } from 'next'; type Product = { id: string; title: string;} type SearchResultsPageProps = { products: Array<Product>;} const SearchResultsPage = ({ products }: SearchResultsPageProps) => ( <div> {products.map((product) => (<p key={product.id}>{product.title}</p>))} </div>) export async function getServerSideProps({ res, query }: GetServerSidePropsContext): Promise<GetServerSidePropsResult<SearchResultsPageProps>> { const category = query?.category; if (!category) { return { redirect: { destination: '/' } } } const data = await fetch(`http://external-api.com/products?category=${category}`); const products = await data.json(); if (products.length === 0) { return { notFound: true } } return { props: { products, } }} export default ProductsPage;
view rawssr.tsx hosted with ❤ by GitHub

Gördüğünüz gibi, oldukça açıklayıcı:

  • kategori gibi bir sorgu parametresini işleyebilirsiniz
  • category parametresi yoksa, bir yönlendirme nesnesi döndürebilirsiniz. Ardından.js kullanıcıyı belirli bir hedefe yönlendirecektir
  • parametre varsa, devam edebilir ve harici bir API'ye çağrı yapabilirsiniz
  • harici API'deki veriler boşsa 404 sayfası döndürebilirsiniz
  • herhangi bir öğeniz varsa, sayfanızı bir ürün listesiyle düzgün bir şekilde oluşturabilirsiniz
SSR ne zaman kullanılır?

SSR, dış kaynaklardan sık güncellenen verileri önceden işlemeniz gereken uygulamalar için önerilir. Bu teknik özellikle, bir kullanıcı isteği gerçekleşmeden önce veriler statik olarak oluşturulamadığında ve aynı zamanda arama motorları tarafından kullanılabilir olması gerektiğinde önerilir.

Örnek? Kullanıcı tarafından oluşturulan içeriği içeren bir arama sonuçları sayfası veya bir e-ticaret web sitesi.

SSR'nin Artıları:
  • sayfa her zaman güncel içerik barındırıyorsa,
  • getServerSideProps içine bir hata atılırsa, Next.js otomatik olarak bir hata sayfası gösterecektir.
  • çerezlere, istek üstbilgilerine ve URL sorgu parametrelerine erişiminiz var
  • 404 sayfasıyla ilgili mantığı ve kullanıcı isteklerine ve verilerine dayalı yönlendirmeleri uygulayabilirsiniz
SSR'nin Eksileri:
  • sayfa, statik olarak oluşturulmuş bir sayfadan belirgin şekilde daha yavaştır, çünkü her istekte (örneğin, API çağrısı) bazı mantıkların yürütülmesi gerekir.
  • sunucu tarafında oluşturulan bir sayfa CDN'lerde yalnızca önbellek denetimi üstbilgisi ayarlanarak önbelleğe alınabilir (ek yapılandırma gerektirir).
  • İlk Bayt Süresi (TTFB – bir sunucunun bir sayfaya ilk bayt bilgi teslim etmesi için gereken süre) metriği, statik olarak oluşturulan bir sayfadan daha yüksek olacaktır

SSG'ye!

Next ile statik site oluşturma.js

SSG tabanlı sayfalar bir derleme zamanında oluşturulur. Her istekte tüm sayfayı yeniden kullanabilir (ve yeniden yükleyebilirsiniz).

Next.js tabanlı SSG nasıl çalışır?

Ardından.js statik oluşturma kullanarak sayfaları önceden oluşturur, bu da diğer şeylerin yanı sıra varsayılan olarak herhangi bir veri getirmediği anlamına gelir. Bu tür verileri içeren bir sayfa oluşturmanız gerekiyorsa, iki senaryonuz vardır:

  • Sayfa içeriği harici dat a'ya bağlıysa, yalnızca getStaticProps yöntemini kullanın,
  • sayfa yolları dış verilere bağlıysa – getStaticProps'a ek olarak getStaticPaths yöntemini kullanın.

getStaticProps yöntemi her zaman sunucuda çalışır (istemci tarafının aksine). Belirli bir yol için sayfa verilerini toplar. Yöntem üç durumdan birinde çağrılır:

  • Bir sonraki yapı sırasında,
  • yeniden doğrulamayı kullandığınızda arka planda,
  • unstable_revalidate kullanırken arka planda isteğe bağlı.

Artımlı Statik Rejenerasyon bölümündeki son iki durumu gözden geçireceğim.

getStaticProps yöntemi her zaman aşağıdaki özelliklerden birine sahip bir nesne döndürür:

  • props – bir sayfayı oluşturmak için gereken tüm verileri içerir,
  • notFound – sayfanın 404 durumu ve 404 Sayfası döndürmesine izin verir,
  • yönlendirme - kullanıcının iç ve dış kaynaklara yönlendirilmesine izin verir,
  • revalidate – sayfa yenilemesinin gerçekleşmesi için gereken süre (saniye cinsinden).

Gerçekten önemli olan, getStaticProps yönteminin gelen isteklere erişimi olmamasıdır. İsteğe erişmeniz gerekiyorsa, getStaticProps dışında bazı ara katman yazılımları kullanmayı veya bunun yerine SSR'yi kullanmayı düşünün. Geliştirme modunda, getStaticProps daha iyi bir geliştirici deneyimi için her istekte çağrılır.

getStaticPaths yöntemi yalnızca bir üretim derlemesi sırasında çalışır. Çalışma zamanı sırasında çağrılmaz. Yöntem getStaticProps ile birlikte kullanılmalıdırgetServerSideProps ile kullanılamaz.

getStaticPaths yöntemi her zaman aşağıdaki özelliklerden herhangi birine sahip bir nesne döndürür:

  • yollar – yapı zamanında hangi yolların önceden oluşturulması gerektiğini belirler,
  • geri dönüş: Kullanıcının yollar dizisinde listelenmeyen bir sayfayı ziyaret etmek istemesi durumunda uygulamanın nasıl davranması gerektiğini belirleyen bir boole bayrağı.

Sonraki.js, sürüm 12.1'de İsteğe Bağlı Statik Rejenerasyon sağlamıştır. Bu, içeriği harici bir kaynakta (ör. CMS veya veritabanı) güncellenen bir sayfanın statik önbelleğini manuel olarak temizleyebilirsiniz anlamına gelir. İşlev, gecikme olmadan her zaman güncel veriler sunma ve belirli bir sayfa için statik oluşturmayı sürdürme olanağı sağlar.

Bir uygulama örneği:

import { GetStaticPathsResult, GetStaticPropsResult, GetStaticPropsContext } from 'next'; type Post = { id: string; title: string;} type PostPageProps = { post: Post;} const PostPage = ({ post }: PostPageProps) => { return ( <p>{post.title}</p> )} export async function getStaticPaths(): Promise<GetStaticPathsResult> { const data = await fetch('http://external-api.com/posts'); const posts = await data.json(); return { paths: posts.map(post => ({ params: { id: post.id } })), fallback: false, }} export async function getStaticProps({ params }: GetStaticPropsContext<{ id?: string }>): Promise<GetStaticPropsResult<PostPageProps>> { const data = await fetch(`http://external-api.com/posts/${params.id}`); const post = await data.json(); return { props: { post, }, }} export default PostPage;
view rawssg.tsx hosted with ❤ by GitHub

Yukarıdaki örnek, daha önce bahsedilen iki senaryodan ikincisini uygular - yollar dış verilere bağlı olduğunda:

  • harici bir API'den gelen yanıta dayalı blog gönderilerinin listesini almak için getStaticPaths yöntemini uygularsınız,
  • getStaticPaths yöntemi, derleme zamanında önceden oluşturulacak bir dizi yol döndürür,
  • geri dönüş: getStaticPaths tarafından döndürülen false , uygulamanın yollarda listelenmeyen herhangi bir sayfa için 404 sayfası sunacağı anlamına gelir,
  • getStaticProps yöntemiyle, tek bir gönderinin verilerini getirir ve verileri bir sayfa bileşenine sayfa propları olarak döndürürsünüz.
SSG ne zaman kullanılır?

SSG, verileri önceden oluşturmanız gereken herhangi bir sayfada kullanılması önerilir. Bir kullanıcı isteği gerçekleşmeden önce oluşturulabilir. Bu, verilerinizin derleme zamanında veya başka bir deyişle - statik içerik sunmak veya mükemmel SEO yetenekleri sağlamak istediğiniz her sayfada mevcut olduğu anlamına gelir. Bu tür sayfalara örnek olarak, içeriği çok sık güncellenmeyen başsız bir CMS'den veri içeren bloglar veya pazarlama siteleri bulunur.

SSG'nin Artıları:
  • CDN önbelleğe almayı kullanarak çok fazla ekstra yapılandırma olmadan performansı artırabilirsiniz,
  • arka ucunuz veya veri kaynağınız çökse bile statik sayfanızın her zaman çevrimiçi olması,
  • Sayfanız sunucu tarafında oluşturulan bir sayfadan çok daha hızlıdır, çünkü tüm mantık derleme zamanında yürütülmüştür
  • arka ucunuz yalnızca sunucu yükünün azaltılmasına katkıda bulunan statik dosyalara hizmet eder,
  • statik olarak oluşturulan sayfanızı önizleme modunda çalıştırabilirsiniz; sayfa daha sonra istek anında işlenir.
SSG'nin Eksileri:
  • Gelen isteklere erişim olmaması nedeniyle, istek başlıklarını, çerezleri veya URL sorgu parametrelerini okuyamazsınız,
  • içeriğiniz site dağıtımları arasında değiştirilemez (ISR olmadan).

Gördüğünüz gibi, hem SSR hem de SSG'nin artıları ve eksileri var. Bu yüzden alternatif çözümleri de düşünmelisiniz.

SSR ve SSG alternatifleri

Söylenen ve yapılan her şeyle, SSR ve SSG'nin iş yükünüzü sunucuya taşımanın tüm olanaklarını tükettiği düşünülebilir. Ancak geliştiriciler gerçekten kendilerine yardım edemezler, ancak her zaman yenilik yaparlar. Artımlı Statik Rejenerasyona Girin!

Artımlı Statik Rejenerasyon – nedir bu?

Artımlı Statik Rejenerasyon, Next.js'daki en güçlü özelliklerden biridir. Statik oluşturmayı, her yeniden yüklemede tüm sayfanızı yeniden oluşturmaya zorlamayacak şekilde kullanmanızı sağlar.

Artımlı Statik Rejenerasyon, statik üretimin bir uzantısıdır. getStaticProps tarafından iade edilen ek bir tesis sunmaktadır. Bu özelliğe revalidate adı verilir ve saniye cinsinden sayılır. revalidate özelliği, Next.js belirli bir sayfa için statik HTML'yi ne sıklıkta yeniden oluşturması gerektiğini belirtir. Rejenerasyon, her "X" saniye yerine bir kullanıcı isteği tarafından tetiklenir. Bu özellik, blog gönderileri, ürünler, kullanıcıyla ilgili veriler, pazarlama içeriği gibi belirli bir sayfada göstermek istediğiniz verilerin yapısına göre yapılandırılmalıdır.

ISR, web uygulamalarının ölçeklenebilirliğini artırır. Yapı zamanında en popüler veya en son yüzlerce gönderiyi statik olarak oluşturabilir ve makalelerin geri kalanı için ISR'yi etkinleştirebilirsiniz. Bir kullanıcı getStaticPaths'te listelenmeyen bir sayfaya istekte bulunduğunda, Next.js bu kullanıcı için sayfayı sunucu olarak oluşturur ve sayfayı arka planda statik olarak oluşturur. Bir sonraki kullanıcı statik olarak oluşturulan içeriği alır. Her blog yazısı için SSG'nin tüm avantajlarını koruyarak oluşturma süresini kısa tutacaktır. Yapı zamanında 10.000'den fazla gönderiyi önceden oluşturmak istiyorsanız yapının ne kadar sürebileceğini hayal edin!

Bir uygulama örneği:

import { GetStaticPathsResult, GetStaticPropsResult, GetStaticPropsContext } from 'next'; type Post = { id: string; title: string;} type PostPageProps = { post: Post;} const PostPage = ({ post }: PostPageProps) => { return ( <p>{post.title}</p> )} export async function getStaticPaths(): Promise<GetStaticPathsResult> { const data = await fetch('http://external-api.com/posts'); const posts = await data.json(); return { paths: posts.map(post => ({ params: { id: post.id } })), fallback: 'blocking' }} export async function getStaticProps({ params }: GetStaticPropsContext<{ id?: string }>): Promise<GetStaticPropsResult<PostPageProps>> { const data = await fetch(`http://external-api.com/posts/${params.id}`)); const post = await data.json(); return { props: { post, }, revalidate: 10, // In seconds }} export default PostPage;
view rawisr.tsx hosted with ❤ by GitHub
Nasıl çalışır?

SSG için yaptığınız gibi getStaticPaths'te önceden oluşturulacak gönderilerin bir listesini getirirsiniz. Aradaki fark, geri dönüş değerinin engelleme olarak ayarlanmış olmasıdır. Bu, kullanıcı henüz statik olarak oluşturulmamış bir sayfayı ziyaret ettiğinde, Next.js'in söz konusu sayfa için sunucu işleme yapıldıktan sonra içerik döndüreceği anlamına gelir. SSG, takip eden kullanıcılar için arka planda yapılacaktır.

getStaticProps'tarevalidate adlı bir nesneyi döndürmekle görevli yeni bir özellik vardır. Saniye cinsinden sayılır, böylece Next.js bir istek geldiğinde sayfayı önceden oluşturur, ancak en fazla 10 saniyede bir kez. Bir sayfa günde yalnızca bir kez ziyaret edildiğinde, yeniden doğrulama günde bir kez tetiklenir.

ISR'yi ne zaman düşünebilirsiniz?
  • Tüm siteyi yeniden oluşturmak zorunda kalmadan içeriği yenilemek istediğinizde.
  • Önceden oluşturmanız gereken yüzlerce sayfanız olduğunda, ancak bir uygulama oluşturmak için saatler harcamak istemiyorsanız.
  • Yakında oluşturulacak sayfaları statik olarak oluşturmak istediğinizde - örneğin içerik editörleri tarafından. Yeni bir blog gönderisi oluşturduklarında, yeni oluşturulan bir sayfa oluşturmak için uygulamanızı yeniden oluşturmak zorunda kalmak istemezsiniz.
CSR veya İstemci Tarafı İşleme

İstemci tarafı veri getirmeyi temel alan istemci tarafı işleme başka bir alternatiftir. Sunucu tarafı işleme API'si ile çalışmanın aksine, veri getirme işlemi bir sayfa veya bileşen düzeyinde yapılabilir.

İstemci tarafı veri getirme, uygulamanızın performansını ve sayfalarınızın yükleme hızını olumsuz yönde etkileyebilir. Bunun nedeni, veri getirmenin bileşen veya sayfa bağlandığında ve veriler önbelleğe alınmadığında yapılmasıdır.

KSS'yi ne zaman düşünebilirsiniz?

  • Satın alma stratejiniz SEO'ya öncelik vermediğinde,
  • verilerinizi önceden oluşturmanız gerekmediğinde,
  • Sayfalarınızın içeriğinin sık sık güncellenmesi gerektiğinde,
  • sayfa içeriği günlüğe kaydedilen kullanıcı verileriyle ilgili olduğunda.

SSR veya SSG kullanmaya karar verdiğinizde, her zaman Next.js kullanarak mı uygulamalısınız?

SSR ve SSG için Neden Next.js?

Sonraki.js, sayfalarınızı oluşturmak için birçok farklı yaklaşım sunan güçlü bir çözümdür. Çok fazla tekniği kapsadığından, gereksinimlerinize göre kolayca ayarlayabilirsiniz. Farklı işleme stratejileri kullanabilir veya hatta bunları bir araya getirebilirsiniz.

Hangi yaklaşımın en iyisi olduğu nasıl anlaşılır? İşte kendinize sormanız gereken birkaç yararlı soru:

  • Hem mükemmel SEO'ya hem de performansa mı ihtiyacınız var? SSG gidilecek yoldur.
  • SEO'ya ve verilerinizi sık sık güncelleme yeteneğine ihtiyacınız var mı? SSR kullanın.
  • Sık sık güncellenen verilere ihtiyacınız var mı, ancak SEO ve performans bir öncelik değil mi? KSS mantıklı bir seçimdir.
  • İçeriğin sık sık güncellenmesini gerektiren binlerce sayfanız var mı? ISR dikkate değer.

Yukarıdaki senaryoların birden çok kombinasyonu vardır. En iyi dengeyi bulmak, projenizin kapsamlı bir analizini gerektirir.

Next.js seçilmesinin bir başka nedeni de basit ve yine de çok önemli - Next.js son derece popülerGithub'da 83.000'den fazla yıldıza (diğer alternatiflerden daha fazla) ve büyük bir topluluğa sahiptir. AyrıcaVercel şirketi arka planda çalışarak, Next.js çerçevesinin sürekli gelişimini ve bakımını sağlar. Bir araya geldiğinde, burada kalmak için burada olan istikrarlı ve canlı bir ortama sahipsiniz.

Tabii ki, her çerçevede olduğu gibi, Next.js'in de dezavantajları vardır. Örneğin, Docker kullanarak üretim ortamında birden çok Next.js örneği arasında statik içerik paylaşmak o kadar kolay değildir. Yine de, Next.js'in esnekliği, projedeki değişen gereksinimler durumunda çözüm bulmayı nispeten kolaylaştırır. Büyük olasılıkla işleri halletmek için başka bir çözüme veya çerçeveye geçmeniz gerekmeyecektir.

Sonraki.js alternatifler

Gatsby

Gatsby, herhangi bir CMS veya API ile web siteleri oluşturmayı çok keyifli hale getiren hızlı ve esnek bir çerçeve ve statik site üreticisidir. Gatsby, derleme zamanında statik HTML oluşturan web siteleri oluşturmak için kullanılır. Daha sonra, kod CDN'lerde saklanabilir ve dünyadaki tüm kullanıcılarınıza dağıtılabilir. Gatsby, React ve GraphQL'nin en iyi unsurlarını birleştirir, bu nedenle geliştiriciler için oldukça iyi bir zevktir. Sürüm 4'ten bu yana, Gatsby çerçeveyi daha da güçlü hale getiren SSR'yi desteklemektedir. 52.000'den fazla GitHub yıldızı, Gatsby'nin popülaritesinin bir kanıtıdır.

Remix

Remix, kullanıcı arayüzüne odaklanmanızı sağlayan tam yığınlı bir web çerçevesidir. Hızlı ve kaygan bir kullanıcı deneyimi sunar.

Remix'te yalnızca iki işleme modu vardır – SSR'yi çalışma zamanında ve CSR'yi çalışma zamanında kullanabilirsiniz. Remix, kullanıcı arayüzleri oluşturmak için React'i kullanır. İç içe geçmiş yollar içerir, yani herhangi bir yükleme durumu olmadan tek bir görünümde birden fazla rota çalıştırabilirsiniz. Remix son birkaç ay içinde popüler hale geldi. Topluluk hızla büyüyor. 14.000'den fazla GitHub yıldızına sahiptir.

Hexo Dili

Hexo, SSG kategorisine ait Node.js destekli bir araçtır. Hızlı, basit ve güçlüdür. Öncelikle bir blog çerçevesi olarak pazarlanmaktadır. Yayınlarınızı Markdown veya başka bir oluşturma motoruyla ayrıştırır ve saniyeler içinde statik dosyalar oluşturur. GitHub'da 34.000'den fazla yıldızı var.

Gelecek neler getirecek?

Next.js yol haritası herkese açık olmadığından (kilometre taşları hariç), gelecekte nasıl görüneceğini tahmin etmek o kadar kolay değildir. Ancak, gerçekten bahsetmeye değer en az bir özellik var. Bu noktada, yalnızca alfa sürümünde kullanılabilir.

React Sunucu Bileşenleri

React 18, React Sunucu Bileşenlerini tanıtıyor. İlk bakışta çok heyecan verici gelmiyor, ama daha iyi oluyor! Dokümanlarla başlayalım.

Kısacası, sunucu bileşenleri ve mantıkları sadece sunucu üzerinde yürütülecektir. Hidrasyon işlemine tabi tutulmayacaklar. Sonuç olarak, yeni oluşturulmuş statik HTML parçaları sunacaksınız. Doğal olarak, sunucu bileşenleri istemcinin alt bileşenlerini içerebilir. Bu bileşenler tarayıcıda tamamen etkileşimli ve hidratlanmış olabilir.

Pratik sonuçları anlamak için, tekrar dokümanlara geri dönelim.

Alfa sürümünde olmasına rağmen, sunucu bileşenleri next/link, next/image ve next/document dahil olmak üzere Next.js API'lerinden bazılarını zaten desteklemektedir . Yönlendiriciye de erişimleri var. Yönlendirici pervane tarafından bileşene enjekte edilir .

Sunucu bileşenleri durum bilgisi içermez, bu nedenle React Hook'ları bu bileşenlerin içinde useContextuseStateuseReducter veya useEffect olarak kullanamazsınız . Ek olarak, i18n (uluslararasılaştırma) veya next/head gibi özellikler henüz desteklenmemektedir.

Benim düşünceme göre, sunucu bileşenleri Next.js çerçevesinin kullanılma şeklini potansiyel olarak değiştirebilir. Geleneksel SSR'nin yerini alabilirler. Avantajları arasında tarayıcıya daha az JavaScript göndermek (indirmek için daha az kilobayt) ve hidrasyon işlemini istemci bileşenleriyle sınırlamak sayılabilir. Her ikisi de web performansını, özellikle de İlk Bayt Süresi ve İlk Giriş Gecikmesi ölçümlerini iyileştirerek kullanıcı deneyimini iyileştirmelidir.

Her şey teoride kulağa harika geliyor, ancak yine de sunucu bileşenlerinin resmi olarak piyasaya sürülmesinin uygun denemeler yapmasını ve onlar hakkında karar vermesini bekleyeceğim. Kullanıcı deneyimini, web performansını ve mevcut Next.js iş akışlarını nasıl etkilediklerine dikkat edeceğim.

React Hooks hakkında daha fazla bilgi edinmek ister misiniz? React Hooks vs Redux'a genel bakışUygulamanızı geliştirmek ve geleceğe hazır hale getirmek için SSR/SSG

Ve hepsi bu kadar! Tabii ki, SSR ve SSG hakkında söylenecek daha çok şey var. Ancak bu, hem uygulamanızı hem de işinizi daha verimli hale getirmek için nasıl çalıştığına dair sağlam bir anlayış sağlamalıdır. Biliyorsunuz ki:

  • SSR ve SSG, işletmelerin içeriklerinin performansı, kullanılabilirliği ve görünürlüğü ile karşılaştıkları gerçek sorunlara yanıt vermek için organik olarak gelişen tekniklerdir .
  • SSR, web uygulamanızdan hiçbir şekilde ödün vermeden tüm bu ölçümleri geliştirir.
  • SSG, metriklerin iyileştirilmesi açısından daha da fazlasını sunar, ancak birçok senaryoda geçerli değildir - veri her değiştiğinde web sitenizi yeniden oluşturma ihtiyacı, kullanım durumlarını müşteriyle çok fazla veri alışverişi içermeyen sayfalarla sınırlar.
  • Sonraki.js, Artımlı Statik Rejenerasyon ile ilgili bazı SSG sorunlarına bir çözüm sunar. Tabii ki, bu çözüm kendi artıları ve eksileri paketi ile birlikte gelir. İkincisi, önbelleğe alma ve hata ayıklama ile ilgili sorunları içerir.

Bir geliştirici veya iş adamı olarak yazılım geliştirme konusunda herhangi bir deneyiminiz varsa, kesinlikle herkese uyan tek bir çözüm olmadığını fark edersiniz. Uygulamanız ne kadar karmaşık ve yenilikçi olursa, düşüncenin tuttuğu gerçek o kadar fazla olur. Aynı şey SSR ve SSG için de geçerli.