У нас є великий додаток Ruby on Rails (25 мільйонів користувачів щомісяця), наше керівництво вирішило переписати на Node.js, я божеволію?


24

Скажіть, будь ласка, якщо:

  • Node.js зробить наш сайт швидше!
  • Node.js буде споживати менше ресурсів сервера, ми можемо заощадити гроші!
  • Node.js зробить нас більш продуктивними!
  • Node.js означає, що ми можемо ділитися кодом JavaScript на клієнті та сервері.

Для уточнення, ми переписуємо передній сервер, який розмовлятиме з нашим наявним додатком Ruby on Rails як API. Тим часом ми повернемо наше додаток Ruby on Rails до послуг.

Детальніше про існуючу архітектуру:

  • Запам'ятовується для кешування частин HTML
  • Повторно для сеансу та деякі структуровані кешування даних
  • MySQL єдиний майстер, кілька рабів
    • Є одна велика таблиця, яка приймає багато записів (уявіть опитування)
    • Інакше в основному читає.
  • MongoDB для деяких метаданих
  • Ruby on Rails 3.0
  • nginx та Єдиноріг

33
Шееш, усі ці хіпстерські мови. Добре написана програма php легко масштабує, традиційні інструменти працюють, не дозволяйте цим хіпстерам сказати вам інакше.
Темна ніч

5
Питання повинно бути більш тематичним: "Чи вдосконалення заощадять достатньо грошей для бізнесу, щоб зробити його вартим?" Це може заощадити гроші протягом 5 років, але переписування дорого і трудомістко - якщо тільки ваш код не є жахливим жахливим безладом, я думаю, що ваші менеджери зліють
Mikey C

4
Якщо розглядаються переписування, ви також можете розглянути можливість перенесення вашого переднього до JavaScript на стороні клієнта, а це означає, що ви більше не матимете динамічного сервера, а лише статичні файли.
Joeri Sebrechts

11
@Darknight майте на увазі, що в один момент PHP була мовою шипшини, і люди, які показують, що він може бути розгорнутий в успішних продуктах, сприяли його прийняттю, в той час як веб-розробники Perl хизувались на PHP-хіпстери.

9
Я дуже здивований, що ніхто не придумав статті Джоела Спольського. Те, чого ти ніколи не повинен робити . Я не кажу, що всі переписки погані, але я погоджуюся з @MikeyC, що до них слід підходити вкрай обережно.
Ден Пішельман

Відповіді:


22

Більшість питань, які ви задаєте, не відповідають без контексту, і більш-менш суперечливе керівництво вже зробило вибір для вас ... якщо ви не запитуєте: «чи варто мені кинути і знайти нову роботу перед усіма цими змінами ? '

Якщо ви збираєтеся це зробити важко, рекомендую вам прочитати цю публікацію на тему: Як пережити перезапис переписування, не втрачаючи розуму .

Нещодавно я пішов по шляху переписання трохи логіки сервера в node.js. Основна причина полягала в тому, що вона зараз написана в .NET, і ми хочемо перейти далеко від середовищ MS вниз по трасі.

Мій досвід досі був позитивним, ви будете мати початкову криву навчання з усією не блокуючою її сутністю, але як тільки ви пройдете минуле, це насправді досить цікаво кодувати. Я знаю, ЗАБАВЛЕНО!

Однак у нього є і темна сторона, кожен чоловік і його собака, які зробили певну розробку за допомогою JavaScript, - і це був би кожен розробник переднього кінця, я сподіваюся - трохи збуджується, коли ви згадуєте, що node.js - це серверний javascript "однак це не означає, що розробники на передньому кінці будуть мати досвід, необхідний для написання хороших додатків на сервері.

З однієї речі, що ви враховуєте, це те, що фатальна помилка призведе до збиття всього додатка через його нерізький характер, тому ставки трохи вище, і вам потрібно чітко перевірити і все виловити.

