Bagaimana cara memutuskan kapan akan menggunakan Node.js?


2195

Saya baru untuk hal semacam ini, tapi belakangan ini saya telah mendengar banyak tentang seberapa baik Node.js adalah. Mempertimbangkan seberapa besar saya suka bekerja dengan jQuery dan JavaScript secara umum, saya tidak bisa tidak bertanya-tanya bagaimana memutuskan kapan harus menggunakan Node.js. Aplikasi web yang ada dalam pikiran saya adalah sesuatu seperti Bitly - mengambil beberapa konten, mengarsipkannya.

Dari semua pekerjaan rumah yang telah saya lakukan dalam beberapa hari terakhir, saya memperoleh informasi berikut. Node.js

  • adalah alat baris perintah yang dapat dijalankan sebagai server web biasa dan memungkinkan seseorang menjalankan program JavaScript
  • menggunakan mesin JavaScript V8 yang hebat
  • sangat baik ketika Anda perlu melakukan beberapa hal sekaligus
  • berbasis acara sehingga semua hal yang mirip Ajax bisa dilakukan di sisi server
  • memungkinkan kami berbagi kode antara browser dan backend
  • mari kita bicara dengan MySQL

Beberapa sumber yang saya temui adalah:

Mempertimbangkan bahwa Node.js dapat dijalankan hampir di luar kotak pada contoh EC2 Amazon , saya mencoba untuk memahami jenis masalah apa yang memerlukan Node.js sebagai lawan dari salah satu raja perkasa di luar sana seperti PHP , Python dan Ruby . Saya mengerti bahwa itu benar-benar tergantung pada keahlian yang dimiliki seseorang pada suatu bahasa, tetapi pertanyaan saya lebih banyak masuk ke dalam kategori umum: Kapan menggunakan kerangka kerja tertentu dan jenis masalah apa yang cocok untuknya?


4
Pertanyaan ini sedang dibahas di meta ( meta.stackoverflow.com/q/332386/497418 ).
zzzzBov

Jawaban:


1355

Anda melakukan pekerjaan yang hebat untuk meringkas apa yang hebat tentang Node.js. Perasaan saya adalah Node.js sangat cocok untuk aplikasi di mana Anda ingin mempertahankan koneksi terus-menerus dari browser kembali ke server. Menggunakan teknik yang dikenal sebagai "polling panjang" , Anda dapat menulis aplikasi yang mengirimkan pembaruan kepada pengguna secara real time. Melakukan polling panjang pada banyak raksasa web, seperti Ruby on Rails atau Django , akan menciptakan beban yang sangat besar di server, karena setiap klien yang aktif memakan satu proses server. Situasi ini sama dengan serangan tarpit . Ketika Anda menggunakan sesuatu seperti Node.js, server tidak perlu mempertahankan utas terpisah untuk setiap koneksi yang terbuka.

Ini berarti Anda dapat membuat aplikasi obrolan berbasis browser di Node.js yang hampir tidak memerlukan sumber daya sistem untuk melayani banyak klien. Kapan pun Anda ingin melakukan polling panjang ini, Node.js adalah pilihan yang bagus.

Layak disebutkan bahwa Ruby dan Python keduanya memiliki alat untuk melakukan hal semacam ini ( masing-masing mesin dan memutar ), tetapi Node.js melakukannya dengan sangat baik, dan dari bawah ke atas. JavaScript sangat baik terletak pada model konkurensi berbasis panggilan balik, dan unggul di sini. Juga, bisa membuat serial dan deserialize dengan JSON asli ke klien dan server cukup bagus.

Saya berharap dapat membaca jawaban lain di sini, ini adalah pertanyaan yang fantastis.

Perlu ditunjukkan bahwa Node.js juga bagus untuk situasi di mana Anda akan menggunakan kembali banyak kode di celah klien / server. The kerangka Meteor membuat ini sangat mudah, dan banyak orang menyarankan ini mungkin menjadi masa depan pengembangan web. Saya dapat mengatakan dari pengalaman bahwa sangat menyenangkan untuk menulis kode di Meteor, dan sebagian besar dari ini menghabiskan lebih sedikit waktu untuk memikirkan bagaimana Anda akan merestrukturisasi data Anda, sehingga kode yang berjalan di browser dapat dengan mudah memanipulasi dan mengembalikannya.

Inilah artikel tentang Piramida dan polling panjang, yang ternyata sangat mudah dibuat dengan sedikit bantuan dari gevent: TicTacToe dan Polling Panjang dengan Piramida .


12
Ya, saya pikir sangat penting untuk berpikir bahwa 'node.js sangat cocok untuk aplikasi yang memerlukan koneksi terus-menerus dari browser kembali ke server. - seperti program obrolan, atau permainan interaktif 'Jika seseorang hanya membangun aplikasi yang tidak perlu komunikasi pengguna / server, pengembangan dengan kerangka kerja lain akan baik-baik saja dan akan memakan waktu lebih sedikit.
user482594

1
Terima kasih untuk ini ... Q dan A yang hebat ;-) Saya juga akan memikirkannya dalam hal menguasai satu teknologi hebat untuk pengembangan depan dan belakang atas beberapa yang berbeda;)
Stokedout

12
Mengapa menggunakan polling panjang? Apa yang terjadi dengan masa depan dan soket ?
hitautodestruct

1
Jawaban singkat saya adalah proses latar belakang. Permintaan dan tanggapan (termasuk API sisanya) semua dapat dicapai dengan bahasa dan server lain. Jadi bagi mereka yang berpikir untuk mengubah proyek web mereka dalam node. Pikirkan lagi hal yang sama! Gunakan simpul sebagai proses latar belakang seperti membaca email dengan imap, pemrosesan gambar, mengunggah file ke cloud, atau proses panjang atau tanpa akhir yang sebagian besar berorientasi pada peristiwa ...
Vikas

409

Saya percaya Node.js paling cocok untuk aplikasi waktu nyata: game online, alat kolaborasi, ruang obrolan, atau apa pun yang dilakukan oleh satu pengguna (atau robot? Atau sensor?) Dengan aplikasi perlu dilihat oleh pengguna lain segera, tanpa refresh halaman.

