Pendahuluan Dasar
Mari kita mulai dengan konsep "template" yang penting. Secara umum, templat di web adalah halaman yang dapat menghasilkan file setelah mengisi data. Secara tegas, mesin templat harus menggunakan file dalam format tertentu dan data yang disediakan untuk menyusun dan menghasilkan halaman. Templat secara kasar dibagi menjadi templat front-end (seperti EJS) dan templat back-end (seperti Freemarker) yang dikompilasi masing-masing di sisi browser dan server.
Karena beberapa siswa di tempat tidak tahu banyak tentang Node.js, berikut adalah beberapa pengetahuan yang relevan dari Node.js. Saya tidak akan berbicara tentang definisi acara yang digerakkan, asinkron dan sebagainya di situs web resmi. Di sini saya meminjam gambar dari Pu Lingshu untuk menjelaskan struktur Node.js. Jika Anda memahami Java, Anda dapat memahaminya sebagai JVM versi JS. Browser umumnya termasuk mesin render dan JS Script. Mengambil browser Chrome sebagai contoh, mereka menggunakan mesin WebKit Kernel dan mesin skrip V8, sementara Node.js menggunakan mesin V8. Singkatnya, ini adalah lingkungan yang berjalan JS, seperti alat debugging F12 browser, tetapi Node.js tidak memiliki DOM dan BOM.
Gambar ini menjelaskan beberapa informasi di sekitar Node.js, seperti NPM, manajer paket yang sangat baik, komunitas CNode, dan GitHub, yang telah mempromosikan kemakmuran Node.js sampai batas tertentu dan memberikan jaminan teknis.
Perusahaan besar biasanya merupakan baling -baling cuaca teknologi. Misalnya, Google's Angular dan Facebook's React sangat populer sekarang. Hanya 3 perusahaan besar yang terdaftar di sini sebagai contoh. Tak perlu dikatakan, arsitektur tengah Taobao adalah, Pu Ling, pelopor node domestik, berasal dari Taobao. Qunar juga telah mengembangkan kerangka teknis yang harus disebut "QTX". Tim 75 yang dipimpin oleh Yueying meluncurkan kerangka kerja server web berdasarkan ES6/ES7 - ThinkJs. Pada saat itu, direktur teknis kami sangat optimis, tetapi karena saya tidak punya waktu untuk belajar ES6 dan plug-in tidak cukup kaya, saya masih memilih ekspres yang lebih matang.
Kembali ke topik, tabel ini mencantumkan tiga metode pengembangan untuk pemisahan ujung depan dan belakang yang telah saya hadapi. Yang pertama adalah templat bahasa backend yang paling umum yang menggunakan Java, yang ramah SEO, dan lebih baik dalam pemanfaatan cache dan mengurangi beban rendering browser. Masalah terbesar adalah tingkat kopling file template terlalu tinggi. Tidak ada yang mau menyelesaikan masalah. Personel front-end tidak dapat melihat data, personel back-end tidak memahami halaman, dan file template seperti kentang panas. Yang kedua adalah solusi implementasi saat ini dari terminal seluler proyek kami, yang menggunakan kerangka kerja sudut (instruksi sudut dapat dianggap sebagai templat front-end) dan server proxy terbalik dari Nginx untuk sepenuhnya memisahkan front-end dan back-end, dan hanya berinteraksi dengan data melalui AJAX. Solusi ini persis kebalikan dari kelebihan dan kekurangan yang pertama. Kinerja templat front-end selalu menjadi masalah, terutama pada perangkat seluler, dan lebih khusus pada perangkat seluler kelas bawah. Yang terakhir adalah proyek baru yang menggunakan Node.js sebagai server front-end, yang membagi tanggung jawab front-end dari browser ke tingkat template, memecahkan semua masalah di atas, tetapi memang ada masalah baru, dan masalah ini akan dianalisis nanti.
Tentu saja, pengembangan tumpukan penuh juga sangat cocok untuk proyek-proyek kecil. Untuk pengembangan JSP/PHP tradisional, biaya komunikasi pengembangan tumpukan penuh lebih rendah, dan pengembang dapat dengan mudah memahami seluruh modul fungsional, sehingga lebih baik memulihkan desain produk. Terutama pengembangan tumpukan penuh berdasarkan bahasa JS: meteor dan teknologi rata-rata yang sekarang muncul membuat pengembangan front-end dan back-end langsung ditangani dalam satu bahasa. Dengan MongoDB, data dari browser ke database secara langsung digunakan tanpa melarikan diri, dan tidak perlu menulis SQL, yang sangat mengurangi biaya pengembangan.
Beberapa plugin yang digunakan untuk membangun server Node.js kali ini. Tidak perlu memperkenalkan Express yang terkenal, kerangka kerja server web yang ringan. Ini juga merupakan kebetulan untuk menggunakan mesin templat setang, karena Express4 adalah secara default. Setang layak menjadi mesin templat "logika lemah". Itu menganjurkan pengurangan logika template dan mencoba hanya menggunakan variabel dan paging. Berdasarkan konsep desainnya, saya hanya memperluas dua pembantu. Artikel spesifik: https://yalishizhude.github.io/2016/01/22/handlebars/superagent masih digunakan karena Express4. Karena kode pengujiannya menggunakan Supertest, Supertest didasarkan pada superagen, sehingga SuperAgent digunakan untuk meneruskan dan memulai permintaan. Superagent masih terlalu lemah dan tidak dapat dibangun untuk koneksi panjang. Saya masih merekomendasikan plugin permintaan. Tidak ada yang bisa diperkenalkan pada Restfuleasi. Server front-end dan browser, server front-end dan server back-end semuanya menggunakan set spesifikasi ini. Pada dasarnya, URL menunjuk ke sumber daya, menambah, menghapus, memodifikasi dan memeriksa, dan metode permintaan spesifik diekspresikan, kode status mewakili hasil, dll. ~ Alat pengemasan GULP, webpack telah lama belajar, dan menemukan bahwa setiap halaman yang ditambahkan memerlukan modifikasi file konfigurasi. Ini terlalu menyakitkan, jadi saya menyerah.
Proses pengembangan
Jika berbagi ini terutama berbicara tentang cara menggunakan node.js sebagai server front-end untuk mencapai pemisahan front-end, maka tidak ada yang bisa dikatakan, lihat saja artikel di taobao ued. Masalah terbesar dengan pemisahan ujung depan dan belakang adalah memunculkan biaya komunikasi, khususnya definisi dan debugging antarmuka. Dalam proses pengembangan tradisional pada gambar di atas, definisi antarmuka akan ditempatkan di server antarmuka, dan kemudian ujung depan dan belakang akan melakukan debugging lokal berdasarkan data penipuan dokumen antarmuka, dan kemudian melakukan debugging bersama. Tautan ini adalah saat ujung depan dan belakang mulai bertarung. Parameter ini salah dan nilai pengembalian salah. Singkatnya, itu adalah buang -buang waktu. Selanjutnya, mari kita lihat bagaimana masalah ini diselesaikan dalam proyek kami ~
Masalah antarmuka yang berjumbai di ujung depan dan belakang selalu ada. Sebagai seorang konservatif, saya percaya pada pengembangan berulang, jadi langkah pertama adalah menambahkan server tiruan. Keajaiban server ini adalah secara otomatis menghasilkan data palsu berdasarkan dokumen antarmuka, menerapkan antarmuka, yaitu API, dan siswa front-end tidak lagi harus menulis data sampai mati untuk pengujian. Tidak mungkin, siapa bilang saya pengembang front-end? Pertama -tama, saya memikirkan orang -orang saya sendiri. Hehe ~ tentu saja, ini hanya bermanfaat bagi pengembangan front-end sampai batas tertentu. Juga akan ada masalah ketika antarmuka dan dokumen back-end tidak konsisten dan terhubung. Apa yang harus dilakukan?
Saya secara tidak sengaja melihat sebuah artikel oleh Lao Ma di blog The Blade Master, yang secara khusus berbicara tentang pemisahan ujung depan dan belakang. Salah satu konsep penting adalah pengujian kontrak, juga disebut pengujian bilateral. Konsep intinya adalah menyelesaikan masalah debugging bersama yang jauh. Verifikasi parameter ujung depan dan belakang dan mengharuskan semua orang untuk berkembang sesuai dengan dokumen antarmuka. Terinspirasi olehnya, aturan JSON-Schema ditambahkan untuk mewujudkan verifikasi parameter permintaan HTTP, dan siapa pun yang tidak mengikuti aturan akan mengubahnya.
Redmine ini adalah manajer dokumen antarmuka kami yang paling awal dan tidak memiliki fungsi lain kecuali fungsi perekaman dan tampilan.
Swagger dikenal sebagai server dokumen antarmuka paling populer di dunia. Ini memiliki antarmuka yang indah dan banyak plug-in. Ini dapat secara langsung menghasilkan kode uji untuk bahasa back-end. Namun, saya tidak pernah memahaminya ketika menggunakannya, dan format YAML tidak sebagus JSON, jadi saya menyerah.
Ini adalah server dokumen dan server tiruan yang digunakan dalam proyek kami, server yang diimplementasikan berdasarkan teknologi rata -rata, dan fungsi dasar:
Menggunakan plug-in mockJs, data acak dapat dihasilkan secara dinamis untuk melakukan tes antarmuka checksum pada parameter antarmuka berdasarkan json-schema, dan status uji dan waktu respons antarmuka dapat disimpan. Editor JSON sederhana memiliki fungsi verifikasi login, dan debugging antarmuka dapat dilakukan setelah masuk. Server mock menanggapi permintaan sesuai dengan server API, dan akan diperbarui secara otomatis ketika antarmuka diperbarui.
Beberapa pertanyaan
Node.js adalah sayap insinyur front-end, dan haruskah saya menjadi malaikat atau iblis dengan sayap? Ini tergantung pada apakah masalah yang disebabkan oleh penggunaannya dapat diselesaikan.
Pertama -tama, beban kerja di ujung depan tidak diragukan lagi akan meningkat, tetapi biaya komunikasi akan dikurangi. Stabilitas server node.js utas tunggal memang tidak cukup baik, tetapi kekokohan kode dan log yang sempurna dapat dihindari secara efektif. Panggilan balik. Ada terlalu banyak solusi untuk masalah ini, termasuk modul q/async Node.js dan ES6/ES7. debugging node.js. Meskipun saya selalu menolak IDE, saya harus mengakui bahwa Webstorm memang sangat nyaman untuk debugging. Node-Inspector yang saya gunakan juga cukup bagus, antarmuka ini mirip dengan alat pengembang Chrome, dan terlihat cukup akrab.
Jika Anda seorang programmer backend, Anda harus lebih cenderung mengakomodasi Node.js. Pekerjaan integrasi antarmuka diserahkan ke server front-end untuk diproses, dan tingkat kopling dengan front-end sangat berkurang, dan beban kerja dan efisiensi kerja berkurang.
Ada dua poin untuk dialami
Meskipun penggunaan Node.js memiliki biaya belajar tertentu, itu masih sangat ramah kepada pengembang front-end. Selain itu, jika Node.js digunakan di ujung depan, baik konten teknis dan beban kerja akan ditingkatkan, sehingga meningkatkan pentingnya pekerjaan. Hanya ketika pengembang saat ini dapat menciptakan lebih banyak nilai yang memenuhi syarat untuk menuntut gaji yang lebih tinggi. Dianjurkan untuk membuat lebih sedikit saran dan memberikan lebih banyak rencana kelayakan di tempat kerja, dan melakukan pra-penelitian teknis alih-alih menulis HelloWorld sederhana.
Meringkaskan
Beberapa orang mungkin mengatakan bahwa serangkaian hal yang Anda perkenalkan sangat rumit dan terlalu merepotkan untuk digunakan, jadi lebih baik berkomunikasi secara langsung. Untuk keraguan seperti itu, saya hanya dapat menggunakan contoh yang disebutkan oleh insinyur UI senior Tencent Yu Guo dalam "Penularan Diri dari Web Full Stack Engineers". Suatu ketika, ketika orang front-end yang bertanggung jawab atas perusahaan kecil di telepon bertanya kepadanya bagaimana mengelola kode, pihak lain mengatakan bahwa ia akan menggunakan FTP untuk mengunggahnya secara langsung, dan mengeluh bahwa bawahannya selalu memperbarui kode yang salah. Dia juga bertanya kepadanya mengapa dia tidak menggunakan SVN atau Git, dan dia mengatakan bahwa akan lebih mudah untuk memperbarui secara manual. Kebenaran dari cerita ini adalah jawaban saya untuk pertanyaan ~
alamat unduhan ppt