Ön uç ve arka uç ayırma arayüzü özellikleri hakkında konuşun
01 Önsöz
İnternetin hızla gelişmesiyle birlikte, ön uç sayfaların görüntülenmesi ve etkileşimli deneyimi gittikçe daha esnek ve göz kamaştırıcı hale geliyor ve yanıt deneyimi için gereksinimler gitgide artıyor. Yüksek eşzamanlılık, yüksek kullanılabilirlik, yüksek performans ve arka uç hizmetlerinin yüksek ölçeklenebilirliği için gereksinimler de Her biri kendi uzmanlık alanlarına odaklanan ön ve arka Ar-Ge'ye yol açan, giderek daha talepkar hale geliyor.
Bununla birlikte, başka bir sorun daha var: ön uç ve arka uç yerleştirme arabirimleri her iki tarafa da çok az dikkat ediyor.Herhangi bir arabirim anlaşması ve şartnamesi olmadan kendi işlerini yapıyorlar.Sonuç olarak, ürün proje geliştirme sürecinde, ön uç ve arka uç arabirim koordinasyonu ve yerleştirme işi hesaba katılıyor Yaklaşık% 30 -% 50, daha da yüksek. Çoğu zaman, ön uç ve arka uç arabirim ortak hata ayıklama ve yerleştirme ve sistemler arasında ortak hata ayıklama ve yerleştirme, tüm ürün projesi geliştirmenin zayıflığıdır.
Bu makalenin asıl amacı, önce standartlaştırmak ve anlaşmak, iletişim ve ortak hata ayıklamadan kaynaklanan gereksiz sorunlardan kaçınmaya çalışmak ve herkesin mutlu bir şekilde uzmanlık alanlarına odaklanmasına izin vermektir.
02 Neden ayrı
İki makaleye bakın:
Şu anda, mevcut ön uç ve arka uç geliştirme modeli: "Arka uç temel dayanak olarak MVC dönemi", aşağıda gösterildiği gibi:
Arka uç tabanlı MVC dönemi
Kodun sürdürülebilirliği önemli ölçüde geliştirildi MVC, geliştiricilerin mimari düzeyde hangi kodun nerede yazılması gerektiğini bilmelerini sağlayan çok iyi bir işbirliği modelidir. Görünüm katmanını daha basit ve daha net hale getirmek için Velocity, Freemaker vb. Şablonlar da seçebilirsiniz, böylece şablonda Java kodu yazılamaz.
Görünüşe göre işlev zayıflamış, ancak ön ve arka arasındaki işbölümünü daha net hale getiren bu kısıtlamadır. Ancak yine de o kadar net değil. Bu aşamadaki tipik sorular şunlardır:
Ön uç geliştirme, büyük ölçüde geliştirme ortamına dayanır ve geliştirme verimliliği düşüktür.
Bu mimari altında, iki ön uç ve arka uç işbirliği modu vardır: biri, ön uçta bir demo yazmak ve yazdıktan sonra, arka uç şablonu ayarlamasına izin vermek. Taobao'nun ilk günlerinde, çok sayıda iş kolu hala bu modeli takip ediyor. Faydaları açıktır Demo yerel olarak geliştirilebilir ve çok etkilidir. Dezavantajı, arka uç şablonunun gerekli olmasıdır ki bu yanlış olabilir Set tamamlandıktan sonra ön uç belirlenmelidir.İletişim ve ileri geri ayarlama maliyeti nispeten yüksektir.
Diğer bir işbirliği modu, tarayıcı tarafının tüm geliştirilmesinden ve sunucu tarafında Görünüm katmanı şablonunun geliştirilmesinden ön ucun sorumlu olmasıdır. Alipay bu moddur. Bunun avantajı, kullanıcı arayüzü ile ilgili kodun ön uçta yazılması ve arka uca çok fazla dikkat edilmesine gerek olmamasıdır.Dezavantaj, ön uç geliştirmenin büyük ölçüde arka uç ortama bağlı olması ve ortamın ön uç geliştirmenin verimliliğini etkileyen önemli bir faktör haline gelmesidir.
Ön ve arka sorumluluklar hala karışık.
Hız şablonları hala oldukça güçlü.Değişkenler, mantık, makrolar ve diğer özellikler, aldıkları bağlam değişkenleri aracılığıyla çeşitli iş mantığını uygulamaya devam edebilir. Bu şekilde, ön uç zayıf olduğu sürece, arka uç genellikle şablon katmanına çok sayıda iş kodu yazmalıdır. Denetleyicide ayrıca büyük bir gri alan vardır, sayfa yönlendirme ve diğer işlevler en çok ilgili ön uç olmalıdır, ancak arka uç tarafından uygulanır. Denetleyicinin kendisi ve Model genellikle birbirine dolanır ve insanların dişlerini gıcırdatmasına neden olan iş kodu genellikle Denetleyici katmanında görünür. Bu sorunların tümü programcının kalitesine atfedilemez, aksi takdirde JSP yeterli olacaktır.
Ön uçtaki sınırlamalar.
Performans optimizasyonu yalnızca ön uçta yapılırsa, alan çok sınırlıdır, bu nedenle kıvılcımlarla çarpışmak için genellikle arka uç işbirliğine ihtiyaç duyarız.Ancak, arka uç çerçevesinin sınırlamaları nedeniyle, performansı optimize etmek için Comet, Bigpipe ve diğer teknik çözümleri kullanmak bizim için zor.
Özetle, kod yeniden düzenlemenin neden gerekli olduğu ile aynıdır:
- Endişelerin ayrılması
- Görevlerin ayrılığı
- Doğru insanlar doğru şeyleri yapar
- Daha iyi bir ortak yapım modeli
- Değişikliklere hızlı yanıt
03 Ayrılık nedir
Ön ve arka ayrımın ilk aşamasını şimdi yapacağız: Şekilde gösterildiği gibi "Ajax'ın getirdiği SPA dönemine dayanarak":
Ajax'ın getirdiği SPA dönemine dayanıyor
Bu modda, ön ve arka uçlar arasındaki iş bölümü çok nettir ve ön ve arka uçlar arasındaki temel işbirliği noktası Ajax arayüzüdür. Çok harika görünüyor, ancak geriye dönüp bakarsanız, JSP döneminden çok da farklı değil. Karmaşıklık sunucu tarafındaki JSP'den tarayıcıdaki JavaScript'e taşındı ve tarayıcı tarafı çok karmaşık hale geldi. Spring MVC'ye benzer şekilde, tarayıcı tarafında katmanlı bir mimari bu çağda ortaya çıkmaya başladı:
Tarayıcı tarafında katmanlı mimari
Bu SPA aşaması için, ön ve arka uçları ayırmanın birkaç önemli zorluğu vardır:
Ön ve arka arayüzler için kurallar.
Arka uç arabirimi karmaşa içindeyse, arka uç iş modeli yeterince kararlı değilse, ön uç geliştirme sancılı olacaktır. Bu alanda, endüstride arayüzleri kabul etmek ve hızlandırmak için API Blueprint gibi çözümler var. == Alibaba'da, birçok takım da arayüz kuralları, arayüz platformları vb. Yoluyla bunu yapmak için benzer girişimlerde bulunuyor. Arka uç ile çökeltilen arayüz kuralları ile, verileri simüle etmek için de kullanılabilir, böylece ön uç ve arka uç, arabirim üzerinde anlaştıktan sonra verimli paralel geliştirme elde edebilir. == Bunun daha iyi ve daha iyi olacağına inanıyorum.
Ön uç geliştirmenin karmaşıklık kontrolü.
SPA uygulamaları çoğunlukla işlevsel olarak etkileşimlidir ve JavaScript kodlarının 100.000 satırı aşması normaldir. Büyük miktarda JS kodunun düzenlenmesi, Görünüm katmanıyla bağlanma vb. Kolay görevler değildir. Tipik çözüm, endüstrinin Omurgasıdır, ancak Backbone, yaptığı işte hala sınırlıdır ve hala meydan okunması gereken çok sayıda boş alan vardır.
04 Ayırma nasıl yapılır
4.1 Görevlerin Ayrılması
Görevlerin ayrılığı
- Ön ve arka uçlar yalnızca eşzamansız arabirimler (AJAX / JSONP) aracılığıyla programlanır
- Hem ön hem de arka uçların kendi geliştirme süreçleri, derleme araçları ve test koleksiyonları vardır
- Endişelerin ayrılması, ön ve arka uçlar nispeten bağımsız hale gelir ve gevşek bir şekilde birleşir
4.2 Geliştirme Süreci
- Arka uç yazma ve arabirim belgelerini koruma ve API değiştiğinde arabirim belgelerini güncelleme
- Arka uç, arayüzü arayüz belgesine göre geliştirir
- Ön uç, arayüz belgesi + Mock platformuna göre geliştirilmiştir
- Geliştirme tamamlandıktan sonra, ortak hata ayıklama ve test için gönderme
Mock sunucusu, arayüz belgesine göre Sahte verileri otomatik olarak oluşturur ve arayüz belgesini veya API'yi gerçekleştirir:
Gelişme süreci
4.3 Özel uygulama
Şimdi temelde tamamlandı, arayüzün uygulanması:
- Arayüz belge sunucusu: Arayüz değişikliklerinin gerçek zamanlı senkronizasyonu ön uçta görüntülenebilir;
- Sahte arayüz veri platformu: Ön uç kullanım için arayüz değişikliği gerçek zamanlı Mock verilerini gerçekleştirebilir;
- Arayüz spesifikasyon tanımı: çok önemli, arayüz tanımının kalitesi doğrudan ön ucun iş yükünü ve uygulama mantığını etkiler; spesifik tanım spesifikasyonları için sonraki bölüme bakın;
Arayüz belgesi + Mock platform sunucusu
05 Arayüz Spesifikasyonu V1.0.0
5.1 Normatif ilkeler
- Arayüz tarafından döndürülen veriler görüntülenir: ön uç yalnızca oluşturma mantığı işlemesini gerçekleştirir;
- Oluşturma mantığı, birden çok arabirim üzerinden aramayı yasaklar;
- Ön uç, etkileşim ve işleme mantığına odaklanır ve iş mantığı işlemenin ortaya çıkmasını önlemeye çalışır;
- Yanıt aktarım veri formatı talep etme: JSON, JSON verileri, çok seviyeli JSON görünümünden kaçınmak için olabildiğince basit ve hafif olmalıdır;
5.2 Temel format
5.2.1 Temel istek biçimiGET isteği, POST isteği == anahtarlı giriş parametresini gövde olarak içermelidir, tüm istek verileri JSON biçiminde paketlenir ve gövde == girdi parametresinde saklanır, örnekler aşağıdaki gibidir:
GET isteği:
xxx / login? body = {"kullanıcı adı": "admin", "şifre": "123456", "captcha": "scfd", "RememberMe": 1}POST isteği:
kod: istek işleme durumu
- 200: İstek başarıyla işlendi
- 500: İsteğin işlenmesi başarısız oldu
- 401: İsteğin kimliği doğrulanmadı, giriş sayfasına atlayın
- 406: Yetkisiz isteyin, yetkisiz bilgi istemi sayfasına gidin
data.message: istek işleme mesajı
- code = 200 ve data.message = "success": İstek başarıyla işlendi
- code = 200 ve data.message! = "success": İstek başarıyla işlendi, genel mesaj istemi: mesaj içeriği
- code = 500: İstek işlenemedi, uyarı mesajı istemi: mesaj içeriği
5.3 Yanıt varlık biçimi
{ kod: 200, veri: { mesaj: "başarılı", varlık: { id: 1, ad: "XXX", kod: "XXX" } } }data.entity: Yanıt olarak döndürülen varlık verileri
5.4 Yanıt listesi biçimi
data.list: Yanıt olarak döndürülen verileri listeleyin
5.5 Yanıt sayfası biçimi
{ kod: 200, veri: { recordCount: 2, mesaj: "başarılı", totalCount: 2, sayfa No: 1, pageSize: 10, liste: , toplam Sayfa: 1 } }- data.recordCount: geçerli sayfa kayıt sayısı
- data.totalCount: toplam kayıt sayısı
- data.pageNo: mevcut sayfa numarası
- data.pageSize: sayfa boyutu
- data.totalPage: toplam sayfa sayısı
5.6 Özel içerik özellikleri
5.6.1 Açılır kutu, onay kutusu, radyo düğmesiArka uç arayüzünün birleşik mantığı, seçilip seçilmediğini belirler ve seçilip seçilmediğini işaretlemek için isSelect kullanılır. Bir örnek aşağıdaki gibidir:
{ kod: 200, veri: { mesaj: "başarılı", liste: } }Ön uç tarafından işlenecek seçim mantığını belirlemek için yasak açılan kutuları, onay kutuları ve radyo kutuları ve arka uç mantığı seçimi belirler ve ön uç ekrana geri döner;
5.6.2 Boole türüBoolean türü ile ilgili olarak, JSON veri iletiminde 1/0, 1 evet / Doğru ve 0, hayır / Yanlış;
5.6.3 Tarih TipiTarih türleri ile ilgili olarak, dizeler her zaman JSON veri aktarımında kullanılır ve belirli tarih biçimi işletmeye bağlıdır;
06 Geleceğin büyük ön ucu
Şu anda kullandığımız ön uç ve arka uç ayırma modu ilk aşamaya aittir. Jquery gibi bazı teknolojilerin kullanılması nedeniyle, bazı sayfa gösterimi ve veri oluşturma hala nispeten karmaşıktır ve yeniden kullanılamaz. Ön uç için hala çok iş var.
Bir sonraki aşama, ön uç mühendislik, teknik çerçeve seçimi ve ön uç modüler yeniden kullanım açısından olabilir. Bu, "== ön uç tabanlı MV * dönemi ==" başlatmak içindir. Çoğu şirket temelde bu ayrılma aşamasındadır.
Son aşama, == Node'un getirdiği tam yığın dönemidir. Sayfaları, URL'leri, Denetleyicileri, yönlendirmeyi vb. Kontrol etmek için bir ön uç vardır ve arka uç uygulamaları yavaş yavaş gerçek veri hizmetleri + iş hizmetlerine dönüştürülür. Ne yapabilirsiniz? Veri sağlamak, iş mantığını işlemek ve yüksek kullanılabilirlik ve yüksek eşzamanlılığa odaklanmaktır.
Bu iki aşama sadece kısaca tanıtılır İlgilenenler aşağıdaki bilgilere başvurabilirler.