Saya juga harus menyebutkan bahwa Socket.IO dalam kombinasi dengan Node.js akan mengurangi latensi real-time Anda lebih jauh dari apa yang mungkin terjadi dengan polling yang lama. Socket.IO akan kembali ke polling lama sebagai skenario terburuk, dan alih-alih menggunakan soket web atau bahkan Flash jika tersedia.

Tetapi saya juga harus menyebutkan bahwa hampir semua situasi di mana kode mungkin memblokir karena utas dapat lebih baik ditangani dengan Node.js. Atau situasi apa pun di mana Anda memerlukan aplikasi untuk dikendalikan oleh peristiwa.

Juga, Ryan Dahl mengatakan dalam sebuah pembicaraan bahwa saya pernah menghadiri bahwa tolok ukur Node.js sangat menyaingi Nginx untuk permintaan HTTP lama yang biasa. Jadi jika kita membangun dengan Node.js, kita dapat melayani sumber daya normal kita dengan cukup efektif, dan ketika kita membutuhkan hal-hal yang digerakkan oleh peristiwa, ia siap menanganinya.

Ditambah lagi itu semua JavaScript sepanjang waktu. Lingua Franca di seluruh tumpukan.


17
Hanya sebuah pengamatan dari seseorang yang beralih antara .Net dan Node, Bahasa yang berbeda untuk area yang berbeda dari sistem membantu banyak ketika pengalihan konteks. Ketika saya melihat Javascript, saya bekerja di Klien, C # berarti Server Aplikasi, SQL = database. Bekerja dalam Javascript di seluruh, saya menemukan diri saya membingungkan lapisan, atau hanya butuh waktu lebih lama untuk konteks-switch. Ini kemungkinan merupakan artefak yang bekerja pada .NET stack sepanjang hari dan Noding pada malam hari, tetapi itu membuat perbedaan.
Michael Blackburn

9
Yang menarik, praktik individu lintas budaya beralih dialek ketika bergerak antara budaya mainstream dan asli disebut "alih kode."
Michael Blackburn

1
Beberapa hari yang lalu saya berpikir tentang bagaimana saya bisa menetapkan warna berbeda ke .jsfile saya yang berbeda . Hijau untuk sisi klien, biru untuk sisi server. Saya terus "tersesat" sendiri.
AJB

209

Alasan menggunakan NodeJS:

  • Ini menjalankan Javascript, sehingga Anda dapat menggunakan bahasa yang sama di server dan klien, dan bahkan berbagi beberapa kode di antara mereka (misalnya untuk validasi formulir, atau untuk membuat tampilan di kedua ujungnya.)

  • Sistem yang digerakkan oleh single-threaded sangat cepat bahkan ketika menangani banyak permintaan sekaligus, dan juga sederhana, dibandingkan dengan kerangka kerja Java atau ROR tradisional multi-threaded .

  • Kumpulan paket yang terus tumbuh dapat diakses melalui NPM , termasuk pustaka / modul sisi klien dan server, serta alat baris perintah untuk pengembangan web. Sebagian besar di-host dengan nyaman di github, di mana kadang-kadang Anda dapat melaporkan masalah dan menemukannya dalam hitungan jam! Sangat menyenangkan memiliki segalanya dalam satu atap, dengan pelaporan masalah terstandarisasi dan forking yang mudah.

  • Ini telah menjadi lingkungan standar defacto di mana untuk menjalankan alat terkait Javascript dan alat terkait web lainnya , termasuk pelari tugas, minifiers, beautifiers, linter, preprocessor, bundlers dan prosesor analitik.

  • Tampaknya cukup cocok untuk membuat prototipe, pengembangan gesit dan iterasi produk yang cepat .

Alasan tidak menggunakan NodeJS:

  • Ini menjalankan Javascript, yang tidak memiliki pemeriksaan tipe waktu kompilasi. Untuk sistem besar yang kritis-keselamatan , yang rumit , atau proyek termasuk kolaborasi antara organisasi yang berbeda, bahasa yang mendorong antarmuka kontrak dan menyediakan pemeriksaan tipe statis dapat menghemat waktu debugging (dan ledakan ) dalam jangka panjang. (Meskipun JVM macet null, jadi silakan gunakan Haskell untuk reaktor nuklir Anda.)

  • Selain itu, banyak paket dalam NPM sedikit mentah , dan masih dalam pengembangan cepat. Beberapa perpustakaan untuk kerangka kerja yang lebih lama telah mengalami satu dekade pengujian dan perbaikan bug, dan sangat stabil sekarang. Npmjs.org tidak memiliki mekanisme untuk memeringkat paket , yang menyebabkan proliferasi paket melakukan hal yang kurang lebih sama, di mana sebagian besar tidak lagi dipertahankan.

  • Callback bersarang neraka. (Tentu saja ada 20 solusi berbeda untuk ini ...)

  • Kumpulan paket yang terus tumbuh dapat membuat satu proyek NodeJS tampak sangat berbeda dari yang lain. Ada keragaman besar dalam implementasi karena banyaknya pilihan yang tersedia (misalnya Express / Sails.js / Meteor / Derby ). Ini kadang-kadang dapat mempersulit pengembang baru untuk ikut serta dalam proyek Node. Bandingkan dengan pengembang Rails yang bergabung dengan proyek yang sudah ada: ia harus bisa mengenal aplikasi dengan cepat, karena semua aplikasi Rails didorong untuk menggunakan struktur yang sama .

  • Berurusan dengan file bisa sedikit menyusahkan. Hal-hal yang sepele dalam bahasa lain, seperti membaca baris dari file teks, cukup aneh untuk dilakukan dengan Node.js bahwa ada pertanyaan StackOverflow dengan 80+ upvotes. Tidak ada cara sederhana untuk membaca satu catatan pada satu waktu dari file CSV . Dll

Saya suka NodeJS, cepat dan liar, dan menyenangkan, tetapi saya khawatir ini kurang tertarik pada kebenaran yang bisa dibuktikan. Semoga saja kita bisa menggabungkan yang terbaik dari kedua dunia. Saya ingin melihat apa yang akan menggantikan Node di masa depan ... :)


1
@nane Ya saya pikir mereka dapat mengatasi masalah itu, namun Anda kemudian harus membatasi diri Anda hanya menggunakan perpustakaan yang ditulis dalam bahasa typesafe, atau menerima bahwa tidak semua basis kode Anda diketik secara statis. Namun ada satu argumen: karena Anda harus menulis tes yang baik untuk kode Anda terlepas dari bahasanya, maka tingkat kepercayaan Anda harus sama bahkan untuk kode yang diketik secara dinamis. Jika kami menerima argumen itu, maka keuntungan dari pengetikan yang kuat dikurangi untuk membantu mengembangkan / men-debug waktu, kemampuan, dan pengoptimalan .
joeytwiddle

