İstemci tarafı ve Sunucu tarafı ile Web Uygulamaları için ön işleme karşılaştırması

Son zamanlarda ön uç toplulukta bir şeyler oluyor. Sunucu tarafı işleme, React ve yerleşik sunucu tarafı hidrasyon özelliği sayesinde giderek daha fazla ilgi görüyor. Ancak kullanıcıya süper hızlı ilk bayt süresi (TTFB) puanıyla hızlı bir deneyim sunmanın tek çözümü bu değil: Ön işleme de oldukça iyi bir stratejidir. Bu çözümler ile tamamen istemci tarafından oluşturulan bir uygulama arasındaki fark nedir?

İstemci Tarafından Oluşturulan Uygulama

Angular, Ember.js ve Backbone gibi çerçeveler mevcut olduğundan, ön uç geliştiriciler her şeyi istemci tarafında işleme eğiliminde olmuştur. Google ve JavaScript'i "okuma" yeteneği sayesinde oldukça iyi çalışıyor ve hatta SEO dostu.

İstemci tarafı işleme çözümüyle, isteği tek bir HTML dosyasına yönlendirirsiniz ve sunucu, siz tüm JavaScript'i getirene ve içeriği oluşturmadan önce tarayıcının her şeyi derlemesine izin verene kadar herhangi bir içerik olmadan (veya bir yükleme ekranıyla) gönderir.

İyi ve güvenilir bir internet bağlantısı altında oldukça hızlıdır ve iyi çalışır. Ama çok daha iyi olabilir ve bunu bu şekilde yapmak zor olmak zorunda değil. İlerleyen bölümlerde göreceğimiz şey bu.

Sunucu Tarafı Oluşturma (SSR)

Bir SSR çözümü, yıllar önce çokça yaptığımız, ancak istemci tarafı işleme çözümü lehine unutmaya meyilli olduğumuz bir şeydir.

Eski sunucu tarafı işleme çözümleriyle, örneğin PHP ile bir web sayfası oluşturdunuz, sunucu her şeyi derledi, verileri dahil etti ve istemciye tam olarak doldurulmuş bir HTML sayfası teslim etti. Hızlı ve etkiliydi.

Ama… başka bir rotaya her gittiğinizde, sunucunun işi yeniden yapması gerekiyordu: PHP dosyasını alın, derleyin ve HTML'yi teslim edin, tüm CSS ve JS sayfanın yüklenmesini birkaç yüz ms'ye kadar geciktirir veya hatta tüm saniyeler.

Ya ilk sayfa yüklemesini SSR çözümüyle yapabilir ve ardından AJAX ile dinamik yönlendirme yapmak için bir çerçeve kullanarak yalnızca gerekli verileri getirebilseydiniz?

Bu nedenle, React bu sorunu kullanımı kolay bir çözümle popüler hale getirdiği için SSR topluluk içinde giderek daha fazla ilgi görüyor: RenderToString yöntemi.

Bu yeni tür web uygulamasına evrensel uygulama veya eşbiçimli uygulama denir. Bu terimlerin tam anlamları ve aralarındaki ilişki konusunda hala bazı tartışmalar var, ancak birçok insan bunları birbirinin yerine kullanıyor.

Her neyse, bu çözümün avantajı, aynı kodla bir uygulama sunucusu ve istemci tarafı geliştirebilmek ve özel verilerle kullanıcıya gerçekten hızlı bir deneyim sunabilmektir. Dezavantajı, bir sunucu çalıştırmanız gerekmesidir.

SSR, verileri almak ve bir sayfayı özel içerikle önceden doldurmak için kullanılır ve sunucunun güvenilir internet bağlantısından yararlanır. Yani, sunucunun kendi internet bağlantısı, lie-fi'lı bir kullanıcınınkinden daha iyidir), bu nedenle, verileri kullanıcıya teslim etmeden önce önceden getirip birleştirebilir.

Önceden doldurulmuş verilerle, bir SSR uygulaması kullanmak, istemci tarafından oluşturulan uygulamalarda sosyal paylaşım ve OpenGraph sistemiyle ilgili bir sorunu da çözebilir. Örneğin, istemciye teslim edilecek yalnızca bir index.html dosyanız varsa, bunların yalnızca bir tür meta verisi olacaktır - büyük olasılıkla ana sayfa meta verileriniz. Bu, farklı bir rotayı paylaşmak istediğinizde bağlamsallaştırılmayacaktır, bu nedenle rotalarınızın hiçbiri, kullanıcıların dünyayla paylaşmak isteyeceği uygun kullanıcı içeriği (açıklama ve önizleme resmi) ile diğer sitelerde gösterilmeyecektir.

ön işleme

Evrensel bir uygulama için zorunlu sunucu, bazıları için caydırıcı olabilir ve küçük bir uygulama için aşırıya kaçabilir. Bu nedenle ön işleme gerçekten güzel bir alternatif olabilir.

Bu çözümü Preact ve önceden seçilmiş tüm yolları derlemenize izin veren kendi CLI'si ile keşfettim, böylece tam olarak doldurulmuş bir HTML dosyasını statik bir sunucuda saklayabilirsiniz. Bu, Node.js'ye ihtiyaç duymadan Preact/React hidrasyon işlevi sayesinde kullanıcıya süper hızlı bir deneyim sunmanızı sağlar.

