İstemci tarafı veya sunucu tarafı işlemeyi vurgulama arasındaki artıları / eksileri

Neden çok sayıda sunucu tarafı işleyen bir web uygulaması yazmak isteyeyim?

Bana göre, programın istemci tarafına yazılması büyük bir avantajdır çünkü mümkün olan en fazla sunucu yükünü ortadan kaldırır, çünkü istemciye yalnızca minimum işlemle veri göndermek zorundadır.

Sunucu tarafında yazmanın ve istemci tarafına yalnızca bir görünüm olarak davranmanın yanı sıra web uygulamaları yazarken çok az şey görüyorum . Neden bunu yapmak isteyeyim ki? Gördüğüm tek avantaj, istediğim dilde yazabilmem ( http://www.paulgraham.com/avg.html ).

İki önemli konu var.

1. Birincisi kolaydır - genellikle istemci tarafında ne tür kaynaklar bulunduğunu bilmezsiniz. Bir şeyi işlemek için 1,5 GB gerekiyorsa, bunu bilinmeyen bir istemci platformunda bilinmeyen bir istemci tarayıcısına (IE, Safari, Opera, Firefox, vb.) Müşteri, bunalmış olduğunuzda sisteminin donduğunu takdir edecek mi?

2. İkincisi daha mimari - dış dünyaya hangi katmanları göstermek istiyorsunuz? Çoğu, veri katmanınızı ortaya çıkarmanın inanılmaz derecede riskli olduğunu kabul eder. Hizmet katmanınız nasıl? Gerçekten bu mantığı oraya dağıtmak ister misiniz? Bunu yaparsanız, giriş noktalarını veri katmanınıza da açığa çıkarıyor musunuz? Hizmet katmanı sunucusu tarafını tutarsanız, geriye ne kalır? Kullanıcı arayüzü, değil mi? Bunun sunucuda ne kadarının ve istemcide ne kadar yaşadığına ilişkin değerlendirmeler için 1. nedene bakın.

İlk ve en önemlisi Güvenlik . Tüm mantığı müşteriye itin ve bilgisayar korsanları ve istismarlar için adil bir oyundur.

Algılanan herhangi bir değere sahip herhangi bir şey, özellikle parasal değer olmak üzere 5 dakika sürmez ve oynanır veya saldırıya uğrar veya sömürülür ve sisteminizi oldukça kötü kırar. Parasal değeri çok az olsa da hiç olmasa da, sıkıldıkları için sisteminizi kırmak için onu hackleyecek bir sınıf insan var.

İstemci Tarafı ve Sunucu Tarafı

İstemci tarafı işleme, sayfa tabanlı yaklaşımların ve SOAP'ın aksine, daha popüler REST standartlarına ve MVC'ye uygundur. Bu eğilimlerin ortaya çıkması ve AJAX ve Html-RIA'ya odaklanması, istemci tarafı komut dosyası oluşturma yükselişte ve daha popüler; ancak, güvenlik kaygıları ve istemci yetenekleri nedeniyle, istemci tarafı komut dosyalarının belirli bir özelliği vardır ve her şey için kullanılmamalıdır.

hususlar:

seyyar

Hedef kitlenizin büyük bir bölümü mobil kullanıcı olacaksa, yoğun işlem sunucuya bırakılmalıdır.

Tarayıcılar arası tutarlılık

Web standartları uzun bir yol kat etti ve bu bir endişe olmayabilir, ancak her web geliştiricisi IE 6,7 ve 8'in ve bazen Safari'nin istemci tarafında komik davranabileceğini biliyor - bazı işlevler nedeniyle çalışmayabilir güvenlik kısıtlamaları ve diğerleri uygulanmayan standartlar nedeniyle. Son kullanıcının bir tarayıcıyı belirli kısıtlamalara sahip olacak şekilde yapılandırabileceğini veya hatta istemci tarafı işlemeyi tamamen kapatabileceğini de unutmayın (javascript yok!). Tutarlılık kullanıcıların% 100'ü için bir gereklilikse (ve özellikle de alışılmışın dışında bir şey yapıyorsanız) sunucu tarafı çok önemlidir.

Güvenlik

Güven altına almak istediğiniz veri işlemlerinin sunucuda yapılması gerekir. İstemci tarafında işlenen tüm veriler kesinlikle manipülasyona açıktır. Örneğin, daha sonra sisteme geri gönderilen bazı bilgileri işleyen bir javascript işleviniz varsa - örnek arka uç güvenliğiniz olsa bile, sonucu geri gönderilmeden hemen önce işlemek çok kolay olurdu

UI / UX

İstemci tarafı işleme, kullanıcı arabirimi ve zengin internet uygulamaları (RIA) oluşturma için bırakılmıştır. Animasyonlar, efektler, kullanıcı etkileşimleri oluşturmak ve tüm sayfayı yeniden yüklemek yerine AJAX çağrıları aracılığıyla içeriği dinamik olarak yüklemek için kullanılır.

Öncelikle çabaların bir kopyası olacaktır. Büyük olasılıkla istemciden gelen tüm veriler tekrar sunucu düzeyinde kontrol edilecek ve işlenecektir.

Sunucu, zengin / sağlam istemcinizin verileri gönderdiğini varsayamaz, bu nedenle gönderilen herhangi bir veriyle sunucunun veriyi doğrulaması ve işlemesi gerekir. Bu yüzden oraya koymak mantıklı.

Ancak, daha iyi bir kullanıcı arayüzü deneyimi için bazı mantıkların istemci düzeyinde yapılabileceğine inanıyorum.

Doğru, neden eksiksiz veya yanlış değilse sunucuya veri gönderebilirsiniz. Gerekli alanları veya düzgün biçimlendirilmiş telefonları veya e-posta adreslerini kontrol etmek kolaydır. Bir form göndermeyi hiç sevmedim ve sonra bir alana girmeyi unuttuğumu söylemek için 5 saniye bekledim. Bu tür bir işlem, emin olun, istemcide yapın ve doğru olduğundan emin olun ve kullanıcıya hızlı bir yanıt için istemci tarafı mantığı kullanın. İşaret ettiğiniz gibi, bir bonus yan etkisi, sunucunuzun daha az kötü veri talepleriyle uğraşmak zorunda kalacağıdır. ANCAK, sunucu yine de doğrulamak zorunda, bu yüzden mantık duping. Ancak, kullanıcılarınız daha mutlu olacak.

Burada ince bir çizgi var. Basit doğrulama mantığı TAMAM, temel iş mantığı TAMAM değil.

1. Her şeyden önce, çoğu 3 katmanlı olmasa da, web uygulamalarının mimarisini anlamanız gerekir:

   a) İstemci / Sunum - HTML ve Javascript, ActiveX / Flash / Java Uygulaması / Silverlight içerebilir. Bir uzuv çıkacağım ve bir arka uç sunucusu ile iletişim kuran yerel mobil uygulamalar ekleyeceğim. Temel olarak bu katmanın rolü, sistemin kullanıcısı ile etkileşime girmesi için bir arayüz sağlamaktır.

   b) İş Mantığı - İstemciden verilerin toplandığı, işlendiği ve depolandığı ve verilerin veri istemcilerinin işlendiği ve istemciye geri gönderildiği PHP / RoR / Java

   c) Arka Uç Veri Deposu - sistem bilgileri için kalıcı depolama sağlar

