Kata pengantar
Untuk menyelesaikan berbagai masalah yang dibawa oleh model pengembangan web tradisional, kami telah melakukan banyak upaya, tetapi karena kesenjangan fisik antara ujung depan dan belakang, solusi yang kami coba serupa. Belajar dari rasa sakit, hari ini kami memikirkan kembali definisi "ujung depan dan belakang" dan memperkenalkan nodeJs, yang akrab bagi siswa front-end, mencoba menjelajahi mode pemisahan front-end baru.
Dengan munculnya terminal yang berbeda (PAD/Mobile/PC), pengembang memiliki persyaratan yang semakin tinggi. Responsif dari sisi browser murni tidak lagi dapat memenuhi persyaratan tinggi dari pengalaman pengguna. Kita sering perlu mengembangkan versi khusus untuk terminal yang berbeda. Untuk meningkatkan efisiensi pengembangan, kebutuhan untuk pemisahan ujung depan dan belakang semakin dinilai. Ujung belakang bertanggung jawab untuk antarmuka bisnis/data, ujung depan bertanggung jawab untuk logika tampilan/interaksi, dan kami dapat menyesuaikan dan mengembangkan beberapa versi antarmuka data yang sama.
Topik ini telah banyak dibahas baru -baru ini, dan beberapa bus Alibaba juga melakukan beberapa upaya. Setelah diskusi yang panjang, tim kami memutuskan untuk mengeksplorasi satu set skema pemisahan front-end dan back-end berdasarkan nodeJS. Ada beberapa pemahaman dan pemikiran yang berubah dalam prosesnya. Saya merekamnya di sini. Saya juga berharap bahwa siswa yang saya lihat berpartisipasi dalam diskusi dan membantu kami memperbaikinya.
1. Apa pemisahan front-end?
Selama diskusi awal dalam kelompok, saya menemukan bahwa setiap orang memiliki pemahaman yang berbeda tentang pemisahan front-end. Untuk memastikan bahwa mereka dapat mendiskusikan di saluran yang sama, pertama-tama kami akan mencapai kesepakatan tentang apa "pemisahan front-back-end" itu.
Contoh pemisahan front-end yang disetujui semua orang adalah spa (aplikasi satu halaman). Semua data presentasi yang digunakan disediakan oleh backend melalui antarmuka asinkron (AJAX/JSONP), dan front-end hanya menampilkannya.
Dalam arti tertentu, spa mencapai pemisahan front-end, tetapi ada dua masalah dengan metode ini:
Di antara layanan web, SPA menyumbang proporsi yang sangat kecil. Dalam banyak skenario, ada juga mode hibrida sinkron/sinkron + asinkron, dan SPA tidak dapat digunakan sebagai solusi umum.
Dalam model pengembangan SPA saat ini, antarmuka biasanya disediakan sesuai dengan logika presentasi. Kadang -kadang, untuk meningkatkan efisiensi, backend akan membantu kita menangani beberapa logika presentasi, yang berarti bahwa backend masih terlibat dalam pekerjaan lapisan tampilan, bukan pemisahan nyata dari depan dan backend.
Pemisahan front-end gaya spa dibedakan dari lapisan fisik (pikirkan bahwa selama klien, front-end, dan ujung belakang adalah server). Klasifikasi ini tidak dapat lagi memenuhi kebutuhan kita untuk pemisahan front-end. Kami percaya bahwa hanya dengan membagi tanggung jawab kami dapat memenuhi skenario penggunaan kami saat ini:
Front-end: Bertanggung jawab atas lapisan tampilan dan pengontrol.
Backend: Hanya bertanggung jawab untuk lapisan model, pemrosesan bisnis/data, dll.
Mengapa pembagian tanggung jawab ini akan dibahas nanti.
2. Mengapa kita harus memisahkan ujung depan dan belakang?
Mengenai masalah ini, artikel Yu Bo menjelaskannya dengan sangat komprehensif dalam evolusi model R&D Web. Mari kita tinjau secara singkat:
2.1 Skenario yang berlaku untuk model pengembangan yang ada
Model pengembangan yang disebutkan oleh Yu Bo masing -masing memiliki skenario mereka sendiri yang berlaku, dan tidak ada yang sepenuhnya menggantikan yang lain.
Misalnya, untuk MVC, yang terutama didasarkan pada backend, sangat efisien untuk melakukan beberapa bisnis tampilan yang sinkron, tetapi ketika menemukan halaman yang sinkron dan asinkron, akan lebih merepotkan untuk berkomunikasi dengan pengembangan backend.
Ajax adalah model pengembangan spa utama, yang lebih cocok untuk mengembangkan skenario tipe aplikasi, tetapi hanya cocok untuk membuat aplikasi, karena SEO dan masalah lainnya sulit dipecahkan. Untuk banyak jenis sistem, metode pengembangan ini juga terlalu berat.
2.2 Tanggung jawab ujung depan dan belakang tidak jelas
Dalam sistem dengan logika bisnis yang kompleks, kami paling takut mempertahankan kode yang dicampur dengan ujung depan dan belakang. Karena tidak ada kendala, kode lapisan MVC lainnya dapat muncul di setiap lapisan. Seiring waktu, tidak ada perawatan sama sekali.
Meskipun pemisahan ujung depan dan belakang tidak dapat sepenuhnya menyelesaikan masalah ini, itu dapat sangat diringankan. Karena dijamin dari tingkat fisik yang tidak dapat Anda lakukan ini.
2.3 Masalah Efisiensi Pengembangan
Web Taobao pada dasarnya didasarkan pada WebX kerangka kerja MVC, dan arsitektur menentukan bahwa front-end hanya dapat mengandalkan back-end.
Jadi model pengembangan kami masih bahwa front-end menulis demo statis dan back-end menerjemahkannya ke dalam templat VM. Saya tidak akan membicarakan masalah dengan model ini, dan saya telah dikritik sejak lama.
Juga menyakitkan untuk dikembangkan secara langsung berdasarkan lingkungan back-end, dan merepotkan untuk mengonfigurasi, menginstal, dan menggunakan. Untuk menyelesaikan masalah ini, kami menemukan berbagai alat, seperti Vmarket, tetapi front-end masih harus menulis VM, dan mengandalkan data back-end, sehingga efisiensinya masih belum tinggi.
Selain itu, backend tidak dapat menghilangkan fokus yang kuat pada tampilan dan dengan demikian fokus pada pengembangan lapisan logika bisnis.
2.4 Keterbatasan kinerja front-end
Jika optimasi kinerja hanya dilakukan di ujung depan, kita sering membutuhkan kerja sama backend untuk menciptakan percikan api. Namun, karena keterbatasan kerangka backend, sulit bagi kita untuk menggunakan Comet, bigpipe, dan solusi teknis lainnya untuk mengoptimalkan kinerja.
Untuk menyelesaikan beberapa masalah yang disebutkan di atas, kami telah melakukan banyak upaya dan mengembangkan berbagai alat, tetapi tidak pernah ada banyak peningkatan, terutama karena kami hanya dapat menggunakan ruang kecil yang dibagi oleh kami di backend. Hanya dengan benar -benar memisahkan ujung depan dan belakang kita dapat sepenuhnya menyelesaikan masalah di atas.
3. Bagaimana cara memisahkan ujung depan dan belakang?
Bagaimana cara memisahkan ujung depan dan belakang? Bahkan, ada jawaban di bagian pertama:
Front-end: Bertanggung jawab atas lapisan tampilan dan pengontrol.
Backend: Bertanggung jawab untuk lapisan model, pemrosesan bisnis/data, dll.
Bayangkan saja, jika para pengontrol front-end menguasai, kita dapat melakukan desain URL, kita dapat memutuskan apakah akan menyinkronkan rendering di server sesuai dengan adegan, atau mengeluarkan data JSON berdasarkan data lapisan tampilan, dan kita juga dapat dengan mudah melakukan bigpipe, comet, soket, dll. Menurut kebutuhan lapisan presentasi. Ini sepenuhnya merupakan metode penggunaan yang ditentukan oleh persyaratan.
3.1 Pengembangan "tumpukan penuh" berdasarkan nodeJS
Jika Anda ingin menerapkan pelapisan angka di atas, Anda pasti akan membutuhkan layanan web untuk membantu kami menyadari apa yang kami lakukan sebelum dan sesudah backend, jadi ada judul "Pengembangan Full-Stack Berdasarkan NodeJS"
Gambar ini terlihat sederhana dan mudah dimengerti, tetapi belum mencobanya dan akan ada banyak pertanyaan.
Dalam mode spa, backend telah menyediakan antarmuka data yang diperlukan, dan frontend tampilan sudah dapat dikontrol. Mengapa menambahkan lapisan nodeJS?
Bagaimana dengan menambahkan satu lapisan lagi?
Menambahkan satu lapisan lagi akan meningkatkan beban kerja front-end?
Menambahkan satu lapisan lagi akan menyebabkan lapisan risiko lain. Bagaimana cara memecahkannya?
NodeJs dapat melakukan apa saja, mengapa Anda masih membutuhkan java?
Tidak mudah untuk menjelaskan masalah ini dengan jelas. Izinkan saya berbicara tentang proses pemahaman saya di bawah ini.
3.2 Mengapa menambahkan lapisan nodej?
Pada tahap ini, kami terutama mengembangkan model MVC backend. Model ini benar-benar menghambat efisiensi pengembangan front-end dan mencegah back-end dari fokus pada pengembangan bisnis.
Solusinya adalah memungkinkan front-end untuk mengontrol lapisan pengontrol, tetapi sulit untuk melakukannya di bawah sistem teknologi yang ada, karena tidak mungkin untuk membiarkan semua ujung depan belajar Java, memasang lingkungan pengembangan back-end, dan menulis VM.
NodeJs dapat menyelesaikan masalah ini dengan sangat baik. Kita dapat melakukan apa yang dibantu oleh perkembangannya sebelumnya, dan semuanya tampak sangat alami.
3.3 Masalah Kinerja
Layering melibatkan komunikasi antara setiap lapisan, dan pasti akan ada kerugian kinerja tertentu. Namun, stratifikasi yang masuk akal dapat membuat tanggung jawab menjadi jelas dan kolaboratif, yang akan sangat meningkatkan efisiensi pengembangan. Kerugian yang disebabkan oleh stratifikasi pasti akan dikompensasi dalam aspek lain.
Selain itu, begitu kami memutuskan untuk mengikat, kami dapat meminimalkan kerugian dengan mengoptimalkan metode komunikasi dan protokol komunikasi.
Misalnya:
Setelah halaman Detail Bayi Taobao statis, masih ada banyak informasi yang perlu diperoleh secara real time, seperti logistik, promosi, dll. Karena informasi ini ada dalam sistem bisnis yang berbeda, front-end perlu mengirim 5 atau 6 permintaan asinkron untuk mengisi ulang konten ini.
Dengan nodeJs, front-end dapat proksi 5 permintaan asinkron ini di nodeJs, dan dapat dengan mudah melakukan bigpipe. Optimalisasi ini dapat meningkatkan seluruh efisiensi rendering.
Anda mungkin berpikir tidak apa -apa untuk mengirim 5 atau 6 permintaan asinkron pada PC, tetapi di sisi nirkabel, sangat mahal untuk membuat permintaan HTTP di ponsel pelanggan. Dengan optimasi ini, kinerjanya beberapa kali ditingkatkan.
Detail Taobao didasarkan pada optimasi nodeJS. Kami sedang dalam proses. Setelah diluncurkan, saya akan berbagi proses optimasi.
3.4 Apakah beban kerja front-end meningkat?
Dibandingkan dengan hanya memotong halaman/demo, itu harus sedikit lebih, tetapi ada keterkaitan dan komunikasi dalam mode saat ini. Proses ini membutuhkan banyak waktu, rentan terhadap bug, dan sulit dipertahankan.
Oleh karena itu, meskipun beban kerja akan meningkat sedikit, efisiensi pengembangan secara keseluruhan akan sangat ditingkatkan.
Selain itu, biaya pengujian dapat dihemat banyak. Antarmuka yang dikembangkan di masa lalu semuanya ditujukan untuk lapisan presentasi, dan sulit untuk menulis kasus uji. Jika pemisahan bagian depan dan belakang dilakukan, bahkan tes dapat dipisahkan. Satu kelompok orang berspesialisasi dalam menguji antarmuka dan kelompok orang lainnya berfokus pada pengujian UI (bagian pekerjaan ini bahkan dapat digantikan oleh alat).
3.5 Bagaimana cara mengontrol risiko yang dibawa dengan menambahkan lapisan simpul?
Dengan penggunaan node skala besar, siswa dari departemen sistem/operasi dan pemeliharaan/keamanan pasti akan bergabung dengan konstruksi infrastruktur. Mereka akan membantu kami meningkatkan kemungkinan masalah di setiap tautan dan memastikan stabilitas departemen.
3.6 Node dapat melakukan apa saja, mengapa Anda masih membutuhkan java?
Niat asli kami adalah memisahkan ujung depan dan belakang. Jika kami mempertimbangkan masalah ini, itu akan sedikit bertentangan dengan niat asli kami. Bahkan jika kami menggunakan Node untuk menggantikan Java, kami tidak dapat menjamin bahwa kami tidak akan menghadapi masalah yang kami hadapi hari ini, seperti tanggung jawab yang tidak jelas. Tujuan kami adalah berkembang secara berlapis, orang -orang profesional, dan fokus melakukan hal -hal profesional. Infrastruktur berdasarkan Java sudah sangat kuat dan stabil, dan lebih cocok untuk melakukan apa yang sekarang menjadi arsitektur.
4. Pemisahan front-end berbasis node Taobao
Gambaran di atas adalah apa yang saya pahami di pemisahan dan pelapis dan pelapis front-end Taobao berdasarkan node, serta ruang lingkup tanggung jawab node. Penjelasan singkat:
Ujung atas adalah server, yang sering kita sebut backend. Bagi kami, backend adalah kumpulan antarmuka, dan server menyediakan berbagai antarmuka untuk kami gunakan. Karena ada lapisan simpul, tidak perlu membatasi bentuk layanan apa itu. Untuk pengembangan backend, mereka hanya menggunakan antarmuka yang peduli dengan kode bisnis.
Server berada di bawah aplikasi Node.
Ada lapisan proxy model dalam aplikasi node yang berkomunikasi dengan server. Lapisan ini terutama digunakan untuk menghaluskan cara kita menyebut antarmuka yang berbeda dan merangkum beberapa model yang dibutuhkan oleh lapisan tampilan.
Lapisan simpul juga dapat dengan mudah mencapai VMCommon asli, TMS (mengutip sistem manajemen konten Taobao) dan persyaratan lainnya.
Kerangka kerja apa yang akan digunakan untuk lapisan simpul terserah pengembang untuk memutuskan. Namun, disarankan untuk menggunakan kombinasi ekspres + xtemplate, yang dapat digunakan untuk ujung depan dan belakang.
Semua orang memutuskan cara menggunakan Node, tetapi yang menarik adalah bahwa kita akhirnya dapat menggunakan Node untuk dengan mudah mengimplementasikan metode output yang kita inginkan: JSON/JSONP/RESTFUL/HTML/BIBPIPE/COMET/SOCKET/SYNCHRONOUS DAN ASINCYCHRONOUS. Ini dapat dilakukan apa pun yang Anda inginkan, dan diputuskan sepenuhnya berdasarkan skenario Anda.
Lapisan browser tidak berubah dalam arsitektur kami, dan kami tidak ingin mengubah pemahaman Anda sebelumnya tentang pengembangan di browser karena pengenalan node.
Memperkenalkan Node hanya untuk menyerahkan bagian kontrol front-end yang harus dikendalikan oleh front-end.
Kami memiliki dua proyek dalam pengembangan dalam model ini. Meskipun mereka belum diluncurkan, kami telah merasakan rasa manis dalam hal efisiensi pengembangan dan optimasi kinerja.
5. Apa lagi yang perlu kita lakukan?
Mengintegrasikan proses pengembangan Node ke dalam proses SCM Taobao yang ada.
Konstruksi infrastruktur, seperti sesi, logger dan modul umum lainnya.
Praktik pembangunan terbaik
Kisah Sukses Online
Pemahaman semua orang tentang konsep pemisahan ujung dan belakang simpul
Keamanan
pertunjukan
...
Tidak akan ada terlalu banyak teknologi yang membutuhkan inovasi dan penelitian, dan ada banyak akumulasi siap pakai. Faktanya, kuncinya adalah pembukaan beberapa proses dan akumulasi solusi umum. Saya percaya bahwa dengan lebih banyak praktik proyek, area ini secara bertahap akan menjadi proses yang stabil.
6. "Pulau Midway"
Meskipun model pengembangan "full-stack berdasarkan nodejs" menarik, masih banyak yang harus dilakukan untuk mengubah pengembangan full-stack berdasarkan node menjadi sesuatu yang dapat diterima semua orang. Proyek "Midway" kami yang sedang berlangsung adalah untuk menyelesaikan masalah ini. Meskipun kami tidak lama sebelumnya, kami semakin dekat dengan tujuan kami! Lai