Top 5 Kesalahan yang dibuat Pengembang Node

Node adalah platform yang fantastis untuk menulis backend. Kecuali ketika Anda tidak melakukan sesuatu dengan benar.


Bergantung pada sisi mana pagar Anda berada, Node adalah yang terbaik atau yang terburuk terjadi pada dunia Web Development. Namun, meskipun ada pendapat, tidak ada yang memperdebatkan popularitas Node. Ini melonjak dalam popularitas jauh lebih cepat daripada yang diperkirakan siapa pun, bahkan penciptanya (katanya dengan pesimistis wawancara)!

Saat menulis, ini adalah platform default untuk memulai aplikasi baru, yang saya akui sering kali merupakan hasil dari mentalitas kawanan, tetapi efek utamanya adalah bahwa ada lebih banyak pekerjaan, lebih banyak uang, dan lebih banyak proyek menarik di Node daripada di bahasa skrip tradisional lainnya.

Sayangnya, ketika seseorang meminta saya untuk merekomendasikan mereka setumpuk awal untuk pengembangan web atau produk startup baru, Node adalah rekomendasi nomor 1 saya meskipun saya fasih dalam PHP dan Laravel.

Jika saya mungkin diizinkan untuk melanjutkan kata-kata kasar sedikit (yang akan saya lakukan karena saya yang menulis?), Pembenci Node ada benarnya ketika mereka mengatakan bahwa tumpukan web favorit mereka dapat melakukan hal-hal seperti halnya Node, tetapi yang sebaliknya juga benar. Dan kemudian ada hal-hal pemrograman dan acara async, yang dimasukkan ke Node dari hari 1, dan ekosistem lainnya sekarang mati-matian berusaha untuk menyalin.

Hari ini kami memiliki opsi async dalam PHP dan Python, tetapi sayangnya, inti dari perpustakaan populer yang ada adalah murni sinkron, sehingga hampir seperti Anda berperang melawan sistem. Tapi ngomong-ngomong, cukup gembar-gembor selama sehari. ��

Jadi, jika Anda adalah pengembang Node (pemula atau yang akrab), kemungkinan Anda membuat salah satu kesalahan besar ini yang berdampak negatif pada aplikasi Anda. Mungkin karena Anda tidak terbiasa dengan cara tertentu dalam melakukan sesuatu yang lebih baik di Node, atau mungkin itu hanya kebiasaan yang Anda bawa dari ekosistem lain.

Tidak menghormati loop acara

Ketika seseorang bermigrasi ke Node, itu sebagian karena mereka telah mendengar cerita tentang bagaimana skala timbang menggunakan Node, atau mereka telah melihat tolok ukur yang menunjukkan Node menjalankan lingkaran di sekitar PHP, Ruby, dll. Ketika datang untuk melayani permintaan per detik atau menangani koneksi soket terbuka.

Jadi mereka membangun aplikasi mereka, mengharapkan waktu respons ledakan yang sama seperti yang mereka impikan – kecuali bahwa tidak ada yang dekat dengan itu terjadi.

Salah satu alasan utama untuk ini adalah tidak memahami loop acara dengan benar. Pertimbangkan kode berikut yang mendapat satu set buku dari database dan kemudian urutkan berdasarkan jumlah halaman:

db.Library.get (libraryId, function (err, library) {
biarkan buku = library.books;
books.sort (fungsi (a, b) {
kembalikan halaman < halaman -1: 1
});
});

Saya setuju bahwa kode ini tidak melakukan apa pun dengan susunan buku yang diurutkan, tetapi bukan itu intinya di sini. Intinya adalah bahwa kode yang tampak tidak bersalah itu cukup untuk meledakkan loop acara segera setelah Anda mulai berurusan dengan jumlah buku yang tidak sepele..

Alasannya adalah bahwa loop acara dimaksudkan untuk melakukan I / O yang tidak menghalangi. Contoh yang baik adalah pengepak pizza di tempat pizza – orang yang mengkhususkan diri dalam memotong pizza, melipat penutup ke dalam kotak pengiriman, memasukkan pizza ke dalam, menempelkan label yang tepat, dan mendorongnya ke petugas pengiriman.

Luar biasa bukan? Sama seperti Node!

Sumber: stackoverflow.com

Tetapi pertimbangkan apa yang akan terjadi jika orang ini juga perlu mencampur, menyiapkan dan mengemas bumbu. Tergantung pada seberapa rumit prosesnya, tingkat pengemasan pizza akan dikurangi menjadi sepertiga, atau bahkan mungkin berhenti total..