2. Peki tüm katmanlarda doğrulamayı nerede yapıyorsunuz? Niye ya?

   a) Müşteri tarafı - kullanıcının doğru verileri, gerekli alanları vb. girmesini sağlayın

   b) İş mantığı - istemci verilerini filtreleyin, sterilize edin ve onaylayın. Verilerin depolama için iyi biçimlendirildiğinden emin olmak için daha karmaşık iş kuralları yürütün. Ön uçta yapılan doğrulama işlemlerinden bazıları burada tekrarlanır, çünkü farklı istemciler olabilir, örneğin Javascript'in devre dışı bırakılabileceği tarayıcıları alın. Örneğin API'ler aracılığıyla farklı kaynaklardan gelen verileri de kabul edebilir, bu nedenle hepsinin doğrulanması gerekir.

   c) Arka Uç Veri Deposu - kısıtlamalar verilerin depolanması ve daha sonra alınması için iyi oluşturulmasını sağlar.

Doğrulama çabalarınızı nereye odaklarsınız, her katmanı en uygun doğrulamayı gerçekleştirmek için kullanın ve katmanla baş edebilecek katman için daha karmaşık kurallar bırakın

Büyük bir kısmı işleminizi verilerinize yakın tutuyor. Yüzlerce GB verileriniz varsa, bunu istemciye göndermeyeceğiniz açıktır. Veri erişim hızları arttıkça bu daha az sorun haline geliyor, ancak bir Büyük Veri siteniz varsa, sunucuya göndermeden önce olabildiğince çok filtreleme ve daralma yapmak istersiniz.

