İş mantığı gerçekten sunucuya ait mi?

Web uygulaması için tipik bir yığın, bir veritabanı, sunucu tarafı kodu olan bir sunucu ve HTML / CSS / JavaScript tarayıcısı olan bir kullanıcıdır.

Kapsamlı AJAX'tan önce, denetleyicinin sunucu tarafı kodu olduğu MVC rulled. Bir sunucunun Dinamik web sayfaları için yanıt isteklerini yönlendirmesi gerekiyordu (örn. JSP ve ASP gibi şablonlanmış html çözümleri). Sunucu, veritabanına yapılan çağrıları koordine etmek ve sayfa isteğini yanıtlamak için hangi dinamik sayfanın kullanılacağına karar vermek için kullanılır. Tüm bunların sonucu, iş mantığı, sayfaları sunma fikrine güçlü bir şekilde bağlı olmasa da, sunucunun iş mantığını içermesi.

Artık sunucuları "Web 2.0" a taşıdığımız için, kendilerini doldurmak ve sunduklarını değiştirmek için JavaScript kullanan statik sayfalar sunucuları. JavaScript'te olabilir. JavaScript genellikle RESTful hizmeti uygular ve bu da veritabanı sorgusu belirttiği anlamına gelir.

Böylece sunucu, gerçek dosyaları sunma ve AJAX çağrılarını yanıtlama rollerine bırakılır. Ve AJAX çağrılarını cevaplamak sadece oturum yönetimi ve güvenlik sağlamaktır. Ve gerçekten, bir kullanıcının görebilmesi gereken şey, veritabanında belirtilmesi gereken verilerdir.

Yani oradan, sunucu sadece zaman zaman bir e-posta göndermek veya bir web hizmetini kapatmak gibi bir şey yapan aptal bir aracı rolüne düşülmeli mi? İş mantığının tamamı JavaScript'te (gizli olmadığında) veya saklı yordamlarda olduğunda yaşayabilir mi?

Hatta sunucuları ve veritabanlarını birleştirmek veya SAP gibi ERP çözümlerini sunucu olarak kullanmak mantıklı olacak mı?

İş mantığı, güvenlik nedeniyle neredeyse her zaman kontrol ettiğiniz bir sunucuda çalışmalıdır. Eğer "sunucu" ile "web sunucusu" demek istiyorsanız, o zaman katılıyorum, neredeyse herhangi bir iş mantığı olması gerekmez. Ancak, ister bir veritabanı ister bir web sunucusunun içinde olsun, ister ayrı ve web sunucusu tarafından çağrılmış olsun, neredeyse her zaman iş mantığına sahip bir uygulama sunucusuna ihtiyacınız vardır.

Web sunucusunun, uygulama sunucusunun API'sini web hizmetleri veya JSON aracılığıyla göstermekten başka bir şey yapmadığı gerçek dünya uygulamaları vardır.

Web 2.0 ve AJAX'tan önce bile, iş mantığınızı ASP sayfalarıyla karıştırmak için en iyi uygulama olarak görülmüyordu. Bağımsız bir iş mantığına sahip olmak ve sunum mantığının sunucu kısmının ASP, JSP veya başka bir yerde olması daha iyi olarak değerlendirildi. Dolayısıyla web 2.0'daki gerçek değişiklik, sunum katmanının tamamen javascript içinde olabilmesidir. Ben şahsen bunu tercih ederim.

JavaScript genellikle RESTful hizmeti uygular ve bu da veritabanı sorgusu belirttiği anlamına gelir.

Yanlış yaptığınız yer burası. REST CRUD değildir .

REST'in maruz kaldığı kaynaklar veritabanı kayıtlarınız değildir; iş mantığınıza göre davranan tamamen yönetilen nesnelerdir. Sunucu bir POST veya PUT aldığında, yalnızca doğrulamalı ve saklamamalıdır. Uygulama için uygun olan her şeyi gerçekleştirmelidir.

Basit bir örnek: Twitter benzeri bir uygulama, belirli bir kapsayıcıya POST iletileri olarak tweet'ler alır. Sunucu daha sonra bağlamı ("siz kimsiniz?", "Hangi kanal bu?") Ve içeriği ("herhangi bir hashtag?", Metin dizinleri vb.) Analiz eder ve tüm bunları ilgili kuyruklarda depolar. Muhtemelen tüm takipçilerinize doğrudan bir referans ekler.

Bu, kaynağı konteynere eklemenin ötesinde bir çok iş, hepsi de iş mantığınız tarafından tanımlandı. Ve sunucuya aittir.

Bu yaklaşımla ilgili endişelerim tasarımınızın yanlış anlaşılmasından kaynaklanabilir, bu yüzden lütfen beni vurmaktan çekinmeyin.

ancak ürünün ölçeklenebilirliğini, bakımını ve güvenliğini düşünün.

Ürününüz büyük ölçüde büyürse, veritabanı darboğaz haline gelir, bu nedenle "performans" iş mantığını saklı yordamlara koymayı önerirken, veritabanı sunucunuza ek CPU yükü ekleyerek sunucunun maksimum kapasiteye ulaştığı günü öne çıkarır. Web sunucularının aksine, ACID veritabanları paralel donanım kullanarak kolayca ölçeklenemez. Ürününüz asla bu kadar başarılı olmazsa, bu bir sorun değildir.