Inilah yang kami maksudkan dengan tugas-tugas yang “memblokir” – selama Node hanya perlu menyampaikan informasi, itu sangat cepat dan idealnya merupakan pilihan terbaik, tetapi segera setelah itu perlu melakukan beberapa perhitungan yang luas, berhenti, dan semuanya yang lain harus menunggu. Ini terjadi karena loop peristiwa adalah single-threaded (detail lebih lanjut sini.)

Jadi, jangan melakukan perhitungan dalam loop acara, tidak peduli betapa pentingnya mereka. Maksud saya, menambahkan angka dan mengambil rata-rata baik-baik saja, tetapi kumpulan data besar akan membuat aplikasi Node Anda merangkak.

Berharap kode async akan bekerja sama

Pertimbangkan contoh Node yang sangat sederhana ini yang membaca data dari suatu file dan menampilkannya:

const fs = membutuhkan (‘fs’);

biarkan konten = fs.readFile (‘secret.txt’, (err, data) => {
mengembalikan data;
});

console.log (‘Konten file adalah:’);
console.log (konten);

Paparan ke bahasa klasik (seperti PHP, Python, Perl, Ruby, C ++, dll.) Akan membuat Anda menerapkan akal sehat bahwa setelah kode ini berjalan, konten variabel akan memiliki konten file. Tapi inilah yang terjadi ketika Anda benar-benar mengeksekusi kode:

Kami tidak terdefinisi (). Itu karena sementara Anda mungkin sangat peduli tentang Node, sifat asyncnya tidak peduli tentang Anda (itu dimaksudkan sebagai lelucon! Tolong jangan spam komentar kebencian di sini ��). Tugas kita adalah memahami sifat asinksinya dan bekerja dengannya. readFile () adalah fungsi asinkron, yang berarti segera setelah dipanggil, loop peristiwa Node meneruskan pekerjaan ke komponen sistem file dan melanjutkan.

Itu kembali ke fungsi nanti ketika file telah dibaca, tetapi pada saat itu konten diperlakukan seperti variabel yang tidak diinisialisasi dan dengan demikian berisi tidak terdefinisi. Cara yang benar adalah memproses data file di dalam fungsi panggilan balik, tapi saya tidak bisa masuk ke detail lebih lanjut karena ini bukan Node tutorial. ��

Panggilan balik yang memanggil panggilan balik yang memanggil panggilan balik yang memanggil . . .

JavaScript lebih dekat ke pemrograman fungsional yang lebih tua, bahasa utama lainnya (pada kenyataannya, semua dikatakan dan dilakukan, itu adalah favorit saya ketika datang ke desain berorientasi objek dan kemampuan fungsional – saya meletakkannya di atas Python, PHP, Perl, Java, dan bahkan Ruby ketika menulis kode “menyenangkan”).

Artinya, fungsi mendapatkan lebih banyak hak warga negara daripada yang mereka lakukan dalam bahasa lain. Pasangan ini dengan fakta bahwa kode asinkron berfungsi dengan menyediakan Anda fungsi panggilan balik, dan kami akhirnya dengan resep untuk bencana yang dikenal sebagai Callback Hell.

Ini beberapa contoh kode Elektron yang saya temui di Quora. Menurut Anda apa yang dilakukannya?

opsi var;