1
@kervin, saya setuju beberapa tolok ukur akan bagus, tapi saya kecewa dengan apa yang bisa saya temukan online. Beberapa orang berpendapat bahwa kinerja .NET sebanding dengan Node, tetapi sangat penting apa yang sebenarnya Anda lakukan. Node mungkin hebat dalam menyampaikan pesan-pesan kecil dengan banyak koneksi bersamaan, tetapi tidak begitu bagus untuk perhitungan matematika yang berat. Perbandingan kinerja yang baik perlu menguji berbagai situasi.
joeytwiddle

2
@ joeytwiddle tidak akan hal-hal seperti Typescript membantu Node.js ketika datang untuk menangani program kompleks yang lebih besar dan pemeriksaan ketik statis?
CodeMonkey

2
@ joeytwiddle untuk apa nilainya, Anda dapat menggunakan stillmaintained.com untuk menentukan apakah paket npm masih dipertahankan (karena mayoritasnya ada di github). Selain itu, npm searchdan npm showakan menunjukkan tanggal rilis terakhir paket kepada Anda.
Dan Pantry

3
Dengan membandingkan rel ke simpul, Anda membingungkan platform dengan kerangka kerja. Rails adalah kerangka kerja untuk Ruby seperti Sails dan meteor adalah kerangka kerja untuk Javascript.
BonsaiOak

206

Singkatnya:

Node.js sangat cocok untuk aplikasi yang memiliki banyak koneksi konkuren dan setiap permintaan hanya membutuhkan siklus CPU yang sangat sedikit, karena loop acara (dengan semua klien lain) diblokir selama pelaksanaan fungsi.

Sebuah artikel yang baik tentang loop acara di Node.js adalah blog teknologi Mixu ini: Memahami node.js loop acara .


127

Saya punya satu contoh dunia nyata di mana saya menggunakan Node.js. Perusahaan tempat saya bekerja mendapat satu klien yang ingin memiliki situs web HTML statis sederhana. Situs web ini untuk menjual satu item menggunakan PayPal dan klien juga ingin memiliki penghitung yang menunjukkan jumlah item yang terjual. Klien diharapkan memiliki sejumlah besar pengunjung ke situs web ini. Saya memutuskan untuk membuat konter menggunakan Node.js dan kerangka Express.js .

Aplikasi Node.js sederhana. Dapatkan jumlah item yang terjual dari basis data Redis , tambah penghitung saat item dijual dan sajikan nilai penghitung kepada pengguna melalui API .

Beberapa alasan mengapa saya memilih untuk menggunakan Node.js dalam kasus ini

  1. Ini sangat ringan dan cepat. Sudah ada lebih dari 200000 kunjungan di situs web ini dalam tiga minggu dan sumber daya server minimal telah mampu menangani semuanya.
  2. Penghitungnya sangat mudah dibuat menjadi waktu nyata.
  3. Node.js mudah dikonfigurasi.
  4. Ada banyak modul yang tersedia secara gratis. Misalnya, saya menemukan modul Node.js untuk PayPal.

Dalam hal ini, Node.js adalah pilihan yang luar biasa.


7
Bagaimana Anda meng-host sesuatu seperti itu? Apakah Anda harus mengatur nodejs di server produksi? Di linux?
Miguel Stevens

1
Ada beberapa PaaS seperti nodejitsu dan Heroku. Atau Anda memang dapat mengatur nodejs pada kotak linux yaitu dari amazon ec2. lihat: lauradhamilton.com/...
harry young

13
200.000 kunjungan dalam 1.814.400 detik. Tidak relevan sama sekali. Bahkan bash dapat melayani banyak permintaan itu, di server yang paling lambat. Server awal. VM paling lambat.
Tiberiu-Ionuț Stan

105

Alasan paling penting untuk memulai proyek Anda berikutnya menggunakan Node ...

  • Semua cowok paling keren ada di dalamnya ... jadi pasti menyenangkan.
  • Anda dapat hangout di pendingin dan memiliki banyak petualangan Node untuk dibanggakan.
  • Anda penny pincher ketika datang ke cloud hosting.
  • Telah ada yang melakukannya dengan Rails
  • Anda membenci penyebaran IIS
  • Pekerjaan IT lama Anda menjadi agak membosankan dan Anda berharap berada dalam Start Up baru yang mengkilap.

Apa yang diharapkan ...

  • Anda akan merasa aman dan aman dengan Express tanpa semua server bloatware yang tidak pernah Anda butuhkan.
  • Berjalan seperti roket dan sisik dengan baik.
  • Kamu memimpikannya. Anda menginstalnya. Paket simpul repo npmjs.org adalah ekosistem pustaka sumber terbuka terbesar di dunia.
  • Otak Anda akan mendapatkan waktu bengkok di tanah panggilan balik bersarang ...
  • ... sampai Anda belajar untuk menepati janji Anda .
  • Sekuel dan Paspor adalah teman API baru Anda.
  • Mendebug sebagian besar kode async akan mendapatkan umm ... menarik .
  • Saatnya semua Noders untuk menguasai Script .

Siapa yang menggunakannya?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • Inilah mengapa mereka beralih ke Node .

18
Ya saya bisa menjawab pertanyaan ini dengan cara tradisional. Saya pikir saya memenuhi syarat untuk melakukannya tetapi sebagian besar sudah dikatakan dan saya pikir beberapa kesenangan ringan akan merusak kebodohan. Saya secara teratur menyumbangkan jawaban teknis untuk pertanyaan lain.
Tony O'Hagan

1
panggilan balik bersarang dapat dihindari dengan menggunakan generator ES6 untuk kode async
refactor

1
@CleanCrispCode: Ya benar! ES6 telah mengadopsi gaya C # async/ awaitjadi sekarang kita dapat meluncurkan kode Node async yang jauh lebih bersih yang juga mendukung tradisional try/ catch. Pada 2016/17 JS coders beralih ke ES6.
Tony O'Hagan

