Halo para Penduduk! Buat aplikasi web dinamis menggunakan Express, komponen kunci dari tumpukan pengembangan Node / JavaScript. Ethan Brown menjelaskan cara bekerja dengan Express 5 dengan membuat aplikasi lengkap. Buku ini mencakup semua tahapan dan komponen - dari rendering server hingga pengembangan API untuk bekerja dengan aplikasi satu halaman (SPA). Express adalah jalan tengah antara kerangka kerja yang mapan dan tidak ada kerangka sama sekali, sehingga memberikan Anda kebebasan dalam memilih arsitektur. Buku ini akan memberikan solusi terbaik untuk pengembang front-end dan back-end yang menggunakan Express. Belajar untuk melihat pengembangan web dari sudut pandang baru! - Buat sistem template untuk menampilkan data dinamis. Pelajari lebih lanjut tentang Objek Permintaan dan Respons, Middleware, dan Perutean URL.- Buat simulasi lingkungan produksi dan uji di dalamnya. - Pelajari penyimpanan informasi jangka panjang dalam database dokumen menggunakan MongoDB dan dalam database relasional menggunakan PostgreSQL. - Bagikan sumber daya Anda dengan program lain berkat API. - Bangun aplikasi aman menggunakan otentikasi, otorisasi dan HTTPS. - Integrasikan dengan jejaring sosial, aktifkan geolokasi, dan banyak lagi. - Menerapkan rencana untuk meluncurkan dan memelihara aplikasi Anda. - Kuasai keterampilan debugging kritis.- Bangun aplikasi aman menggunakan otentikasi, otorisasi dan HTTPS. - Integrasikan dengan jejaring sosial, aktifkan geolokasi, dan banyak lagi. - Menerapkan rencana untuk meluncurkan dan memelihara aplikasi Anda. - Kuasai keterampilan debugging kritis.- Bangun aplikasi aman menggunakan otentikasi, otorisasi dan HTTPS. - Integrasikan dengan jejaring sosial, aktifkan geolokasi, dan banyak lagi. - Menerapkan rencana untuk meluncurkan dan memelihara aplikasi Anda. - Kuasai keterampilan debugging kritis.
Jaringan pengiriman konten
Saat Anda membawa situs Anda ke produksi, aset statis harus diupload di suatu tempat di Internet. Anda mungkin terbiasa meletakkannya di server yang sama tempat semua HTML dinamis Anda dibuat. Contoh kita sejauh ini juga menggunakan pendekatan ini: server Node / Express, diluncurkan oleh perintah node meadowlark.js, melayani semua jenis HTML dan sumber daya statis. Namun, jika Anda ingin mengoptimalkan kinerja situs Anda (atau menyimpannya di masa mendatang), Anda akan memerlukan kemampuan untuk menghosting sumber daya statis di jaringan pengiriman konten (CDN). CDN adalah server yang dioptimalkan untuk mengirimkan sumber daya statis. Ini menggunakan tajuk khusus (yang akan kita pelajari lebih lanjut segera) yang memungkinkan cache browser.
Selain itu, CDN dapat menyertakan pengoptimalan geografis (sering disebut cache tepi), yang berarti bahwa konten statis akan dikirim dari server yang paling dekat dengan klien Anda. Meskipun Internet sangat cepat (tentu saja, tidak bekerja dengan kecepatan cahaya, tetapi mendekati), data akan dikirim lebih cepat dari jarak ratusan kilometer daripada ribuan. Penghematan waktu tidak signifikan dalam setiap kasus, tetapi ketika dikalikan dengan jumlah pengguna, permintaan, dan sumber daya, itu dengan cepat menjadi mengesankan.
Sebagian besar sumber daya statis Anda akan dirujuk dalam tampilan HTML
<link> CSS-, <script> — JavaScript, <img> ,
Ini adalah praktik umum untuk memiliki tautan statis di CSS, biasanya di properti gambar latar belakang. Terakhir, sumber daya statis terkadang direferensikan dalam JavaScript, misalnya kode JavaScript dapat mengubah atau menyisipkan tag secara dinamis.
<img>
atau properti gambar latar belakang.
Jangan khawatir tentang berbagi sumber daya lintas domain (CORS) saat menggunakan CDN. Sumber daya eksternal yang dimuat dalam HTML tidak tunduk pada aturan CORS: Anda hanya perlu mengaktifkan CORS untuk sumber daya yang dimuat melalui Ajax (lihat Bab 15).
Mendesain CDN
Cara Anda menggunakan CDN bergantung pada arsitektur situs Anda. Sebagian besar jaringan pengiriman konten memungkinkan Anda menyetel aturan perutean untuk menentukan ke mana harus mengirim permintaan masuk. Meskipun Anda dapat menyetel aturan perutean yang cukup kompleks, biasanya hal itu bermuara pada pengiriman permintaan sumber daya statis ke satu lokasi (biasanya disediakan oleh CDN Anda) dan permintaan titik akhir dinamis (halaman dinamis atau titik akhir API) ke lokasi lain.
Memilih dan mengonfigurasi CDN adalah topik luas yang tidak akan saya bahas di sini, tetapi saya akan memberi Anda beberapa informasi dasar untuk membantu Anda mengatur CDN pilihan Anda.
Pendekatan paling sederhana untuk menyusun aplikasi Anda adalah dengan membuat sumber daya dinamis dan statis mudah dibedakan. Ini akan membuat aturan perutean CDN Anda sesederhana mungkin. Meskipun hal ini dapat dicapai dengan menggunakan subdomain (misalnya, sumber daya dinamis disajikan dari meadowlark.com dan sumber daya statis dari static.meadowlark.com), pendekatan ini menambah kompleksitas tambahan dan memperumit pengembangan lokal. Cara yang lebih mudah adalah dengan menggunakan jalur permintaan: misalnya, segala sesuatu yang dimulai dengan / public / adalah sumber daya statis, dan yang lainnya dinamis. Pendekatannya mungkin berbeda jika Anda membuat konten dengan Express atau menggunakan Express untuk menyediakan API untuk aplikasi satu halaman.
Situs web rendering sisi server
Jika Anda menggunakan Express untuk merender HTML dinamis (dengan kata lain, segala sesuatu yang dimulai dengan / static /) adalah sumber daya statis, dan yang lainnya dinamis. Dengan pendekatan ini, semua URL Anda (yang dibuat secara dinamis) akan menjadi seperti yang Anda inginkan (kecuali jika dimulai dengan / static /, tentu saja!), Dan semua sumber daya statis Anda akan diawali dengan / static /:
<img src="/static/img/meadowlark-logo-1.png" alt="Meadowlark Logo">
<a href="/about">Meadowlark Travel</a>.
Sejauh ini dalam buku ini, kami telah menggunakan middleware statis, seolah-olah semua sumber daya statis diletakkan di direktori root. Jadi, dengan menempatkan sumber daya statis foo.png di folder publik, kami merujuknya ke jalur URL /foo.png, bukan /static/foo.png. Tentu saja, dimungkinkan untuk membuat subdirektori statis di dalam direktori publik yang ada dan URL untuk /public/static/foo.png akan menjadi /static/foo.png, tetapi ini tidak terlalu cerdas. Untungnya, middleware statis memungkinkan kita menghindari hal ini dengan menentukan jalur berbeda saat memanggil app.use:
app.use('/static', express.static('public'))
Sekarang, di lingkungan pengembangan, kita dapat menggunakan struktur URL yang sama seperti dalam eksploitasi. Jika konten folder publik dan CDN sinkron, Anda dapat mereferensikan sumber daya statis di kedua tempat dan beralih dengan mulus antara pengembangan dan produksi.
Saat menyiapkan perutean untuk CDN (Anda perlu merujuk ke dokumentasi CDN Anda), peruteannya akan terlihat seperti ini.
Aplikasi Halaman Tunggal Aplikasi Halaman
Tunggal umumnya kebalikan dari situs web yang dirender sisi server: hanya API yang akan diteruskan ke server (misalnya, permintaan apa pun yang dimulai dengan / api), yang lainnya diteruskan ke penyimpanan file statis.
Di Bab 16, Anda melihat bahwa Anda dapat membuat rakitan untuk mengoperasikan aplikasi Anda yang akan menyertakan semua sumber daya statis yang dimuat ke dalam CDN. Kemudian Anda hanya perlu memastikan bahwa penyiapan perutean API Anda sudah benar. Dengan cara ini Anda akan memiliki perutean berikut.
Sekarang setelah kita mempelajari cara menyusun aplikasi untuk transisi yang mulus dari pengembangan ke produksi, mari kita lihat apa yang sebenarnya terjadi dalam caching dan bagaimana ia mengoptimalkan kinerja.
Menyimpan Sumber Daya Statis
Baik Anda menggunakan Express atau CDN untuk menyajikan sumber daya statis, ada baiknya memahami header permintaan HTTP yang digunakan browser untuk menentukan kapan dan cara menyimpan sumber daya statis ke dalam cache.
- Kedaluwarsa / Cache-Control. Kedua header ini memberi tahu browser Anda jumlah waktu maksimum suatu sumber daya dapat disimpan dalam cache. Browser menganggap mereka serius: jika mereka menyuruhnya menyimpan sesuatu selama sebulan, itu tidak akan mengunduhnya lagi selama sebulan, selama itu tetap ada di cache. Penting untuk dipahami bahwa browser mungkin menghapus gambar dari cache sebelum tanggal kedaluwarsa karena alasan yang tidak dapat Anda kendalikan. Misalnya, pengguna dapat mengosongkan cache secara manual, atau browser dapat menghapus sumber daya Anda untuk memberi ruang bagi sumber daya yang lebih sering dikunjungi pengguna. Anda hanya membutuhkan salah satu dari tajuk ini. Kedaluwarsa lebih banyak didukung, jadi lebih disukai untuk menggunakannya. Jika sumber daya ada dalam cache dan belum kedaluwarsa,browser tidak akan menjalankan permintaan GET sama sekali, yang akan meningkatkan kinerja, terutama pada perangkat seluler.
- Modifikasi Terakhir / ETag. Sediakan semacam kontrol versi: jika browser perlu memeriksa sumber daya, browser akan memeriksa tag tersebut sebelum memuat konten. Permintaan GET ke server akan tetap dijalankan, tetapi jika nilai yang dikembalikan di header ini menunjukkan kepada browser bahwa sumber daya tidak berubah, browser tidak akan melanjutkan untuk mengunduh file. Seperti namanya, Last-Modified memungkinkan Anda menyetel tanggal saat aset terakhir diubah. ETag memungkinkan Anda menggunakan string arbitrer, biasanya string versi atau hash konten.
Saat menerbitkan sumber daya statis, gunakan header Expires dan Last-Modified atau ETag. Middleware statis bawaan Express menginstal Cache-Control, tetapi tidak memproses Last-Modified atau ETag. Oleh karena itu, cocok untuk pengembangan, tetapi tidak untuk pengoperasian.
Jika Anda memilih untuk menghosting aset statis Anda di CDN, seperti Amazon CloudFront, Microsoft Azure, Fastly, Cloudflare, Akamai, atau StackPath, Anda akan mendapatkan bonus: sebagian besar detail ini akan ditangani untuk Anda. Anda akan dapat membuat penyesuaian yang bagus, meskipun pengaturan default di salah satu layanan ini juga baik-baik saja.
Mengubah konten statis
Caching secara signifikan meningkatkan kinerja situs Anda, tetapi bukan tanpa konsekuensi. Secara khusus, jika salah satu sumber daya statis berubah, klien mungkin tidak melihat perubahan hingga versi cache browser telah kedaluwarsa. Google merekomendasikan caching selama satu bulan, lebih disukai satu tahun. Bayangkan seorang pengguna yang mengunjungi situs Anda setiap hari melalui browser yang sama: dia dapat melihat pembaruan Anda hanya setelah setahun!
Jelas, ini bukanlah situasi yang diinginkan, tetapi Anda tidak dapat memberi tahu pengguna Anda untuk menghapus cache. Solusi untuk masalah ini adalah menonaktifkan perusakan cache. Trik ini akan memberi Anda kendali atas kapan browser harus memuat ulang sumber daya. Metode ini hanya menambahkan beberapa informasi versi ke nama file. Saat Anda memperbarui sumber daya, nama sumber daya berubah dan browser tahu untuk mengunduhnya. Biasanya, ini sama saja dengan mengontrol versi sumber daya (main.2.css atau main.css? Version = 2) atau menambahkan beberapa jenis hash (main.e16b7e149dccfcc399e025e0c454bf77.css). Metode apa pun yang Anda gunakan, saat Anda memperbarui sumber daya, namanya berubah dan browser tahu untuk memuatnya.
Anda dapat melakukan hal yang sama dengan sumber multimedia. Mari kita ambil logo kita (/static/img/meadowlark_logo.png). Jika kami meletakkannya di CDN untuk memaksimalkan kinerja dengan menyetel periode retensi menjadi satu tahun dan kemudian mengubah logo, pengguna mungkin tidak melihat perubahan selama setahun. Namun, jika kami mengganti nama logo menjadi /static/img/meadowlark_logo-1.png dan mencerminkan perubahan ini dalam HTML, browser harus mendownloadnya karena tampaknya merupakan resource baru.
Jika Anda menetapkan kerangka aplikasi halaman tunggal seperti create-react-app atau yang serupa, maka pada tahap build, rakitan resource yang siap digunakan akan dibuat dengan hash yang ditambahkan ke dalamnya.
Jika Anda memulai dari awal, Anda mungkin ingin melihat pembuat (itulah yang ada di balik kerangka kerangka aplikasi satu halaman). JavaScript, CSS, dan beberapa jenis sumber daya statis lainnya akan digabungkan menjadi kumpulan sesedikit mungkin, dan hasilnya akan diminimalkan sebanyak mungkin. Kustomisasi build adalah topik yang luas, tetapi untungnya ada banyak dokumentasi yang bagus tentangnya. Di bawah ini adalah kolektor paling populer yang tersedia saat ini.
- Webpack (https://webpack.js.org/). Salah satu kolektor pertama yang mencapai kemajuan nyata. Dia masih punya banyak pendukung. Ini sangat kompleks, dan ada harga yang harus dibayar untuk kompleksitas itu: kurva pembelajarannya curam. Namun, pengemas ini bagus untuk mempelajari dasar-dasarnya.
- Parcel (https://parceljs.org/). Muncul baru-baru ini dan membuat banyak kebisingan. Ini didokumentasikan dengan sangat baik, sangat cepat, dan yang terpenting, memiliki kurva belajar terpendek. Sangat cocok jika Anda ingin menyelesaikan pekerjaan dengan cepat dan tanpa kerumitan.
- Rollup (https://rollupjs.org/). Itu berada di antara Webpack dan Parcel. Seperti Webpack, ini kuat dan kaya fitur. Lebih mudah untuk memulai daripada Webpack, bagaimanapun, tetapi tidak semudah Parcel.
Ringkasan
Untuk semua kesederhanaannya, sumber daya statis sangat merepotkan. Namun, mereka merupakan bagian terbesar dari data yang dikirim ke pengunjung Anda, sehingga waktu yang dihabiskan untuk mengoptimalkannya akan terbayar dengan bunga.
Solusi yang layak untuk sumber daya statis, yang tidak disebutkan sebelumnya, adalah mengekspos sumber daya statis ke CDN dan selalu menggunakan URL lengkap ke sumber daya dalam tampilan dan CSS. Keuntungan dari pendekatan ini adalah sangat sederhana, tetapi jika Anda ingin menyelenggarakan hackathon selama seminggu di sebuah pondok hutan tanpa akses internet, Anda dalam masalah!
Perakitan dan minifikasi yang cermat adalah area lain tempat Anda dapat menghemat waktu jika peningkatan kinerja aplikasi Anda tidak membenarkan upaya tersebut. Secara khusus, jika Anda hanya memiliki satu atau dua file JavaScript di situs Anda, dan semua CSS ada di file yang sama, Anda dapat melewati pembuatan sama sekali, tetapi aplikasi dunia nyata cenderung bertambah seiring waktu.
Metode apa pun yang Anda pilih untuk menyajikan sumber daya statis, saya menyarankan Anda untuk mengunggahnya secara terpisah, sebaiknya di CDN. Jika menurut Anda itu merepotkan, saya jamin: sama sekali tidak sesulit kelihatannya. Apalagi jika Anda meluangkan sedikit waktu pada sistem penyebaran sebelumnya sehingga penyebaran sumber daya statis ke satu lokasi dan aplikasi ke lokasi lain akan otomatis.
Jika Anda khawatir tentang biaya hosting di CDN, saya mendorong Anda untuk melihat jumlah yang saat ini Anda bayarkan untuk hosting. Sebagian besar penyedia hosting mengenakan biaya besar untuk lalu lintas bahkan jika Anda tidak mengetahuinya. Namun, jika tiba-tiba situs Anda terdaftar di Slashdot dan Anda mengalami efek slashdot, Anda mungkin menerima tagihan hosting yang sama sekali tidak terduga. CDN hosting biasanya diatur sedemikian rupa sehingga Anda hanya membayar apa yang Anda gunakan. Misalnya, situs yang saya jalankan untuk perusahaan menengah lokal menggunakan sekitar 20GB lalu lintas per bulan, sedangkan biaya hosting statis (yang merupakan situs yang sangat berat media) hanya beberapa dolar per bulan.
Manfaat menempatkan sumber daya statis pada CDN sangat besar, dan biaya serta ketidaknyamanan melakukannya minimal, jadi saya sangat menyarankan Anda untuk memilih jalur ini.
Dengan trik JavaScript tertentu di browser, Anda dapat menggunakan LESS yang tidak dikompilasi. Namun, pendekatan ini dapat menimbulkan konsekuensi negatif dalam hal performa, jadi saya tidak menyarankan untuk menggunakannya.
Rincian lebih lanjut tentang buku dapat ditemukan di situs web penerbit
» Daftar Isi
» Kutipan
Untuk Habitants diskon 25% untuk kupon - JavaScript
Setelah pembayaran untuk versi kertas dari buku tersebut, e-book dikirim melalui e- surat.