Davranışınızı tamamen istemci tarafında oluşturduğunuzda (örneğin Javascript ile) SEO bir sorun haline gelebilir.

Sunucu tarafında çok şey tutan web çözümleri, belirli bir URL'de (genellikle RESTful) yayınlanan belirli içeriği arama motorları tarafından görülebilecek şekilde daha kolay tutabilir.

Bu aynı zamanda ziyaretçinin belirli bir sayfaya yer işareti koyabileceği anlamına gelir. Facebook'ta denedin mi?

Bu şeyler çözülebilir, ancak genellikle sunucuda çok şey yapan uygulamalara (RAILS, WordPress vb.) Yerleştirilir, oysa REACT derliyorsanız, kasnaklardan atlamanız gerekir.

Nedeni istikrardır .

Sunucu tarafında, kararlı bileşenleri seçebilirim. Genellikle bu, Java'yı ve FreeMarker gibi çok dikkatli seçilmiş kütüphaneleri seçtiğim anlamına gelir. Söylemeye gerek yok, Java'nın standart kitaplıklarının dışındaki her kitaplık tek kullanımlık olarak ele alınır, bu nedenle kendi kitaplıklı bir sarıcı aracılığıyla harici kitaplıklara erişirim. Bu, gereksinim ortaya çıkarsa bir kütüphaneden diğerine kolayca değiştirebileceğim anlamına gelir.

Java'yı yeni bir sürüme güncellediğimde, Java iyi sürüm güncellemelerinde bile son derece kararlı bir bileşen olduğu için genellikle iyi çalışır. Ayrıca, sahip olduğum her sunucu aynı Java sürümünü çalıştırıyor. Her istemci aynı JavaScript uygulamasını çalıştırmaz.

İstemci tarafında, kararlı bileşenleri seçemiyorum. Tarayıcı üreticileri beni özellikle sevmediğim bir dili, ama kullanmak zorunda olduğum bir dili seçmeye zorlayacak. (Ve bana JavaScript'e derlenen dillerden bahsetme, korkunç!) Her tarayıcının JavaScript uygulaması farklı. Bu, desteklenen tüm tarayıcı sürümleriyle ürünümü test etmenin tamamen cehennem olduğu anlamına gelir.

Çözümüm? Sunucu tarafında yapabildiğim kadar çok işlem gerçekleştiriyorum ve istemci tarafı sunucuya veri gönderen ve sunucudan JSON ve HTML parçaları biçiminde veri alan hafif bir sarmalayıcı. XML'den kaçının; bunun yerine JSON kullanın.

İstemci tarafı şablonlama yapmıyorum; Sunucudaki içeriği sonra .innerHTMListemci tarafında çeşitli yer tutucu öğelerin özniteliğini kullanarak atadığım bir HTML parçasına render . Bu, iki şablon motoruna (bir Java ve bir JavaScript) ihtiyacım olmadığından, teknoloji yığınını olabildiğince basit tutar.

Dezavantajı açıkça ışık hızı gecikme; yarım saniye gecikme kıtalar arasında nadir değildir.

Bugünlerde müşterilerinizin akıllı telefonlar olabileceğini düşünün. Akıllı telefonların pil ömrü sınırlıdır, bu nedenle yoğun hesaplama yapıyorsanız, sunucularınıza boşaltmak daha iyidir. Ancak, istemci tarafında yapıldığında basit şeyler daha enerji tasarruflu olabilir, çünkü o zaman radyo erişiminden kaçınabilirsiniz. Ancak ana argüman olan istikrar, sunucuya basit bir hesaplamayı bile boşaltmanın mantıklı olabileceği anlamına gelebilir.

Bir zeyilname olarak, bazı cevaplarda zaten görüldüğü gibi, güvenlik de kazanırsınız . Uygulama mantığı tamamen istemci tarafındaysa, birileri örneğin online web mağazanızdan satın alacakları şey için bir fiyat belirleyebilir.