1
sepuluh ribu kali ini "Anda akan merasa aman dan aman dengan Express tanpa semua server bloatware yang tidak pernah Anda butuhkan"
Simone Poggi

60

Tidak ada yang seperti Silver Bullet. Semuanya datang dengan biaya yang terkait dengannya. Ini seperti jika Anda makan makanan berminyak, Anda akan membahayakan kesehatan Anda dan makanan sehat tidak datang dengan rempah-rempah seperti makanan berminyak. Ini adalah pilihan individu apakah mereka menginginkan kesehatan atau rempah-rempah seperti dalam makanan mereka. Cara yang sama yang Node.js pertimbangkan untuk digunakan dalam skenario tertentu. Jika aplikasi Anda tidak sesuai dengan skenario itu, Anda sebaiknya tidak mempertimbangkannya untuk pengembangan aplikasi Anda. Saya hanya memikirkan hal yang sama:

Kapan menggunakan Node.JS

  1. Jika kode sisi server Anda memerlukan siklus cpu yang sangat sedikit. Di dunia lain Anda sedang melakukan operasi non pemblokiran dan tidak memiliki algoritma / Pekerjaan berat yang menghabiskan banyak siklus CPU.
  2. Jika Anda berasal dari Javascript latar belakang dan nyaman dalam menulis kode Threaded Tunggal seperti sisi klien JS.

Kapan TIDAK menggunakan Node.JS

  1. Permintaan server Anda bergantung pada algoritma / Pekerjaan yang memakan banyak CPU.

Pertimbangan Skalabilitas dengan Node.JS

  1. Node.JS sendiri tidak menggunakan semua inti dari sistem yang mendasarinya dan itu adalah single threaded secara default, Anda harus menulis logika sendiri untuk menggunakan prosesor multi-core dan membuatnya multi-threaded.

Alternatif Node.JS

Ada pilihan lain untuk digunakan sebagai pengganti Node.JS namun Vert.x tampaknya cukup menjanjikan dan memiliki banyak fitur tambahan seperti poligot dan pertimbangan skalabilitas yang lebih baik.


24
Saya tidak yakin tentang "Jika permintaan sisi server Anda termasuk memblokir ops seperti File IO atau Socket IO" yang tercantum dalam "When NOT to use". Jika pemahaman saya benar, salah satu kekuatan dari node.js adalah, bahwa ia memiliki cara yang kuat dan asinkronik untuk menangani IO tanpa menghalangi. Jadi Node.js dapat dilihat sebagai "obat" untuk memblokir IO.
Ondrej Peterka

3
@OndraPeterka: Anda benar bahwa Node.js adalah obat untuk memblokir server IO, namun jika penangan permintaan Anda pada server itu sendiri membuat panggilan pemblokiran ke beberapa layanan web / operasi File lainnya, Node.js tidak akan membantu di sini. Ini bukan memblokir IO hanya untuk permintaan masuk ke server tetapi tidak untuk permintaan keluar dari penangan permintaan aplikasi Anda.
Ajay Tiwari

4
@ Mei dari nodejs.org mereka mengatakan "non-blocking I / O", silakan periksa "When NOT" 2 dan 3.
Omar Al-Ithawi

5
dengan versi saat ini, node sebenarnya mendukung dukungan multi-core dengan menggunakan cluster. Ini benar-benar meningkatkan kinerja aplikasi Node setidaknya dua kali. Namun, saya pikir kinerja harus lebih dari dua kali ketika mereka menstabilkan lib cluster.
Nam Nguyen

4
Anda dapat menggunakan node.js untuk perhitungan berat. Gunakan fork. Lihat stackoverflow.com/questions/9546225/… . Node menangani beberapa core dengan sangat baik dengan clustermodul. nodejs.org/api/cluster.html
Jess

41

Hal hebat lainnya yang menurut saya belum ada yang menyebutkan tentang Node.js adalah komunitas yang luar biasa, sistem manajemen paket (npm) dan jumlah modul yang ada yang dapat Anda sertakan dengan memasukkannya ke dalam file package.json Anda.


6
Dan paket-paket ini semuanya relatif segar, sehingga mereka memiliki manfaat dari belakang dan cenderung sesuai dengan standar web terbaru.
joeytwiddle

3
Dengan segala hormat, banyak paket di npm mengerikan, karena npm tidak memiliki mekanisme untuk menilai paket . Tinjau dari CPAN siapa saja?
Dan Dascalescu

Sayang sekali tidak ada perpustakaan websockets dapat memenuhi spesifikasi rfc 6455. fanboys node.js tuli, bisu dan buta ketika fakta ini diberikan.
r3wt

1
Saya tidak tahu tentang kapan Anda membuat komentar tetapi sampai sekarang perpustakaan ws mendukung spec itu
Jonathan Gray

37

Bagian saya: nodejs sangat bagus untuk membuat sistem waktu nyata seperti analitik, aplikasi chat, apis, server iklan, dll. Sial, saya membuat aplikasi chat pertama saya menggunakan nodejs dan socket.io kurang dari 2 jam dan itu juga selama minggu ujian!

Edit

Sudah beberapa tahun sejak saya mulai menggunakan nodejs dan saya telah menggunakannya dalam membuat berbagai hal termasuk server file statis, analitik sederhana, aplikasi obrolan dan banyak lagi. Ini adalah pendapat saya tentang kapan harus menggunakan nodejs

Kapan harus digunakan

Saat membuat sistem yang mengutamakan konkurensi dan kecepatan.

  • Soket hanya server seperti aplikasi obrolan, aplikasi irc, dll.
  • Jejaring sosial yang menekankan sumber daya waktu nyata seperti geolokasi, aliran video, aliran audio, dll.
  • Menangani potongan data kecil sangat cepat seperti webapp analytics.
  • Seperti mengekspos REST hanya api.

Kapan tidak digunakan

Ini adalah server web yang sangat serbaguna sehingga Anda dapat menggunakannya di mana pun Anda inginkan, tetapi mungkin bukan tempat-tempat ini.

  • Blog sederhana dan situs statis.
  • Sama seperti file server statis.

Perlu diingat bahwa saya hanya nitpicking. Untuk server file statis, apache lebih baik terutama karena tersedia secara luas. Komunitas nodejs telah tumbuh lebih besar dan lebih matang selama bertahun-tahun dan aman untuk mengatakan nodejs dapat digunakan di mana saja jika Anda memiliki pilihan hosting sendiri.