Farklı tarayıcıların farklı javascriopt, tarayıcıların çoklu sürümleri, vb. Gereksinimlerini karşılayacağı webbrowswers üzerinde çalışan javascript'te iş mantığını koruma düşüncesi ... Neden bu sorunu zaten olduğundan daha karmaşık hale getirelim?

Javiar'ın dediği gibi, ürününüz için bir veritabanı API'si olarak bir REST yaklaşımı kullanmak gerçekten mantıklı değil. Bir REST arayüzünün bir yararı, diğer insanların daha sonra REST arayüzünüzü kullanmanın ve sorgulamanın farklı yollarını düşünmesidir. Ancak bu, genel iş sonrası mantık kaynaklarıdır ve düşük düzey tablo kaydı kaynakları değildir. HTTP api üzerinden bu tür düşük düzeyli veri sorgularını kullanılabilir hale getirme düşüncesi bir güvenlik kabusu gibi geliyor.

Bununla ilgili birçok düşünce okulu olsa da ve kesinlikle hiçbir şekilde evrensel olarak "doğru yol" olarak adlandırılamazken, diğerleri ise evrensel olarak "yanlış yol" iken, sunucu tarafında iş mantığını izole etmenin birkaç nedeni vardır. ve RESTful hizmeti aracılığıyla bu nesnelere ve hizmetlere erişebilirsiniz.

Kısa cevap, çoğunlukla risk yönetimi ve performans izleme ve iyileştirme ile ilgilidir.

Detayda:

1 numaralı sebep güvenliktir. İstemcilere hiçbir zaman sunucuya çöp dışında başka bir şey göndermeleri konusunda güvenilmemelidir ve güvenlik yönlerini sunucu tarafını tutarak, sahte bir kullanıcının sisteminize zarar verme potansiyel riskini izole edersiniz. Unutmayın, Javascript tamamen istemci tarafıdır ve önemsizce değiştirilebilir, bu nedenle ÇIKIŞI GÜVENEMEZSİNİZ.

2 numaralı neden endişelerin ayrılmasıdır. Javascript programlayıcınız güvenlik konusunda uzman olmayabilir ve güvenlik gurunuz Javascript'te o kadar iyi olmayabilir. İş mantığını sunum mantığından ayırarak, javascript'in izin düzeylerinin ötesindeki kaynaklara erişmesine izin verilmeyeceğinden ve işlenmesi Komut Dosyası Programcısının öncülüğünde olan hatalar verileceğinden bu endişeleri aşmaktan kaçınabilirsiniz. Benzer şekilde, Güvenlik görevlisi, güvenliğin nasıl sağlandığını görmek için Javascript'te hata ayıklamayacaktır.

3 numaralı neden performanstır. İş mantığı potansiyel olarak sunucu ve veritabanı kaynaklarını talep edebilir. Bu mantığı kullanıcı arabirimi öğelerinizden yalıtılmış tutarak uygulamanızın yalnızca bu bölümünü ölçeklendirerek darboğazları ele almayı çok daha kolay hale getirebilirsiniz. Ayrıca, iş süreçleri sunucuda yürütülürse, hangi iş sürecinin sisteminizi veya veritabanı arka uçlarınızı yüklediğini izole etmek çok daha kolaydır.

Buradaki bir sonuç, genellikle birkaç iş sürecinin aynı verileri kullanmasıdır ve böylece istemcilere yan kod erişimi vermek mümkün / güvenli olmayabilecek genel sistem yükünü azaltmak için sunucu tarafında önbellekleme uygulayabilirsiniz.

Son olarak, ACID standartlarını korumak için Business Logic'in gerçekten sunucuda olması gerektiğini öneriyorum. Web tarayıcısında çalıştırılan bir faturalandırma ürününü, yalnızca sunucuya veritabanı bağlantısıyla koruduğumu hatırlıyorum. Günlük faturalandırma (iyi bir günde bir saat veya daha fazla sürebilir!) Kesintiye uğradıysa, diyelim ki tarayıcının kapatılması veya kilitlenmesi nedeniyle, veritabanının yaptığı karışıklığı çözmek birkaç saat sürebilir. tutarsız bir durumda. Unutmayın, bu kredi kartlarını da içeriyordu, bu nedenle faturalandırma kayıtlarının da işlemciye karşı kontrol edilmesi gerekiyordu!

Sunucu tarafı iş mantığı, herhangi bir dilin uygulama veya veritabanı düzeyinde işlemlerini sürdürmesi için herhangi bir çerçeve olduğundan ASİT güncellemelerini sağlamak için önemsizdir. Bunu bir web istemcisinin birden fazla güncellemesi ile yapıyorsanız ... bir noktada tutarsız bir durum elde edersiniz ve muhtemelen uygulamanızı etkileyecektir.

RESTful hizmetlerini veritabanına erişmenin bir yolu olarak düşünmek cazip gelse de, felaket için iyi bir tarif olduğu için bu tuzağa düşmemelisiniz. RESTful hizmeti aracılığıyla ortaya koyduğunuz nesne modeli veritabanınızla ilgili olabilir, ancak iş mantığınızı sadece bir CRUD motoru olarak kullanmak yerine gerçekten kapsamalıdır.