it-swarm-tr.com

"Ayrılmış" web uygulamalarının avantajları / dezavantajları

(Yakında) oldukça büyük bir PHP/MySQL web uygulaması tasarlama sürecindeyim. İç mimari kadar yoldaki bir çatala geldim; Web sitesini "geleneksel" bir web uygulaması olarak oluşturabilirim, istek yaptığınızda, sunucu size bir HTML sayfası oluşturur, size tüm sayfayı gönderir ve tarayıcı bunu oluşturur veya "ayrılmış olarak oluştururum" "HTML kodunun tamamı ve uygulamanın kodunun tarayıcıya ilk yüklenme sırasında sağlandığı ve uygulama, belirli bir veri almak veya birleşik bir API üzerinden komutlar vermek için JavaScript geri aramalarını kullanan web uygulaması. Ayrıca, sitenin birden fazla versiyonunun (masaüstü, mobil, iPhone/Android mobil, arama motoru dostu vb.) Ve bir noktada, belki de bağımsız mobil veya masaüstü uygulamalarının olmasını istiyorum.

Bu geliştiricilerin her biriyle web geliştiricileri olarak karşılaştığınız avantajlar/dezavantajlar nelerdir? Birbiri ardına gitmem için net bir neden var mı? Geliştiricilerin tercih ettiği bir şey mi?

3
Adam Maras

Öncelikle, Asenkron bir web sitesine girip girmemeniz veya iPhone/Mobil ve masaüstü uygulamaları oluşturma yeteneğiniz üzerinde fazla bir etkisi olmaz, çünkü onlarla hiçbir ilgisi yoktur. Her iki durumda da kodunuzu tekrar kullanamazsınız.

Ayrıca, Asenkron siteler normal sitelerden daha yavaş veya daha yavaş olabilirler. Genellikle, bu tür işlevsellik bir nedenle, özellikle zenginleştirilmiş kullanıcı deneyimi için eklenir. JavaScript'i kullanmak, SEO'da size zarar verme eğilimindedir; çünkü web tarayıcıları, JavaScript'in amacını tam olarak anlayamaz ve bu nedenle çoğunlukla dikkate almaz.

Aradığınızı, yalnızca işlevsel (orta) seviyenizi bir kez yazarak ve uygulamalarınızın tümü için aynı olanı kullanarak, genel giderlerinizi azaltmanın bir yolu olduğunu düşünüyorum. Bu durumda değer olduğunu düşünüyorum ama açıkçası bu tür mimarileri kurmak ve çok zaman almak zor. Web sitenizi en iyi şekilde geliştirmeniz ve orta seviye kodunuzu olabildiğince güçlü tutmanız gerektiği görüşündeyim. Bu şekilde bir iPhone uygulaması ekleme zamanı geldiğinde veya ortak bir orta seviye olan bir modele daha kolay bir şekilde geçebileceksiniz.

Burada savunduğum tek şey bebek adımlarını atmak. Henüz bilmediğiniz şeyleri işlemek için şimdi kod yazmaya çalışmayın. Sadece ihtiyacınız olan kodu yazın ve mümkün olduğunca esnek hale getirin.

4
Ben Hoffman

Bence JavaScript/AJAX'a büyük ölçüde dayanan "ayrık" bir uygulama fikri sizi başın büyük belaya sokacak. Başımın üstünden birkaç şey:

  1. Google bir şeyleri indekslemekte zorlanacağı için SEO için kötü olacak.
  2. "Yer işareti" haline getirmek zor olacak
  3. Birçoğu çok sınırlı (veya bozuk) javascript desteğine sahip olduğundan, mobil cihazlarda zorlanacaksınız.
5
Eric Petroelje

İlk olarak, eğer bu cevap çok açık ya da basit ise, alınma. Ajax veya jQuery gibi terimler yerine "ayrı" kullanımı, bu konuda daha az deneyim sahibi olmamı sağlıyor. Tabii ki soruyu yanlış okuyor olabilirim, öyleyse özür dilerim.

Her ikisini de kullanın, ancak akıllıca

Bir görevin en verimli biçimde nerede ve nasıl yapıldığını belirleyerek sunucu veya müşteri tarafı görevler seçiminizi düşünün. Bu, sayfaları hızlı bir şekilde (sunucuda) oluşturmanıza yardımcı olur, ancak işi yapmak için anlamlı olduğu tarayıcıya boşaltma yapar. Ve sadece bir karar vermeniz gereken gri alanlar olacak. İşiniz akıllı bir iş bölümü bulmaktır.

Sunucu tarafında ne var?

(Bu, noktayı göstermek için aşırı bir örnektir.) Bir tür arama yapan bir web uygulaması yazdığınızı söyleyin. Tarayıcı tarafı Javascript'i bir sunucu tarafı çağırmak için yazmazsınız PHP web servisi "sunucunuzu boşaltmak" için 2GB veri tabanının tamamını almak ve kullanıcının makinesini boşaltmak için kullanılır. Yaptığınız şey, kullanıcı tarafından bir formla arama terimlerini almaktır, POST veritabanını doğrudan sorgulamak için sunucuya geri döndürür, ardından sonuçları sunucudan tarayıcıya geri gönderir.