Blog sederhana masih dapat memanfaatkan Node.js. Untuk menyajikan file statis, Anda masih dapat menggunakan Node.js dan jika memuat meningkat, cukup tambahkan proxy reverse Nginx di depannya, sesuai praktik terbaik saat ini. Server Apache httpd adalah dinosaurus yang sekarat - lihat survei Netcraft ini .
Endrju

Saya akan mengatakan sebaliknya - lihat ghost.org , terlihat luar biasa dan dibangun di atas NodeJs - kolaborasi, pengeditan artikel waktu nyata. Juga, membuat halaman sederhana di NodeJs, katakanlah menggunakan sailsjs.org , mudah, cepat dan Anda tidak perlu repot-repot belajar bahasa pemrograman sisi server
Bery

30

Itu bisa digunakan dimana

  • Aplikasi yang sangat didorong oleh peristiwa & sangat terikat I / O
  • Aplikasi yang menangani sejumlah besar koneksi ke sistem lain
  • Aplikasi waktu nyata (Node.js dirancang dari bawah ke atas untuk waktu nyata dan agar mudah digunakan.)
  • Aplikasi yang menyulap kumpulan streaming informasi ke dan dari sumber lain
  • Lalu lintas tinggi, aplikasi yang dapat diukur
  • Aplikasi seluler yang harus berbicara dengan platform API & basis data, tanpa harus melakukan banyak analisis data
  • Bangun aplikasi jaringan
  • Aplikasi yang perlu berbicara dengan bagian belakang sangat sering

Di depan Mobile, perusahaan prime-time mengandalkan Node.js untuk solusi mobile mereka. Lihat mengapa?

LinkedIn adalah pengguna terkemuka. Seluruh tumpukan mobile mereka dibangun di atas Node.js. Mereka beralih dari menjalankan 15 server dengan 15 instance pada setiap mesin fisik, menjadi hanya 4 instance - yang dapat menangani lalu lintas dua kali lipat!

eBay meluncurkan ql.io, bahasa permintaan web untuk API HTTP, yang menggunakan Node.js sebagai tumpukan runtime. Mereka dapat menyetel workstation Ubuntu berkualitas pengembang biasa untuk menangani lebih dari 120.000 koneksi aktif per proses node.js, dengan setiap koneksi mengkonsumsi sekitar 2kB memori!

Walmart merekayasa ulang aplikasi selulernya untuk menggunakan Node.js dan mendorong pemrosesan JavaScript-nya ke server.

Baca lebih lanjut di: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/


20

Node terbaik untuk penanganan permintaan bersamaan -

Jadi, mari kita mulai dengan sebuah cerita. Dari 2 tahun terakhir saya mengerjakan JavaScript dan mengembangkan web front end dan saya menikmatinya. Back end guys berikan kita beberapa API yang ditulis dalam Java, python (kami tidak peduli) dan kami hanya menulis panggilan AJAX, dapatkan data kami dan coba tebak! kita sudah selesai. Tetapi sebenarnya itu tidak mudah, Jika data yang kita peroleh tidak benar atau ada beberapa kesalahan server maka kita macet dan kita harus menghubungi orang-orang back end kita melalui surat atau obrolan (kadang-kadang di whatsApp juga :).) Ini tidak keren Bagaimana jika kita menulis API kita dalam JavaScript dan memanggil API itu dari ujung depan kita? Ya itu sangat keren karena jika kita menghadapi masalah di API kita dapat memeriksanya. Tebak apa ! Anda bisa melakukan ini sekarang, Bagaimana? - Node ada untukmu.

Ok setuju bahwa Anda dapat menulis API Anda dalam JavaScript tetapi bagaimana jika saya setuju dengan masalah di atas. Apakah Anda punya alasan lain untuk menggunakan simpul untuk API sisanya?

jadi inilah keajaiban dimulai. Ya saya punya alasan lain untuk menggunakan simpul untuk API kami.

Mari kita kembali ke sistem API tradisional kami yang didasarkan pada operasi pemblokiran atau threading. Misalkan dua permintaan bersamaan terjadi (r1 dan r2), masing-masing membutuhkan operasi basis data. Jadi, dalam sistem tradisional apa yang akan terjadi:

1. Cara Menunggu: Server kami mulai melayani r1permintaan dan menunggu respons permintaan. setelah selesai r1, server mulai melayani r2dan melakukannya dengan cara yang sama. Jadi menunggu bukanlah ide yang baik karena kita tidak punya banyak waktu.

2. Cara Threading: Server kami akan membuat dua utas untuk kedua permintaan r1dan r2dan melayani tujuan mereka setelah meminta basis data dengan sangat cepat. maka Anda harus berurusan dengan masalah semacam kebuntuan. Jadi ini lebih baik daripada menunggu tetapi masih ada masalah.

Sekarang di sini adalah, bagaimana simpul akan melakukannya:

3. Nodeway: Ketika permintaan bersamaan yang sama datang dalam node maka itu akan mendaftarkan acara dengan callback dan bergerak maju itu tidak akan menunggu respons permintaan untuk permintaan tertentu. Jadi ketika r1permintaan datang maka simpul acara simpul (ya ada loop acara di node yang melayani tujuan ini.) mendaftarkan suatu acara dengan fungsi panggilan baliknya dan bergerak maju untuk melayani r2permintaan dan juga mendaftarkan acara tersebut dengan panggilan baliknya. Setiap kali kueri selesai, ia memicu acara terkait dan mengeksekusi callback-nya sampai selesai tanpa terganggu.

Jadi tidak perlu menunggu, tidak ada threading, tidak ada konsumsi memori - ya ini jalan bebas hambatan untuk melayani API lainnya.


1
Hai Anshul. Bisakah Anda menguraikan atau menyarankan beberapa sumber daya tentang bagaimana kebuntuan mungkin terjadi dalam cara threading.
jsbisht

16

Saya satu lagi alasan untuk memilih Node.js untuk proyek baru adalah:

Mampu melakukan pengembangan berbasis cloud murni

Saya telah menggunakan Cloud9 IDE untuk sementara waktu dan sekarang saya tidak bisa membayangkan tanpanya, ia mencakup semua siklus pengembangan. Yang Anda butuhkan hanyalah peramban dan Anda bisa membuat kode kapan saja di mana saja di perangkat apa pun. Anda tidak perlu memeriksa kode di satu Komputer (seperti di rumah), lalu checkout di komputer lain (seperti di tempat kerja).

