Kami memiliki aplikasi besar Ruby on Rails (25 juta pengguna bulanan), manajemen kami memutuskan untuk menulis ulang di Node.js, apakah saya gila?


24

Tolong beritahu saya jika:

  • Node.js akan membuat situs kami lebih cepat!
  • Node.js akan mengkonsumsi lebih sedikit sumber daya server, kita dapat menghemat uang!
  • Node.js akan membuat kita lebih produktif!
  • Node.js berarti kita dapat berbagi kode JavaScript sisi klien dan server.

Untuk memperjelas, kami menulis ulang server frontend, yang akan berbicara dengan aplikasi Ruby on Rails kami yang ada sebagai API. Sementara itu, kami akan mengubah aplikasi Ruby on Rails kami menjadi layanan.

Lebih detail tentang arsitektur yang ada:

  • Memcached untuk cache sebagian HTML
  • Redis untuk sesi, dan beberapa caching data terstruktur
  • Master tunggal MySQL , banyak budak
    • Ada satu meja besar yang menerima banyak penulisan (bayangkan polling)
    • Kalau tidak sebagian besar membaca.
  • MongoDB untuk beberapa metadata
  • Ruby on Rails 3.0
  • nginx dan Unicorn

33
sheesh, semua bahasa hipster ini. Aplikasi php yang ditulis dengan baik akan mengukur dengan mudah, alat tradisional bekerja, jangan biarkan orang-orang hipster memberi tahu Anda sebaliknya.
Darknight

5
Pertanyaannya harus lebih sesuai: "Apakah perbaikan akan menghemat cukup uang bagi bisnis untuk menjadikannya bermanfaat?" Mungkin menghemat uang lebih dari 5 tahun tetapi menulis ulang itu mahal dan memakan waktu - kecuali kode Anda berantakan mengerikan Saya pikir manajer Anda sedang marah
Mikey C

4
Jika penulisan ulang sedang dipertimbangkan, Anda juga dapat mempertimbangkan untuk memindahkan front-end Anda ke javascript sisi klien, yang berarti Anda tidak akan memiliki server front-end yang dinamis lagi, hanya file statis.
Joeri Sebrechts

11
@Darknight ingat bahwa pada satu titik PHP adalah bahasa hipster, dan bahwa orang-orang yang menunjukkannya dapat digunakan dalam produk-produk yang sukses mempromosikan pengadopsiannya — sementara pengembang web Perl mencibir pada hipsters PHP.

9
Saya sangat terkejut tidak ada yang mengungkit artikel Joel Spolsky Hal-hal yang tidak boleh Anda lakukan . Saya tidak mengatakan semua penulisan ulang itu buruk, tapi saya setuju dengan @MikeyC bahwa mereka harus didekati dengan sangat hati-hati.
Dan Pichelman

Jawaban:


22

Sebagian besar pertanyaan yang Anda ajukan tidak dapat dijawab tanpa konteks, dan sedikit banyak diperdebatkan manajemen telah membuat pilihan untuk Anda ... kecuali jika Anda bertanya 'harus saya berhenti dan mencari pekerjaan baru dalam menghadapi semua perubahan ini ? '

Jika Anda akan berusaha keras, saya sarankan Anda membaca posting ini pada topik: Cara Bertahan Menulis Ulang Tanpa Kehilangan Ketangkasan Anda .

Saya baru-baru mulai menyusuri jalan menulis ulang sedikit logika server di node.js. Alasan utama adalah saat ini ditulis dalam. NET dan kami ingin bermigrasi dari lingkungan MS di trek.

Pengalaman saya sejauh ini positif, Anda akan memiliki kurva belajar awal dengan semua non-blocking-ness itu tetapi setelah Anda melewati itu sebenarnya cukup menyenangkan untuk kode masuk .. Saya tahu, MENYENANGKAN!

Memang memiliki sisi gelap, setiap orang dan anjingnya yang telah melakukan beberapa pengembangan front end dengan JavaScript - dan itu akan menjadi setiap pengembang front-end saya harap - menjadi sedikit bersemangat ketika Anda menyebutkan bahwa node.js adalah 'server side javascript 'Namun itu tidak berarti pengembang ujung depan akan memiliki pengalaman yang diperlukan untuk menulis aplikasi sisi server yang baik.

Untuk satu hal yang Anda pertimbangkan adalah bahwa kesalahan fatal akan menjatuhkan seluruh aplikasi karena sifatnya yang tidak berulir, sehingga taruhannya sedikit lebih tinggi dan Anda harus secara eksplisit memeriksa dan menangkap semuanya.

Bagi mereka yang telah melakukan front dan back - dan menikmati keduanya - tidak harus mengubah konteks mental dari bahasa front end ke back end adalah bonus nyata yang saya pikir pada akhirnya akan meningkatkan produktivitas di tim kami.