Buradaki mantık, DB'nin sorguyu en iyi nasıl yapacağını bilmesi, sunucunun kaynak verilere daha yakın olması ve bileşenler arasında daha az veri taşınması gerektiğidir. Tarayıcı sadece gösterdiği şeylere ihtiyaç duyar, bu yüzden hepsini tarayıcıya göndermeyin. (Göreceli dil performansından bahsetmiyorum.)

Tarayıcıya ne ait?

Tarayıcı tarafı kodu "ayrı" senaryonuzdur (doğru anlıyorsam). Ancak tarayıcının akıllıca bir şey yapması için sunucu işbirliğine sahip olması gerekir.

Tamam, arama uygulamanızı çalışıyor ancak biraz şık pantolon Ajax ile süslemek istiyorsunuz. Birkaç harf almak ve eşleşen arama terimlerini döndürmek için PHP web hizmeti yazın, a la Bing, Google'ın "arama önerisi" özelliğini yazın. Tarayıcı kodunuz, yalnızca kullanıcının üç veya dört harften sonra yazdığı terimleri önerecek şekildedir, bu nedenle öneri listeniz küçüktür. Sunucuya geri döndüğünüzde, veritabanınızı o alana indeksleyin, böylece arama hızlı hızlı olacaktır.

Buradaki düşünce, "arama önerisi" nin sunucu ile istemci arasında bölünmesi gereken bir özellik olduğudur. Tarayıcı hızlı bir şekilde hedeflenen küçük veri yığınlarıyla ilgilenebilir. Sunucu bu küçük ve hedef veri yığınını alabilir ve müşteriye verebilir. Zayıf bir bölme, sunucunun HTML sayfasına gömülü bir XML adası olarak olası alan değerlerini (örneğin, 500.000 öğe) bir canavar listesi oluşturması ve ardından kullanıcının yazdığı gibi tarayıcı araması yapması olabilir. (a) tüm bu verileri tarayıcıya göndermek yavaştır, (b) Javascript'te arama yapmak asla DB'nin aramasına izin vermek kadar hızlı olmayacaktır ve (c) siz ' Tüm bu verileri tarayıcı uygulama alanlarına tıkayarak bir kullanıcının makinesini havaya uçurabilir. Öte yandan, Ajax'ın sunucuya çağrı yaptığından ve sonraki sorgu ve geri dönüşün süper hızlı olduğundan emin olmanız gerekir . Etrafta dilimlenmiş dally yok.

Gri alan nerde?

İşte yine bir yargılama çağrısı. Yukarıda, aramayı yapan sunucu hakkında konuştum, ardından sonuçları tarayıcıya gönderdim. Ancak, soru ortaya çıkıyor, tarayıcının formla birlikte arama terimlerini göndermesine izin veriyor musunuz ve sunucunun sonuç sayfasını oluşturmasını mı sağlıyorsunuz, yoksa arama terimlerini göndermek ve sonuçları almak için istemci tarafı Ajax/Javascript kullanıyor musunuz? sayfanın yenilenmesini önlemek için DIV’de Her ikisi de geçerlidir. Kaynak bilge, hiçbir şekilde gerçek bir faydası yok. Ajax yolu daha iyi bir kullanıcı deneyimi sağlayabilir, ancak uygulamanıza ve koşullara bağlı olarak başka zorluklar da (ör. Güvenlik) sunabilir.

Alt çizgi

Her ikisini de uygun şekilde kullanın. Mimari performans ve verimlilik hakkında düşünme ve öğrenmeye yatkın olma. Daha az veri taşıyın, daha az sayıda. Sunucularınızı, veritabanlarınızı ve kullanıcılarınızın tarayıcılarını yükleyeceksiniz.

2
b w

Kodu tekrar kullanabilmek için, açılış sayfalarının oluşturulması için XSLT'ye her zaman bakabilir ve daha sonra AJAX (XSLT açılış sayfaları için XML arayüzünü kullanarak) için XML/JSON arayüzlerine sahip olabilirsiniz.

İçeriğin ve etkileşimin,/json/... ve/xml/... ön ekiyle RESTful bir arabirimde çalışmasına izin verirsiniz ve ana içeriğinizi XSLT üzerinden/...

Bu yolla insanlar herhangi bir sayfaya inebilir ve birden bire AJAX web sitesine sahip olabilir. Örümcekler sitenizi tarayabilir ve her şeyden önce içerik/arayüzlere odaklandınız - kazan/kazan gibi görünüyor.

Mobil web siteleri bazen farklı düzenlere ihtiyaç duyarlar (özel olarak iPhone yalnızca herkes sitelere?) Burada basit bir XSLT dönüşümü veya farklı kullanıcı müşterileri için şimdiye kadar yaptığınız her şeyi tekrar kullanabilirsiniz.

Basit HTML çıktısı ve gezinti için tasarım yapmayı unutmayın, AJAX basitleştirmeler takip edebilir.

PS - XSLT dönüşümlerini sunucu tarafında yapın

1
Metalshark