Tentu saja, mungkin ada IDE berbasis cloud untuk bahasa atau platform lain (Cloud 9 IDE juga menambahkan dukungan untuk bahasa lain), tetapi menggunakan Cloud 9 untuk melakukan pengembangan Node.js benar-benar pengalaman hebat bagi saya.


1
Sebenarnya Cloud9 IDE dan yang lainnya (koding yang saya gunakan) mendukung hampir semua jenis bahasa web.
Wanny Miarelli

7
Apakah Anda serius? apakah ini kriteria untuk memilih tumpukan? :) senang itu bekerja untuk Anda!
matanster

15

Satu hal lagi yang disediakan node adalah kemampuan untuk membuat beberapa instalan v8 node menggunakan proses anak simpul ( childProcess.fork () masing-masing membutuhkan memori 10mb sesuai dokumen) dengan cepat, sehingga tidak memengaruhi proses utama menjalankan server. Jadi membongkar pekerjaan latar belakang yang membutuhkan beban server besar menjadi permainan anak-anak dan kita dapat dengan mudah membunuh mereka saat dan ketika dibutuhkan.

Saya sudah sering menggunakan simpul dan di sebagian besar aplikasi yang kami bangun, memerlukan koneksi server pada saat yang sama sehingga lalu lintas jaringan yang padat. Kerangka kerja seperti Express.js dan Koajs baru (yang menghapus panggilan balik neraka) telah membuat bekerja pada node lebih mudah.


15

Mengenakan asbes longjohns ...

Kemarin judul saya dengan Publikasi Publikasi, Pemrograman Reaktif dengan JavaScript . Itu sebenarnya bukan judul Node.js-centric; bab-bab awal dimaksudkan untuk membahas teori, dan bab-bab selanjutnya membahas praktik. Karena saya tidak benar-benar berpikir itu akan sesuai untuk gagal untuk memberikan pembaca webserver, Node.js tampak jauh pilihan yang jelas. Kasing ditutup sebelum dibuka.

Saya bisa memberikan pandangan yang sangat indah tentang pengalaman saya dengan Node.js. Sebaliknya saya jujur ​​tentang poin baik dan buruk yang saya temui.

Biarkan saya sertakan beberapa kutipan yang relevan di sini:

Peringatan: Node.js dan ekosistemnya panas - cukup panas untuk membakar Anda dengan buruk!

Ketika saya menjadi asisten guru dalam matematika, salah satu saran yang tidak jelas yang saya diberitahu adalah untuk tidak memberi tahu seorang siswa bahwa ada sesuatu yang “mudah.” Alasannya agak jelas dalam retrospeksi: jika Anda memberi tahu orang-orang sesuatu itu mudah, seseorang yang tidak melihat solusi mungkin berakhir dengan perasaan (bahkan lebih) bodoh, karena mereka tidak hanya tidak mendapatkan cara untuk menyelesaikan masalah, tetapi masalahnya mereka terlalu bodoh untuk dipahami adalah hal yang mudah!

Ada gotcha yang tidak hanya mengganggu orang yang datang dari Python / Django, yang segera memuat ulang sumber jika Anda mengubah apa pun. Dengan Node.js, perilaku default adalah bahwa jika Anda melakukan satu perubahan, versi lama akan tetap aktif hingga akhir waktu atau hingga Anda berhenti dan memulai ulang server secara manual. Perilaku yang tidak pantas ini tidak hanya mengganggu Pythonista; itu juga mengganggu pengguna Node.js asli yang menyediakan berbagai solusi. Pertanyaan StackOverflow "Auto-reload file di Node.js", pada saat penulisan ini, memiliki lebih dari 200 upvote dan 19 jawaban; hasil edit mengarahkan pengguna ke skrip pengasuh, simpul-pengawas, dengan beranda di http://tinyurl.com/reactjs-node-supervisor. Masalah ini memberi pengguna baru peluang besar untuk merasa bodoh karena mereka pikir telah memperbaiki masalahnya, tetapi perilaku kereta yang lama benar-benar tidak berubah. Dan mudah untuk melupakan server bouncing; Saya sudah melakukannya berkali-kali. Dan pesan yang ingin saya sampaikan adalah, “Tidak, Anda tidak bodoh karena perilaku Node ini. Saya menggigit Anda; hanya saja para desainer Node.js tidak melihat alasan untuk memberikan perilaku yang sesuai di sini. Cobalah untuk mengatasinya, mungkin mengambil sedikit bantuan dari simpul-supervisor atau solusi lain, tapi tolong jangan pergi dengan perasaan bahwa Anda bodoh. Anda bukan orang yang bermasalah; masalahnya adalah perilaku default Node.js. "

Bagian ini, setelah beberapa perdebatan, ditinggalkan, tepatnya karena saya tidak ingin memberi kesan "Mudah." Saya memotong tangan saya berulang kali sambil menyelesaikan berbagai hal, dan saya tidak ingin meredakan kesulitan dan membuat Anda percaya bahwa membuat Node.js dan ekosistemnya berfungsi dengan baik adalah masalah yang mudah dan jika tidak langsung untuk Anda juga , kamu tidak tahu apa yang kamu lakukan. Jika Anda tidak mengalami kesulitan menjengkelkan menggunakan Node.js, itu luar biasa. Jika Anda melakukannya, saya berharap Anda tidak pergi dengan perasaan, "Saya bodoh — pasti ada yang salah dengan saya." Anda tidak bodoh jika Anda mengalami kejutan buruk berurusan dengan Node.js. Ini bukan kamu! Ini Node.js dan ekosistemnya!

Apendiks, yang sebenarnya tidak saya inginkan setelah naiknya crescendo pada bab-bab terakhir dan kesimpulannya, berbicara tentang apa yang dapat saya temukan di ekosistem, dan memberikan solusi untuk literalisme gila:

Basis data lain yang sepertinya sangat cocok, dan mungkin dapat ditebus, adalah implementasi sisi-server dari penyimpanan nilai kunci HTML5. Pendekatan ini memiliki keunggulan utama dari API yang dipahami oleh sebagian besar pengembang front-end yang baik. Dalam hal ini, ini juga merupakan API yang dipahami oleh sebagian besar pengembang front-end yang cukup baik. Tetapi dengan paket node-localstorage, sementara akses kamus-sintaks tidak ditawarkan (Anda ingin menggunakan localStorage.setItem (kunci, nilai) atau localStorage.getItem (kunci), bukan localStorage [kunci]), semantik localStorage penuh diimplementasikan , termasuk kuota 5MB default— MENGAPA? Apakah pengembang JavaScript sisi-server perlu dilindungi dari diri mereka sendiri?

Untuk kemampuan basis data sisi klien, kuota 5MB per situs web benar-benar merupakan jumlah ruang pernafasan yang murah hati dan berguna untuk memungkinkan pengembang bekerja dengannya. Anda bisa menetapkan kuota yang jauh lebih rendah dan masih menawarkan pengembang peningkatan yang tak terukur dibandingkan pincang bersama dengan manajemen cookie. Batas 5MB tidak cocok untuk pemrosesan data sisi klien Big Data, tetapi ada tunjangan yang cukup besar yang dapat digunakan oleh pengembang yang banyak akal untuk melakukan banyak hal. Tetapi di sisi lain, 5MB bukanlah bagian yang paling besar dari sebagian besar disk yang dibeli kapan saja, yang berarti bahwa jika Anda dan situs web tidak setuju tentang apa yang masuk akal dari penggunaan ruang disk, atau beberapa situs hanya omong kosong, itu tidak benar-benar mahal Anda banyak dan Anda tidak dalam bahaya hard drive yang kebanjiran kecuali hard drive Anda sudah terlalu penuh.

Namun, mungkin dengan lembut ditunjukkan bahwa ketika Anda adalah satu-satunya kode penulisan untuk server Anda, Anda tidak memerlukan perlindungan tambahan dari membuat database Anda lebih dari ukuran 5MB yang dapat ditoleransi. Sebagian besar pengembang tidak perlu atau menginginkan alat yang bertindak sebagai pengasuh dan melindungi mereka dari menyimpan lebih dari 5MB data sisi server. Dan kuota 5MB yang merupakan tindakan penyeimbangan emas di sisi klien agak konyol di server Node.js. (Dan, untuk database untuk banyak pengguna seperti yang dicakup dalam Lampiran ini, mungkin ditunjukkan, sedikit menyakitkan, bahwa itu bukan 5MB per akun pengguna kecuali Anda membuat database terpisah pada disk untuk setiap akun pengguna; itu 5MB dibagi antara semua akun pengguna bersama. Itu bisa menyakitkanjika Anda menjadi viral!) Dokumentasi menyatakan bahwa kuota dapat disesuaikan, tetapi email seminggu yang lalu kepada pengembang yang menanyakan bagaimana mengubah kuota tidak dijawab, seperti pertanyaan StackOverflow yang menanyakan hal yang sama. Satu-satunya jawaban yang dapat saya temukan adalah di sumber Github CoffeeScript, di mana ia terdaftar sebagai argumen integer kedua opsional untuk sebuah konstruktor. Jadi itu cukup mudah, dan Anda dapat menentukan kuota yang setara dengan ukuran disk atau partisi. Tetapi selain mem-porting sebuah fitur yang tidak masuk akal, pembuat alat telah gagal sepenuhnya untuk mengikuti konvensi yang sangat standar dalam menafsirkan 0 sebagai makna "tidak terbatas" untuk variabel atau fungsi di mana integer adalah untuk menentukan batas maksimum untuk beberapa penggunaan sumber daya. Hal terbaik untuk dilakukan dengan penyimpangan ini mungkin untuk menentukan bahwa kuota adalah Infinity:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Bertukar dua komentar secara berurutan:

Orang-orang yang tidak perlu menembak diri sendiri terus-menerus menggunakan JavaScript secara keseluruhan, dan bagian dari JavaScript yang dijadikan bahasa terhormat adalah Douglas Crockford yang pada intinya mengatakan, “JavaScript sebagai bahasa memiliki beberapa bagian yang sangat bagus dan beberapa bagian yang sangat buruk. Ini bagian yang bagus. Lupakan saja ada hal lain di sana. ” Mungkin Node.js panas ekosistem akan tumbuh nya sendiri “Douglas Crockford,” yang akan mengatakan, “The Node.js ekosistem adalah coding Wild West, tetapi ada beberapa permata yang nyata dapat ditemukan. Inilah peta jalan. Berikut adalah area yang harus dihindari dengan biaya berapa pun. Berikut adalah area dengan paydirt terkaya yang dapat ditemukan dalam bahasa atau lingkungan APAPUN. ”

Mungkin orang lain dapat menganggap kata-kata itu sebagai tantangan, dan mengikuti petunjuk Crockford dan menulis "bagian yang baik" dan / atau "bagian yang lebih baik" untuk Node.js dan ekosistemnya. Saya akan membeli salinan!

Dan mengingat tingkat antusiasme dan jam kerja semata-mata pada semua proyek, mungkin diperlukan dalam satu tahun, atau dua, atau tiga, untuk meredam dengan tajam setiap komentar tentang ekosistem yang belum matang yang dibuat pada saat penulisan ini. Sangat masuk akal dalam lima tahun untuk mengatakan, “Ekosistem Node.js 2015 memiliki beberapa ladang ranjau. Ekosistem Node.js 2020 memiliki banyak paradis. ”


9

Jika aplikasi Anda terutama mengikat web apis, atau saluran io lainnya, beri atau ambil antarmuka pengguna, node.js mungkin merupakan pilihan yang adil untuk Anda, terutama jika Anda ingin memeras skalabilitas yang paling banyak, atau, jika bahasa utama Anda dalam hidup adalah javascript (atau pengalih javascript). Jika Anda membangun microservices, node.js juga oke. Node.js juga cocok untuk proyek apa pun yang kecil atau sederhana.

Nilai jual utamanya adalah memungkinkan front-ender mengambil tanggung jawab untuk hal-hal back-end daripada pembagian tipikal. Titik penjualan lain yang dapat dibenarkan adalah jika tenaga kerja Anda berorientasi pada javascript untuk memulai.

Namun, di luar titik tertentu, Anda tidak dapat membuat skala kode Anda tanpa peretasan yang mengerikan karena memaksa modularitas, keterbacaan, dan kontrol aliran. Namun, beberapa orang menyukai peretasan tersebut, terutama yang berasal dari latar belakang javascript yang dipicu oleh peristiwa, mereka tampak akrab atau dapat dimaafkan.