Для тих, хто зробив і передню, і задню частину - і їм подобається обоє - не потрібно переключати розумові контексти з мов переднього на задній, - це справжній бонус, який, на мою думку, врешті-решт підвищить продуктивність роботи нашої команди вниз.


"З однієї речі, яку ви враховуєте, це те, що фатальна помилка призведе до збиття всього додатка через його нерізький характер, тому ставки трохи вище, і вам доведеться чітко перевірити і впіймати все" - Це було б моє хвилювання.
намети

Так, моє головне в цьому твердженні було те, що тільки розробники на передньому кінці, як правило, не особливо вибагливі, коли мова йде про обробку винятків. Давай, вже майже 2017 рік!
dave.zap

8

Ну, я не думаю, що переписування програми було гарною ідеєю, якщо вона не була поганою. Щоб відповісти на ваші запитання:

  1. Node.js - це не магія. У вашому додатку величезна кількість користувачів, тому немає жодної впевненості, що це зробить це швидше.

  2. Ну так, Node.js насправді споживає менше ресурсів сервера. Тож ви не тільки можете заощадити гроші на ресурсах, але і можете зробити більше з існуючими. Це здебільшого через однопотоковий характер Node.js. Немає накладних додаткових ниток.

  3. Знову ж Node.js - це не магія. Сказавши це, у цьому може бути якась правда. Node.js має дуже активне співтовариство, яке створило сотні модулів для кожного можливого завдання. Тож цілком ймовірно, що більша частина роботи була зроблена саме за вас. Вам просто потрібно скласти шматки разом.

  4. Теоретично так. Оскільки Node.js - JavaScript, ви можете ділитися кодом між клієнтом і сервером. Але я не знаю, на що саме поділяться. Я не написав жодного фрагмента коду, який був би повторно використаний у клієнта. Те, що ми робимо на сервері, зазвичай не має нічого спільного з клієнтом. Для мене важливіше відсутність переключення контексту. Мені легше кодувати як клієнт, так і сервер однією мовою.

Оскільки Node.js є однопотоковою, якщо явно не налаштовано це робити, він не може скористатися кількома процесорами .

Погляньте і на коментарі. Вони дають гарне уявлення про роботу Node.js.


16
Менше ресурсів через одну нитку? Як ви думаєте, чим би займалися ці зайві теми?
Джо

@Joe, наскільки я розумію, вони додадуть. У вузлі js - найкраща практика розпоряджатися запитом якомога швидше. Або заповнивши його за один раз. Або, відновивши його наступного разу. Буду чесним вузлом js це єдина технологія, для якої я зробив виробничі програми. Тому я, можливо, не найкраща людина для порівняння її з іншими технологіями на стороні сервера. Тому я утримався від порівнянь і просто поставив те, що, на мою думку, знаю про вузол js у моя відповідь.
Акшат Джіван Шарма

7
Так, один потік, безумовно, обмежує використання ресурсів, оскільки сервер може робити лише одне в одразу в циклі подій. Це також обмежує використання сервера, оскільки він може робити лише одну справу одночасно. Дуже важливо цитувати особливості (однониткові) та зворотні та зворотні сторони, а не лише перевертання. Node.js підходить для деяких застосувань, але для інших це погана ідея. Коли у вашого однопотокового сервера вузлів є проблеми з ємністю, можливо, вам доведеться додати інший примірник вузла. Тепер у вас є багатопроцесорний сервер.
Джо

Я бачу, що ви маєте на увазі. Я скоро оновлю відповідь (читайте після деяких досліджень)
Akshat Jiwan Sharma,

10
Справа не лише у процесорах. Причина, чому важливо обробити кожен запит якомога швидше (в однопотоковій системі без іншої одночасності), полягає в тому, що сервер не може обслуговувати декілька запитів одночасно, тому кожен запит повинен чекати, поки ви закінчите обробку всіх запити перед ним. Паралельність, зроблена правильно, означає менше очікування. Використання потоків не є за своєю суттю витіканням продуктивності, а однопоточність (за замовчуванням чи іншим способом) не є перевагою продуктивності.
Пітер Хосей
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.