membutuhkan (‘elektron’). app.once (
‘siap’,

function () {

options = {
bingkai: salah,
tinggi: 768,
lebar: 1024,
x: 0,
y: 0
};

options.BrowserWindow = membutuhkan (‘elektron’). BrowserWindow;
options.browserWindow = opsi baru.BrowserWindow (opsi);
options.browserWindow.loadURL (‘http://electron.atom.io’);
options.browserWindow.webContents.once (
‘did-stop-loading’,

function () {
options.browserWindow.capturePage (
pilihan,

fungsi (data) {
membutuhkan (‘fs’). writeFileSync (
‘/tmp/screenCapture.testExampleJs.browser..png’,
data.toPng ()
);

process.exit (0);
}
);
}
);
}
);

Jika Anda mengalami kesulitan, bergabunglah dengan klub!

Fungsi-fungsi di dalam fungsi-fungsi di dalam fungsi-fungsi sulit untuk dibaca dan sangat sulit untuk dipikirkan, itulah sebabnya ia disebut sebagai “panggilan balik neraka” (Saya kira Neraka adalah tempat yang membingungkan untuk keluar dari!). Meskipun ini secara teknis berfungsi, Anda membuat kode Anda menjadi bukti masa depan dari segala upaya pemahaman dan pemeliharaan.

Ada banyak cara untuk menghindari neraka panggilan balik, termasuk Janji dan Ekstensi reaktif.

Tidak menggunakan semua core CPU

Prosesor modern memiliki beberapa core – 2, 4, 8, 16, 32. . . jumlahnya terus bertambah.

Tapi ini bukan yang ada di pikiran pencipta Node ketika dia merilis Node. Akibatnya, Node adalah single-threaded, yang artinya berjalan di dalam satu thread (atau proses, jika Anda ingin menyebutnya demikian, meskipun tidak sama), hanya menggunakan satu inti CPU.

Itu berarti jika Anda mempelajari Node dari tutorial dan teman dan cuplikan kode melayang-layang, dan membuat aplikasi Anda digunakan pada server 8-core, Anda menyia-nyiakan 7/8 dari daya pemrosesan yang tersedia!

Tak perlu dikatakan, ini adalah pemborosan besar. Jika Anda mengikuti jalur ini, Anda akan membayar delapan server saat Anda hanya membutuhkan satu. Artinya, belanjakan $ 16.000 per bulan ketika $ 2.000 akan lakukan (kehilangan uang selalu menyakitkan, bukan?). Semua ini, ketika solusinya cukup sederhana: menggunakan gugus modul.

Saya tidak bisa membahas semua detail di sini, tetapi ini adalah teknik sederhana untuk mendeteksi berapa banyak core yang dimiliki mesin saat ini, dan kemudian meluncurkan banyak instance Node. Ketika kesalahan terdeteksi, instance dimulai kembali. Begini sederhananya untuk mengimplementasikan (tutorial sini):

var cluster = butuhkan (‘cluster’);

if (cluster.isMaster) {
var numWorkers = membutuhkan (‘os’). cpus (). length;

console.log (‘Pengaturan klaster master’ + numWorkers + ‘pekerja …’);

untuk (var i = 0; i < jumlah pekerja; i ++) {
cluster.fork ();
}

cluster.on (‘online’, fungsi (pekerja) {
console.log (‘Pekerja’ + pekerja.process.pid + ‘sedang online’);
});

cluster.on (‘keluar’, fungsi (pekerja, kode, sinyal) {
console.log (‘Pekerja’ + pekerja.process.pid + ‘mati dengan kode:’ + kode + ‘, dan sinyal:’ + sinyal);
console.log (‘Memulai pekerja baru’);
cluster.fork ();
});
} lain {
var app = require (‘express’) ();
app.all (‘/ *’, function (req, res) {res.send (‘process’ + process.pid + ‘say hello!’). end ();})

var server = app.listen (8000, function () {
console.log (‘Proses’ + process.pid + ‘mendengarkan semua permintaan yang masuk’);
});
}

Seperti yang Anda lihat, cluster.fork () melakukan keajaiban, dan sisanya hanya mendengarkan beberapa peristiwa penting cluster dan melakukan pembersihan yang diperlukan.

Tidak menggunakan TypeScript

Oke, itu bukan kesalahan, karena itu, dan banyak aplikasi Node telah dan sedang ditulis tanpa TypeScript.

Yang mengatakan, TypeScript menawarkan jaminan dan ketenangan pikiran bahwa Node selalu dibutuhkan, dan di mata saya, itu adalah kesalahan jika Anda mengembangkan untuk Node pada 2019 dan tidak menggunakan TypeScript (terutama ketika A (Angular) di tumpukan MEAN dipindahkan ke TypeScript dulu).

Transisinya lembut, dan TypeScript hampir persis seperti JavaScript yang Anda tahu, dengan surety of types, ES6, dan beberapa cek lainnya dilemparkan ke dalam:

// /lib/controllers/crmController.ts
impor * sebagai luwak dari ‘luwak’;
impor {ContactSchema} dari ‘../models/crmModel’;
impor {Request, Response} dari ‘express’;

const Contact = mongoose.model (‘Kontak’, ContactSchema);
kelas ekspor ContactController {

addNewContact publik (req: Request, res: Response) {
biarkan newContact = Kontak baru (req.body);

newContact.save ((err, contact) => {
if (err) {
res.send (err);
}
res.json (kontak);
});
}

Saya sarankan memeriksa ini baik dan ramah Tutorial TypeScript.

Kesimpulan

Node memang mengesankan, tetapi bukan tanpa masalah (banyak?). Yang mengatakan, ini berlaku untuk semua teknologi di luar sana, baru dan lama, dan kami akan lebih baik untuk memahami Node dan bekerja dengannya.

Saya harap lima tips ini akan mencegah Anda terhisap ke dalam lubang tar bug dan masalah kinerja abadi. Jika saya melewatkan sesuatu yang menarik, beri tahu saya, dan saya akan lebih dari senang (sebenarnya, berterima kasih!) Untuk memasukkannya ke dalam artikel. ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map