Khususnya, ketika aplikasi Anda perlu melakukan aliran sinkron, Anda mulai mengalami pendarahan pada solusi setengah matang yang memperlambat Anda dalam hal proses pengembangan Anda. Jika Anda memiliki bagian intensif perhitungan dalam aplikasi Anda, tapak dengan hati-hati memilih (hanya) node.js. Mungkin http://koajs.com/ atau hal baru lainnya meringankan aspek-aspek yang awalnya sulit, dibandingkan dengan ketika saya awalnya menggunakan node.js atau menulis ini.


3
Ada banyak pendekatan yang ada untuk penskalaan aplikasi Node.js, dan Anda tampaknya tidak memberikan referensi apa pun mengenai klaim "solusi setengah matang", "peretasan mengerikan", dan "API mengerikan". Pikiran berkembang pada mereka?
Sven Slootweg

Saya meninggalkannya sebagai latihan untuk pembaca, tetapi cukup untuk melihat solusi yang disebut untuk kontrol aliran.
matanster

2
Itu bukan jawaban. Anda mengklaim bahwa solusi yang ada adalah "peretasan yang mengerikan", namun gagal menunjukkannya. Sudahkah Anda mempertimbangkan bahwa Anda mungkin tidak benar-benar memahami atau menyadari metode yang benar untuk meningkatkan skala aplikasi Node.js?
Sven Slootweg

Saya memperbarui jawaban saya sedikit. Mungkin Anda masih memiliki keluhan, tetapi jika Anda pikir itu salah, Anda harus berkomentar dengan detail ... daripada menunjukkan kekurangannya dalam jawabannya. Itu akan lebih produktif bagi komunitas imo.
matanster

-2

Saya dapat berbagi beberapa poin di mana & mengapa menggunakan simpul js.

  1. Untuk aplikasi waktu nyata seperti obrolan, pengeditan kolaboratif lebih baik kita gunakan dengan nodejs karena ini adalah basis acara di mana acara api dan data untuk klien dari server.
  2. Sederhana dan mudah dimengerti karena merupakan basis javascript di mana sebagian besar orang memiliki ide.
  3. Sebagian besar aplikasi web saat ini menuju sudut js & backbone, dengan simpul itu mudah untuk berinteraksi dengan kode sisi klien karena keduanya akan menggunakan data json.
  4. Banyak plugin tersedia.

Kekurangan: -

  1. Node akan mendukung sebagian besar database tetapi yang terbaik adalah mongodb yang tidak akan mendukung gabungan kompleks dan lainnya.
  2. Kesalahan Kompilasi ... pengembang harus menangani masing-masing dan setiap pengecualian dengan bijaksana jika setiap aplikasi sesuai kesalahan akan berhenti bekerja di mana lagi kita harus pergi dan memulainya secara manual atau menggunakan alat otomatisasi apa pun.

Kesimpulan: - Nodejs terbaik untuk digunakan untuk aplikasi waktu nyata dan sederhana .. jika Anda memiliki logika bisnis yang sangat besar dan fungsi yang kompleks lebih baik tidak boleh menggunakan nodejs. Jika Anda ingin membangun aplikasi bersama dengan obrolan dan fungsi kolaboratif apa pun .. simpul dapat digunakan di bagian tertentu dan tetap harus pergi dengan teknologi kenyamanan Anda.


-3
  1. Node sangat bagus untuk prototipe cepat tetapi saya tidak akan pernah menggunakannya lagi untuk hal yang kompleks. Saya menghabiskan 20 tahun mengembangkan hubungan dengan kompiler dan saya sangat merindukannya.

  2. Node sangat menyakitkan untuk mempertahankan kode yang belum Anda kunjungi untuk sementara waktu. Jenis info dan kompilasi deteksi kesalahan waktu adalah HAL YANG BAIK. Mengapa membuang semua itu? Untuk apa? Dan sial, ketika ada sesuatu yang pergi ke selatan tumpukan jejak cukup sering sama sekali tidak berguna.


2
Meskipun Anda tidak mendapatkan pemeriksaan waktu kompilasi, JSDoc memungkinkan Anda untuk menambahkan info jenis apa pun yang Anda inginkan sehingga hal-hal yang lebih masuk akal ketika Anda kembali. Fungsi-fungsi yang didekomposisi dengan baik (kecil) juga biasanya cukup mudah untuk grok karena lingkungannya yang terdefinisi dengan baik (penutupan). Jejak tumpukan yang buruk seringkali dapat diselesaikan dengan anjak piutang ulang untuk memastikan Anda tidak membagi logika Anda dengan callback asinkron di antaranya. Menjaga panggilan balik async Anda dalam penutupan yang sama membuatnya mudah untuk dipertimbangkan dan dipelihara.
Rich Remer

2
Saya telah menghabiskan 30 tahun dengan bahasa yang dikompilasi, tetapi setelah menggunakannya hanya sekitar satu tahun JavaScript sekarang menjadi bahasa pilihan saya. Ini sangat produktif - saya dapat melakukan lebih banyak hal dengan kode yang jauh lebih sedikit, daripada Java C # C ++ atau C. Tapi itu pola pikir yang berbeda. Variabel yang tidak diketik sebenarnya merupakan keuntungan dalam banyak kasus. JSLINT sangat penting. Ketika Anda perlu melakukan hal-hal secara bersamaan, callback asinkron jauh lebih aman, lebih mudah dan pada akhirnya lebih produktif daripada bahasa apa pun di mana Anda harus menggunakan utas. Dan Anda tetap harus tahu JavaScript karena itu bahasa browser.
James

Saya benar-benar bersimpati dengan keprihatinan yang diangkat, dan saya perhatikan bahwa beberapa upaya telah dilakukan untuk mengatasinya, meskipun mereka tentu saja tidak diterapkan secara universal. Ada proyek luar biasa yang disebut Tern yang dapat memberikan derivasi tipe dari analisis statis kode Javascript dan perpustakaan. Ini memiliki plugin untuk berbagai editor. Ada juga naskah, JSDoc, dan BetterJS . Dan kemudian ada Go , salah satu dari banyak bahasa kompilasi-ke-Javascript !
joeytwiddle
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.