"Untuk satu hal yang telah Anda pertimbangkan adalah bahwa kesalahan fatal akan menjatuhkan seluruh aplikasi karena sifatnya yang tidak berulir, sehingga taruhannya sedikit lebih tinggi dan Anda harus secara eksplisit memeriksa dan menangkap semuanya" - Itu akan menjadi kekhawatiran saya.
tentimes

Ya, poin utama saya dengan pernyataan itu adalah bahwa front end only developer biasanya tidak terlalu cerewet dalam hal penanganan pengecualian. Ayo, ini sudah hampir 2017!
dave.zap

8

Yah, saya tidak berpikir bahwa menulis ulang aplikasi adalah ide yang bagus kecuali jika kinerjanya buruk. Untuk menjawab pertanyaan Anda:

  1. Node.js bukan sihir. Aplikasi Anda memiliki sejumlah besar pengguna, jadi tidak ada cara untuk memastikan bahwa itu akan membuatnya lebih cepat.

  2. Yah, ya, Node.js memang mengkonsumsi lebih sedikit sumber daya server. Jadi Anda tidak hanya dapat menghemat uang pada sumber daya, tetapi Anda juga dapat melakukan lebih banyak dengan yang sudah ada. Ini sebagian besar karena sifat single-threaded dari Node.js. Tidak ada overhead untuk utas tambahan.

  3. Sekali lagi Node.js bukanlah sihir. Karena itu, mungkin ada beberapa kebenaran di dalamnya. Node.js memiliki komunitas yang sangat aktif yang telah menciptakan ratusan modul untuk setiap tugas yang mungkin. Jadi sangat mungkin sebagian besar pekerjaan telah dilakukan untuk Anda. Anda hanya perlu menyatukan potongan-potongan itu.

  4. Secara teoritis, ya. Karena Node.js adalah JavaScript, Anda dapat berbagi kode antara klien dan server. Tapi saya tidak tahu persis apa yang akan dibagikan. Saya belum menulis kode apa pun yang dapat digunakan kembali pada klien. Hal-hal yang kami lakukan di server biasanya tidak ada hubungannya dengan klien. Yang lebih penting bagi saya adalah kurangnya saklar konteks. Saya merasa lebih mudah untuk kode pada klien dan server dalam satu bahasa.

Karena Node.js adalah single-threaded, kecuali jika dikonfigurasi secara eksplisit untuk melakukannya, Node.js tidak dapat memanfaatkan banyak CPU .

Lihatlah komentar juga. Mereka memberikan beberapa wawasan yang baik tentang cara kerja Node.js.


16
Lebih sedikit sumber daya karena satu utas? Menurut Anda apa yang akan dilakukan utas tambahan itu?
Joe

@Sampai sejauh yang saya mengerti mereka akan bertambah. Pada simpul js itu adalah praktik terbaik untuk membuang permintaan secepat mungkin. Baik dengan menyelesaikannya dalam satu go.Atau dengan melanjutkannya di lain waktu.Jadi simpul jujur ​​js adalah satu-satunya teknologi yang telah saya buat untuk aplikasi produksi. Jadi saya mungkin bukan orang yang terbaik untuk membandingkannya dengan teknologi sisi server lainnya. Itulah mengapa saya menahan diri untuk tidak membuat perbandingan dan hanya memasukkan apa yang saya pikir saya ketahui tentang simpul js di Jawabanku.
Akshat Jiwan Sharma

7
Ya, satu utas tentu membatasi penggunaan sumber daya, karena server hanya dapat melakukan satu hal sekaligus pada perulangan acara. Ini juga membatasi penggunaan server, karena hanya dapat melakukan satu hal sekaligus. Sangat penting untuk mengutip fitur (single-threaded) dan sisi atas dan bawah daripada hanya sisi atas. Node.js cocok untuk beberapa kegunaan tetapi itu adalah ide yang buruk untuk yang lain. Ketika server node single-threaded Anda memiliki masalah kapasitas, Anda mungkin harus menambahkan instance node lain. Sekarang Anda memiliki server multi-proses.
Joe

Saya mengerti maksud Anda. Saya akan segera memperbarui jawabannya (baca setelah riset)
Akshat Jiwan Sharma

10
Ini bukan hanya tentang CPU. Alasan mengapa penting untuk menangani setiap permintaan secepat mungkin (dalam sistem berulir tunggal tanpa konkurensi lainnya) adalah karena server tidak dapat melayani beberapa permintaan sekaligus, jadi setiap permintaan harus menunggu sampai Anda selesai menangani semua permintaan. permintaan sebelumnya. Konkurensi, dilakukan dengan benar, berarti kurang menunggu. Penggunaan utas tidak secara inheren menguras kinerja, dan utas tunggal (secara default atau tidak) bukan keuntungan kinerja.
Peter Hosey
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.