Buradaki sorun şu ki, bu SSR olmadığı için, bu noktada gösterilecek kullanıcıya özel verileriniz yok - olduğu gibi doğrudan ilk istek üzerine gönderilen yalnızca statik (ve biraz genel) bir dosya. Dolayısıyla, kullanıcıya özel verileriniz varsa, kullanıcının hayal kırıklığına uğramasını önlemek için verilerinin geldiğini göstermek için güzel tasarlanmış bir iskeleti entegre edebileceğiniz yer burasıdır:

Başka bir yakalama daha var: Bu tekniğin çalışması için, yine de kullanıcıyı doğru dosyaya yönlendirecek bir proxy veya başka bir şeye ihtiyacınız var.

Niye ya?

Tek sayfalık bir uygulama ile, tüm istekleri kök dosyaya yönlendirmeniz gerekir ve ardından çerçeve, yerleşik yönlendirme sistemi ile kullanıcıyı yeniden yönlendirir. Yani ilk sayfa yüklemesi her zaman aynı kök dosyadır.

Bir ön işleme çözümünün çalışması için, proxy'nize bazı yolların her zaman kök index.html dosyasına değil, belirli dosyalara ihtiyacı olduğunu söylemeniz gerekir.

Örneğin, dört rotanız ( / , /about , /jobs ve blog ) olduğunu ve hepsinin farklı düzenleri olduğunu varsayalım. İskeleti kullanıcıya teslim etmek için, daha sonra React/Preact/etc'ye izin verecek dört farklı HTML dosyasına ihtiyacınız var. verilerle yeniden sulandırın. Bu nedenle, tüm bu yolları kök index.html dosyasına yeniden yönlendirirseniz, sayfa yükleme sırasında hoş olmayan, sorunlu bir his verir, bu sayede kullanıcı yüklemeyi bitirip düzeni değiştirene kadar yanlış sayfanın iskeletini görür. Örneğin, kullanıcı Pinterest benzeri bir galeriye sahip farklı bir sayfa istediğinde yalnızca bir sütunlu bir ana sayfa iskeleti görebilir.

Çözüm, proxy'nize bu dört yolun her birinin belirli bir dosyaya ihtiyacı olduğunu söylemektir:

• https://my-website.com → Kök index.html dosyasına yönlendir
• https://my-website.com/about → /about/index.html dosyasına yönlendirin
• https://my-website.com/jobs → /jobs/index.html dosyasına yönlendir
• https://my-website.com/blog → /blog/index.html dosyasına yönlendir

Bu nedenle bu çözüm küçük uygulamalar için faydalı olabilir—birkaç yüz sayfanız olsaydı ne kadar acı verici olacağını görebilirsiniz.

Açıkça söylemek gerekirse, bunu bu şekilde yapmak zorunlu değildir; doğrudan statik bir dosya kullanabilirsiniz. Örneğin, https://my-website.com/about/ dizini içinde otomatik olarak bir index.html araması yapacağından herhangi bir yeniden yönlendirme olmadan çalışacaktır. Ancak, param url'leriniz varsa bu proxy'ye ihtiyacınız vardır - https://my-website.com/profile/guillaume isteği kendi düzeniyle /profile/index.html yönlendirmesi gerekir, çünkü profile/guillaume/index.html mevcut değil ve bir 404 hatasını tetikleyecek.

Kısacası, yukarıda açıklanan işleme stratejileriyle ilgili üç temel görünüm vardır: Bir yükleme ekranı, bir iskelet ve nihayet oluşturulduktan sonra tam sayfa.

Stratejiye bağlı olarak, bazen bu görünümlerin üçünü de kullanırız ve bazen doğrudan tam işlenmiş bir sayfaya atlarız. Yalnızca bir kullanım durumunda farklı bir yaklaşım kullanmaya zorlanıyoruz:

Yalnızca İstemci Oluşturma Genellikle Yeterli Değildir

İstemci tarafından oluşturulan uygulamalar artık kaçınmamız gereken bir şey çünkü kullanıcı için daha iyisini yapabiliriz. Ve bu durumda daha iyisini yapmak, ön işleme çözümü kadar kolaydır. Bu kesinlikle yalnızca istemci oluşturma üzerinde bir gelişmedir ve uygulanması, tamamen sunucu tarafında oluşturulmuş bir uygulamadan daha kolaydır.

Çok sayıda farklı sayfa içeren büyük bir uygulamanız varsa, bir SSR/evrensel uygulama gerçekten güçlü olabilir. Bir sosyal tarayıcıyla konuşurken içeriğinizin odaklanmasını ve alakalı olmasını sağlar. Bu, artık sitenizin performansını sıralarken hesaba katan arama motoru robotları için de geçerlidir.

Bir SPA'nın önceden oluşturulmuş ve SSR sürümlerine dönüştürülmesini anlatacağım ve performanslarını karşılaştıracağım bir sonraki eğitim için bizi izlemeye devam edin.