Penulis materi, terjemahan yang kami terbitkan, mengumpulkan 19 ide yang mungkin berguna bagi para pengembang Node.js yang ingin meningkatkan level profesional mereka pada tahun 2019. Dunia JavaScript sangat besar, sehingga menguasai segala sesuatu yang akan dibahas di sini tidak realistis. Tidak mungkin ada seseorang yang memiliki semua ini dengan sempurna. Namun, sesuatu dalam ulasan ini mungkin berguna bagi Anda.
1. Pikirkan tentang mengetik. Perhatikan TypeScript
Terbukti bahwa pemrograman dalam JavaScript, menggunakan pendekatan pengetikan yang digunakan di dalamnya, mengarah pada penurunan produktivitas tenaga kerja dan munculnya kesalahan. Ini tidak berarti bahwa Anda harus berusaha untuk memastikan bahwa semua kode diketik dengan kuat. Sebaliknya, kita berbicara tentang fakta bahwa akan lebih baik, ketika mengembangkan JavaScript, untuk memilih pendekatan tertentu untuk bekerja dengan tipe dan tetap menggunakannya. Pendekatan semacam itu berbeda, antara lain, dengan tingkat pembatasan yang terkait dengan jenis data yang dikenakan pada kode. Sebagai contoh, ini bisa menjadi sesuatu yang sangat sederhana, seperti mengatur cek menggunakan paket
jsonschema (atau
joi ). Jika Anda merasa bahwa Anda memerlukan kontrol tipe yang lebih ketat, Anda dapat mempertimbangkan menggunakan anotasi jenis dalam kode JS biasa (di sini
aliran dari Facebook akan membantu Anda). Dan jika Anda siap untuk menulis kode yang hampir seluruhnya diketik - perhatikan
TypeScript .
Perlu dicatat bahwa pada tahun 2018 TypeScript mendapatkan popularitas yang serius, di samping itu, ada perasaan bahwa ada semua prasyarat untuk itu untuk memantapkan dirinya dengan kuat di Node.js. Jika Anda serius melihat TypeScript, Anda harus bertanya pada diri sendiri apakah Anda hanya berpikir tentang mengetik, atau tentang fitur lain dari bahasa tersebut. Intinya di sini adalah bahwa bekerja dengan sesuatu seperti antarmuka dan kelas abstrak akan berarti bahwa Anda akan menemukan diri Anda dalam lingkungan di mana, terutama berpikir tentang mengetik, Anda hampir tidak akan masuk ke dalamnya.
2. Perhatikan kemampuan linter
Linter hari ini diterima begitu saja. Setelah pengaturan sederhana, Anda memiliki alat yang siap membantu Anda menemukan kesalahan dalam kode. Lewat sudah hari-hari ketika kode linting terutama berarti mengendalikan desainnya (sesuatu seperti ada atau tidak adanya titik koma). Sekarang linter dapat mengidentifikasi masalah serius - seperti kesalahan yang tidak ditangani dengan benar, janji-janji yang tidak pernah diselesaikan, dan masalah serupa lainnya yang secara sadar tidak akan dimasukkan ke dalam kode mereka. Karena itu, jika Anda belum menggunakan linter, sekaranglah saatnya untuk melakukannya, tanpa melupakan konfigurasi yang bijak. Di sini, misalnya, adalah plugin untuk
ESLint ,
eslint-plugin-chai-expect , yang dapat mendeteksi tes yang dikomposisikan secara keliru. Berikut ini adalah
plugin eslint-plugin-janji yang mendeteksi janji yang tidak terselesaikan (kode dengan janji seperti itu, tanpa alasan yang jelas, berhenti). Menggunakan
plugin eslint-plugin-security, dimungkinkan untuk menemukan ekspresi reguler yang tidak aman dalam kode yang dapat digunakan oleh penyerang untuk melakukan serangan DOS.
3. Memperdalam pengetahuan Anda tentang arsitektur proyek perangkat lunak dengan mengadopsi sesuatu dari dunia Java dan melupakan banyak hal dari dunia Ruby
Ekosistem Node.js jarang mengangkat topik arsitektur dan desain sistem informasi. Jadi, semua orang berbicara tentang layanan mikro, tetapi hanya sedikit yang berbicara tentang struktur internal mereka. Akibatnya, sebagian besar aplikasi Node.js adalah contoh penerapan konsep MVC dan pola meragukan lainnya dari dunia Ruby. Apa yang buruk tentang itu? Template MVC, misalnya, dibuat untuk merampingkan pekerjaan dengan data, tetapi template ini tidak cocok untuk merancang bagian server aplikasi yang andal. Bob Martin, misalnya,
mengatakan bahwa MVC adalah mekanisme untuk mengirimkan data kepada pengguna, bukan arsitektur aplikasi. Apakah mungkin untuk menggambarkan logika bisnis aplikasi layanan mikro, aturan operasinya, fitur akses data, interaksi dengan layanan microser lainnya hanya dengan menggunakan dua kelas -
Controller dan
Model ?
Perlu dicatat bahwa saya benar-benar tidak ingin merekomendasikan penggunaan template Java / Spring di Node.js di sini (setelah semua, bukan kebetulan bahwa kami beralih ke Node.js untuk mengembangkan program server?). Saya akan menyarankan Anda untuk meminjam hanya beberapa ide yang, di satu sisi, dapat memiliki efek menguntungkan pada arsitektur aplikasi, dan di sisi lain, tidak akan menyebabkan kompleksitas yang berlebihan.
Berikut adalah beberapa pedoman bagi mereka yang peduli tentang arsitektur proyek Node.js:
- Baca bagian pertama artikel ini di arsitektur aplikasi Node.js.
- Cobalah untuk tidak mencampur logika bisnis aplikasi dengan objek Express, baca tentang prinsip-prinsip Desain Berbasis Domain (DDD) dan arsitektur heksagonal .
- Penggunaan pola Rekaman Aktif, yang sangat populer di kalangan pengembang yang menggunakan Mongoose dan Sequelize, dengan mudah mengarah pada tampilan objek yang kelebihan beban yang sulit untuk diuji. Pertimbangkan untuk menggunakan pola Data Mapper alih-alih pola Rekaman Aktif.
- Lihatlah kode untuk proyek template Node.js yang dibuat dengan baik ini , menampilkan arsitektur berkualitas yang mengimplementasikan prinsip-prinsip DDD.
4. Pikirkan tentang bagaimana menggunakan async_hooks Node.js-API baru saat bekerja dengan kode asinkron
Model eksekusi kode berulir tunggal yang digunakan dalam JavaScript memiliki satu kelemahan serius - operasi asinkron, misalnya, permintaan, kehilangan konteks. Itu tidak disimpan selama siklus hidup permintaan, karena operasi asinkron terlibat dalam pelaksanaannya. Kenapa ini buruk? Misalnya, pengembang sering berusaha untuk memasukkan pengidentifikasi kueri unik dalam entri jurnal, yang, ketika menganalisis catatan tersebut, memungkinkan seseorang untuk mengidentifikasi orang-orang yang berhubungan dengan permintaan yang sama. Hari ini, pada tahun 2018, ini tidak mudah. Tahun depan, sesuatu yang baru menunggu kita, yaitu, kita berbicara tentang kait asinkron, API
async_hooks . Ini bukan untuk mengatakan bahwa ini adalah kesempatan yang sama sekali baru, intinya adalah bahwa ia harus segera meninggalkan rezim eksperimental. Sederhananya, kait asinkron memungkinkan pengembang untuk mengeksekusi kode asli pada titik-titik tertentu dalam siklus hidup operasi asinkron. Dengan mengingat hal ini, Anda dapat mengoordinasikan tindakan yang dilakukan oleh kode asinkron dan mempertahankan konteks. Fitur ini meletakkan dasar untuk mengembangkan paket yang akan membawa Node.js ke tingkat baru dalam melacak operasi asinkron dan bekerja dengan konteks.
Sebagai contoh, paket
cls-hooked memungkinkan Anda untuk mengatur penggunaan variabel dan konteks sepanjang siklus hidup operasi asinkron. Paket
jaeger-client memungkinkan Anda untuk memvisualisasikan proses melewati permintaan melalui sistem, bahkan melalui microservices dan server (standar Javascript OpenTracing API 1.0 diterapkan di sini).
Berikut adalah bahan untuk mengetahui lebih lanjut tentang penggunaan async_hooks API.
5. Memahami teknologi "tanpa server" terbaru yang sudah cukup siap untuk proyek-proyek serius dan mampu membunuh Kubernetes
Di sini kita menggunakan konsep FaaS (Function as a Service, function as a service) dan "serverless technologies" sebagai sinonim, meskipun tidak berarti hal yang sama. Secara khusus, di bawah ini kita akan berbicara tentang layanan FaaS cloud.
Awalnya, teknologi FaaS dimaksudkan untuk mengembangkan tugas-tugas mikro, dan bukan untuk membuat aplikasi "layanan mikro" penuh. Semakin populernya platform FaaS telah menyebabkan peningkatan minat penyedia layanan cloud, platform FaaS telah mendapatkan fitur baru. Akibatnya, meskipun ini tidak terduga, ada perasaan bahwa pada 2019 platform FaaS dapat menjadi dasar untuk proyek-proyek serius. Bisakah platform ini bersaing dengan Kubernetes dan digunakan untuk meng-host aplikasi besar? Beberapa melihat dalam komputasi tanpa server dan teknologi FaaS yang merupakan sesuatu yang sama sekali baru, tetapi dalam praktiknya, setiap pencipta aplikasi cloud harus membuat pilihan antara ketiga teknologi pada 2019. Pilihan ini, secara harfiah, disajikan di situs web penyedia layanan cloud. Yaitu, kita berbicara tentang memilih satu dari tiga opsi:
- Server cloud normal (mis. VDS dari RUVDS)
- Kubernetes
- FaaS
Akibatnya, di zaman kita, sangat penting untuk dapat membandingkan kemampuan Kubernet dengan FaaS dan mengantisipasi konsekuensi dari memilih teknologi tertentu.
6. Periksa inovasi JavaScript yang akan segera standar.
Saya tidak bisa menyebut diri saya pendukung pencarian dan penggunaan fitur bahasa terbaru, karena kadang-kadang penggunaannya merusak kesederhanaan dan kelengkapan kode. Tetapi dari waktu ke waktu, fitur-fitur JavaScript yang sangat berharga muncul (seperti async / tunggu konstruksi dua tahun lalu), jadi sangat berguna untuk melihat daftar penawaran dan
node.gc. Sumber daya yang ramah untuk mengetahui terlebih dahulu tentang fitur-fitur baru yang mungkin cocok untuk Anda. Inilah yang menarik yang saya temukan di sana:
- Bidang kelas sekarang pada 3 (terakhir) tahap persetujuan, mereka dapat memasukkan standar pada 2019.
- Tipe data BigInt juga melewati tahap akhir dari rekonsiliasi. Penggunaan angka-angka jenis ini dapat membantu dalam mengatur interaksi dengan layanan-layanan mikro atau sistem apa pun, di mana angka-angka besar digunakan.
- Iterator asinkron dan metode akhirnya () telah diterima. Jika Anda belum memperhatikannya - bacalah.
7. Kuasai setidaknya satu teknologi untuk membuat API. Perhatikan GraphQL
REST-API adalah alat yang hebat untuk menyelesaikan kelas tugas tertentu. Yaitu, kita berbicara tentang mengelola kueri dan memodifikasi catatan dalam basis data. Apakah sistem Anda fokus untuk bekerja dengan data keuangan? Mungkin, untuk memastikan operasinya, perlu untuk mematuhi pembatasan ketat dan menggunakan model data yang dikembangkan dengan hati-hati yang tidak memungkinkan ambiguitas. Teknologi REST cocok untuk Anda dalam hal ini, tetapi tidak menunjukkan dirinya dengan sangat baik dalam situasi yang sangat umum lainnya, misalnya, ketika eksekusi permintaan yang sama dapat menyebabkan diterimanya set data yang berbeda. Hal yang sama berlaku untuk bekerja dalam kondisi kecepatan koneksi rendah, ketika data sesedikit mungkin ditransmisikan saat bekerja dengan API tertentu. Situasi seperti itu termasuk koneksi antar komputer, di mana komunikasi berkecepatan tinggi muncul. Apakah layak dalam kasus seperti itu untuk beralih ke sesuatu yang baru? Tidak, tidak sepadan. Yang terbaik adalah menambahkan sesuatu yang baru ke apa yang sudah digunakan. API bukan arsitektur aplikasi. Ini hanyalah titik akses ke aplikasi, yang berarti bahwa API yang dibuat menggunakan alat yang berbeda dapat hidup berdampingan. Bahkan jika mereka semua dibangun di atas kerangka web tunggal seperti Express.
Teknologi apa yang harus dipelajari? Mungkin, dalam kondisi saat ini layak bertaruh pada teknologi GraphQL, yang menjadi semakin populer. Ekosistem teknologi ini telah matang secara signifikan, melayani beberapa skenario data yang sangat populer - seperti pencarian dinamis dan interaksi dengan sumber data hierarkis. Di sisi lain, teknologi gRPC masih merupakan solusi yang sangat khusus yang sangat cocok untuk komunikasi antara server dalam situasi ketika selama pertukaran data, diharapkan untuk mentransfer informasi layanan sesedikit mungkin (misalnya, kita berbicara tentang sistem pertukaran data berdasarkan pada " publisher-subscriber ”, atau tentang mereka yang menggunakan antrian pesan dan pesan). Berikut adalah beberapa tulisan bermanfaat tentang hal ini:
- Perbandingan REST, GraphQL dan gRPC
- Pengembangan server GraphQL berdasarkan Node.js dan Express
- Video YouTube 11 menit menjelaskan dasar-dasar GraphQL
8. Menggunakan tes unit dan integrasi? Lihatlah teknik pengujian baru.
Apakah Anda sudah terbiasa dengan piramida tes, dengan unit, integrasi, dan tes end-to-end? Jika begitu - hebat. Semua ini mendasari strategi pengujian yang sukses. Namun, perlu dicatat bahwa selama 10 tahun terakhir, dunia pengembangan perangkat lunak telah berubah dengan sangat serius, dan model pengujiannya tetap sama, yang menimbulkan pertanyaan kepada kami tentang cara menguji layanan mikro, aplikasi Internet yang kaya, sistem tanpa server. Beberapa pendekatan modern untuk pengujian melengkapi serangkaian teknologi tradisional, dan beberapa bahkan mungkin menggantinya, sehingga meningkatkan strategi dan hasil pengujian. Inilah yang dapat Anda baca dan lihat:
- Sistem pengujian yang dibangun pada pola Consumer-Driven Contracts membantu mencegah API server yang digunakan oleh layanan mikro atau klien gagal.
- Pengujian menggunakan snapshot dapat digunakan tidak hanya di frontend, tetapi juga di proyek server.
- Pengujian komponen adalah pendekatan yang seimbang untuk menguji layanan mikro.
- Berikut ini adalah video tentang pendekatan modern untuk menguji proyek Node.js.
9. Bawa sistem pemantauan aplikasi Anda sejalan dengan praktik terbaik SRE / DevOps
Pada 2019, bahkan aplikasi berukuran sedang dapat terdiri dari puluhan komponen. Untuk memastikan kelancaran operasi infrastruktur seperti itu, harus dipantau dengan cermat. Meskipun jelas di atas, sebagian besar pengembang masih tidak menganggap penting untuk mempelajari dan menggunakan rekomendasi tersebut untuk memantau aplikasi dan membuat sistem peringatan tentang masalah yang dapat diberikan kepada mereka oleh spesialis yang bertanggung jawab atas keandalan proyek web. Misalnya, pengembang sering fokus pada indikator internal kinerja sistem, seperti kecepatan prosesor atau RAM, daripada mengkhawatirkan metrik yang secara langsung mempengaruhi pengguna akhir. Secara khusus, kita berbicara tentang frekuensi kesalahan dan penundaan. Ini
disebut "pemantauan berbasis gejala." Indikator berorientasi pengguna seperti itu kadang-kadang disebut "sinyal emas", dan Anda, mungkin memperkenalkan sistem pemantauan, memutuskan untuk memulai dengan pengenalan metrik tersebut. Berikut adalah bahan terkait:
10. Tingkatkan keamanan proyek dengan melihatnya dari sudut pandang penyerang, serta mempelajari cara melakukan serangan dan alat peretas
Jika Anda tidak dapat berpikir seperti seseorang yang ingin menyerang sistem Anda, itu berarti Anda tidak dapat berpikir seperti yang akan dipikirkan oleh pembela sistem ini. Pada 2019, Anda tidak boleh mentransfer tugas untuk melindungi proyek ke pihak ketiga, atau hanya mengandalkan penganalisa keamanan statis. Saat ini ada sejumlah besar jenis serangan (tren terbaru di daerah ini adalah
serangan terhadap infrastruktur pembangunan dan pada npm). Pada saat yang sama, aplikasi berubah sangat, sangat cepat - kemarin proyek itu diakui sebagai terlindungi dengan baik, dan besok mereka dapat menambahkan beberapa layanan AWS baru, beberapa jenis database baru dan peran IAM baru. Pada saat yang sama, tidak akan segera menganalisis keamanan proyek. Hasilnya adalah bahwa pengembang menimbulkan risiko keamanan terbesar pada proyek mereka sendiri. Solusi untuk masalah ini adalah pelatihan mereka. Ini berarti bahwa setiap pengembang proyek web perlu membawa implementasi aturan keamanan hampir ke otomatisme, dan apa pun yang dilakukannya, selalu ingat keselamatan.
Setelah Anda memutuskan untuk bergerak ke arah ini, ternyata memperhitungkan keamanan saat melakukan pekerjaan apa pun tidak begitu menakutkan. Katakanlah, setelah membiasakan diri dengan metode dan alat umum untuk menyerang, buatlah diagram arsitektur aplikasi Anda dan pikirkan bagaimana Anda akan menyerangnya. Seiring waktu, bahkan tanpa memberi diri Anda laporan dalam hal ini, Anda akan mulai mempertimbangkan masalah keamanan akun, membuat setiap keputusan arsitektur dan memasukkan setiap baris kode baru di editor. Berikut adalah beberapa ide untuk mengelola masalah keamanan:
- Coba OWASP ZAP - alat multi-fungsional untuk meneliti sistem dan peretasan, yang memungkinkan bahkan pemula untuk mempelajari tingkat keamanan aplikasi.
- Lihatlah daftar rekomendasi keamanan Node.js ini untuk lebih dari dua lusin ide serangan dan contoh kode JavaScript.
- Jadwalkan pertemuan analisis ancaman bulanan di mana tim proyek akan mempelajari arsitekturnya dan menawarkan serangan terhadapnya. Jika ide seperti itu terasa membosankan bagi Anda - Anda dapat melakukan gamifikasi rapat semacam itu. Katakanlah, mereka yang menemukan kerentanan dapat diberi imbalan entah bagaimana. Anda juga dapat, misalnya, membagi peserta dari pertemuan semacam itu menjadi dua tim dan mengatur kompetisi di antara mereka untuk menemukan kerentanan.
11. Merancang dan mengimplementasikan strategi pembaruan paket npm. 2018 menunjukkan bahwa tergesa-gesa saat memperbarui mereka berbahaya
Biasanya, tim pengembangan mematuhi satu dari dua "strategi" untuk memperbarui paket npm. Mereka memperbarui mereka secepat mungkin setelah rilis versi baru mereka, kadang-kadang bahkan mengotomatiskan proses ini, atau tidak memiliki strategi pembaruan paket sama sekali. Dengan pendekatan ini, paket diperbarui secara tidak teratur, dan, memulai proses ini, mereka dipandu oleh sesuatu seperti pemikiran tiba-tiba: "Haruskah kita diperbarui hari ini?" Meskipun yang pertama dari pendekatan ini terlihat lebih baik dari yang kedua, ternyata secara tak terduga dikaitkan dengan risiko yang lebih tinggi pada tahun 2018 daripada yang kedua. Masalah, seperti yang terjadi pada paket
flat-stream , ditemukan oleh komunitas dalam beberapa lusin hari, dan mereka yang tidak tergesa-gesa untuk memperbarui aman.
Pertimbangkan memformalkan strategi untuk memperbarui paket yang tergantung pada proyek Anda, pertimbangkan untuk menggunakan alat otomatisasi untuk proses ini. Temukan jalan tengah antara menolak pembaruan dan memperbarui paket terlalu sering. Di sini program
npq dapat membantu
Anda , yang memeriksa paket selama instalasi dan memberikan rekomendasi. Anda dapat melihat proyek komersial seperti
penjaga hijau . Kerugian dari solusi tersebut adalah bahwa mereka tidak dapat menunda instalasi sampai saat ketika akan sangat jelas bahwa paket tertentu aman.
12. Lihatlah lebih dekat pada penyebaran proyek secara bertahap
Mungkin pada tahun 2019 Anda akan menganggap pantas untuk menyebarkan proyek dalam produksi menggunakan skema bertahap, dan tidak dengan langsung mengirim segala sesuatu yang sebelumnya dalam proses pengembangan ke server tempur. Proses ini disebut "penyebaran kenari", ini memberikan tingkat perlindungan proyek yang lebih tinggi daripada penyebaran kode baru secara simultan. Biasanya membedakan tiga tahap berikut:
- Penempatan Kode baru ini digunakan dalam lingkungan produksi baru yang terisolasi (pada layanan Kubernet baru, pada server virtual baru). Pada tahap ini, kode belum melayani siapa pun, oleh karena itu, kegagalan di dalamnya tidak dapat menyebabkan kerusakan.
- Pengujian. Sekarang, beberapa spesialis dapat bekerja dengan kode baru dalam kondisi sedekat mungkin dengan yang asli, karena kode tersebut digunakan dalam produksi.
- Lepaskan Setelah pengujian menunjukkan operabilitas kode baru, secara bertahap diberikan akses ke semakin banyak pengguna, dan setelah ternyata itu bekerja cukup andal, versi yang lama secara bertahap dikeluarkan dari penggunaan.
Salah satu poin penting untuk dibuat di sini adalah bahwa melakukan penyebaran kenari skala penuh pada tahun 2019 masih akan menjadi kesenangan yang sangat mahal. Faktanya adalah ini membutuhkan koordinasi pekerjaan elemen infrastruktur proyek - seperti perutean dan pemantauan. Jadi, jika Anda ingin menerapkan teknik yang sama, Anda harus mulai dengan penyebaran kenari yang sederhana, sebagian manual. Secara khusus, ini terdiri dari kenyataan bahwa setelah berhasil menyelesaikan tes pertama, dengan mempertimbangkan indikator pemantauan, penambahan manual server dengan versi baru dari perangkat lunak ke sistem dilakukan. Baca lebih lanjut tentang rilis kenari di
sini . Jika Anda ingin mengotomatiskan proses melakukan rilis seperti itu, perhatikan platform
Spinnaker .
13. Lihatlah teknologi Kubernetes yang telah menaklukkan dunia.
Kubernetes (K8S) , . - . . Kubernetes , , 54% K8S-. —
. K8S — , :
, , Kubernetes, .
14. -,
- — . , .
15. , , ,
, — . , . . , (,
tensorflow.js brain.js , , ).
16.
, . , , . , — .
17. Linux, —
Linux- , , . — , ( — ), Docker, . , , , , , .
, Linux.
18. , Node.js
( Node.js): « . , ». , , ( ). , Node.js, , V8 libuv. , 2019 — , Node.js, , , libuv. , , , Node.js - , .
, .
, npm- C/C++.
Node.js.
Node.js RUVDS.
19. ,
, , . , , , , , . , , , , . JavaScript-, . , JavaScript, . , , TypeScript . flow , , . , - flow, , , , « , ». ? , , «
». , - . , , , — . . , - , , , . , . , 2019 , — .
.
, . — , , , , , , . , , , , , .
Ringkasan
19 , Node.js-, - , 2019 . , - , .
Pembaca yang budiman! Node.js- 2019 ?
