Почему нет сильной Ecommerce платформы под node.js?

Question

[Itvanya]

На днях перевели высоконагруженный(550,000 товаров и услуг) интернет магазин(аукцион) с opencart на node.js. В качестве основы взяли meteor.js, который дописывали самостоятельно. На фронте реакт. По итогу прирост производительности более чем в два с половиной раза. Хотелось бы, чтобы из коробки была готовая система, написанная на ноде, именно под ecommerce, но таковой найдено не было(из достойных). Вопрос : почему, учитывая достоинства ноды в работе с потоковыми данными, до сих пор нет такой платформы?

Comments

[Илья Ерохин]

Есть подозрение, что Нода здесь не при чем. Вы перевели проект с какой-то нагрузкой с универсального сложного монстра на эксклюзивное решение, заточенное под проект. Конечно оно будет быстрее. Скорее всего для производительности вообще без разницы, на чем оно там написано, главное - как работаете с БД и другими затычными операциями, как и что кешируете.

> Вопрос : почему, учитывая достоинства ноды в работе с потоковыми данными, до сих пор нет такой платформы?

достоинства в контексте таких систем не так уж и важны. Такой платформы пока нет потому что Нода еще молода.

[SMA2]

AirWorker: Однозначно, да - дело не в преимуществах Ноды, а в узкой заточке инструмента. Причем, заточку можно еще и улучшить. Потому как "в 2 раза" что-то плохой показатель.

[E N]

У меня на simpla cms 600т товаров с кучей свойств и тройным деревом каталога, и работает на отклике 0.14 мс на сервере с 4 ядрами. 13000 хостов в сутки.

Answer 1

[SMA2]

На днях перевели высоконагруженный(550,000 товаров и услуг)

Нагрузка - это не количество товара.
Для современных баз данных даже на слабом железе это не нагрузка, а смешно.

Нагрузка - это количество посетителей.
Даже на 100 товарах если большое количество посетителей нагрузка может быть в разы больше, чем у вас.

На Ruby, Node, Go, Java, Python как правило делают решения под себя. Готовые - редкость.
Готовые решения - существуют как правило на PHP.

Так устроен этот мир.

Можно, конечно, пофилософствовать о причинах этого, например, об том, что представляет из себя типичный программист, занимающийся той или этой сферой деятельности, и из этого логическим путем вывести, - а почему именно так.

Или просто смотреть на факту - если вы сделаете полностью готовое решение не на PHP, то с большой вероятностью оно не будет востребовано большим количеством людей, ваши потребители будут только нишевые.

Отсюда и оборотная сторона - наверняка на Node и пр. есть готовые решения интересующего вас типа. Их просто не может не быть. Просто вы их не нашли. Это не настолько массовый продукт, чтобы на каждом углу об них говорили, как, к примеру, об OpenCart.

Answer 2

[xfg]

Потому что на node.js как не пиши, но любое более менее сложное приложение превращается в процедурную лапшу. Абстракций и полиморфизма типов нет, приходится зависеть от конкретных реализаций. В метеоре на котором вы написали свое приложение нет di контейнера, всё валится в глобальную область видимости, используется монго, не поддерживаются транзакции между документами/коллекциями, сильная связанность, тяжело покрыть тестами.

Впечатление от этого всего, что вернулся в начало 2000-ых. Нужно ждать, пока спецификацию ecmascript допилят до вменяемого состояния. Но я думаю, что к тому времени в том же php уже будет асинхронность из коробки, тем более у разработчиков это в планах.

Comments

[SMA2]

а кто мешает на модуля делить логические.

[HoHsi]

raidhon: порой жалею, что нельзя лайкать коментарии

[Илья Шатохин]

Поддержу HoHsi

[xfg]

raidhon: ничего выше из перечисленного не решает проблему сильной связанности и не позволяет следовать grasp/solid и вообще писать вменяемый код, за исключением typescript. Но нужно понимать, что это новый язык, обратно совместимый к javascript и в него компилирующийся и появился только потому, что спецификация ecmascript примитивна.

А то что в сообществе куча разных сборщиков, то что каждый считает своим долгом написать свой собственный пакет менеджер, да и очередной компилятор не против запилить. Так это минус, но не плюс. Потому что, приводит к хаосу. Скоро будете сборщики сборщиков писать и компиляторы компиляторов. Удачи.

[xfg]

Артём Петренков: а в plain js есть интерфейсы? типизация у параметров методов? Помоему нет.

[xfg]

raidhon: Я отвечу вам в последний раз, поскольку более нет желания общаться с человеком, который хамит и плохо понимает написанное.

Я нигде не говорил, что di нельзя реализовать средствами языка. Я лишь сказал, что di нет в метеоре.

Отсутствие абстракций в js, как минимум не даст вам реализовать ISP и DIP из SOLID. DIP говорит, что модули должны зависеть от абстракций, но в js их нет. Поэтому мы в любом случае зависимы от конкретных реализаций. Angular 1 может быть вам в пример. Из этого же вытекает то, что как минимум Low Coupling, Polymorphism и Protected Variations из GRASP так же будут нарушены.

[PQR]

>>В метеоре на котором вы написали свое приложение нет di контейнера, всё валится в глобальную область видимости... ...впечатление от этого всего, что вернулся в начало 2000-ых.

Насчёт meteor.js всё верно написано, но при этом много других плюшек, вроде реактивной синхронизации данных с клиентом и автоматическая сборка + hot reloading из коробки (не нужно думать о gulp, babel, webpack и проч...). Противоречивый фреймворк. Хотел бы узнать у автора вопроса его ощущения и впечатления от метеора (помимо радости от возросшей производительности).

[Игорь Александрович]

raidhon: интерфейс это и есть абстракция как и абстрактный класс. Прочитайте Боба Мартина, DIP зависить от высокоуровневых абстракций, а не от реализаций. Переход от композиции к агрегации. Получается в зависимость ты можешь подпихнуть что угодно не нарушив контракт, так как его нет.
JS имеет ряд проблем, вот о чем речь, отсюда и появились coffescrypt typescrypt dart и др. Никто не говорит, что нельзя сделать на JS. Можно и на С написать, вопрос не в этом. Да и для интерпрайза он плохо годится со своей динамической типизацией typescrypt и dart тому подтверждение.

[Игорь Александрович]

raidhon: с формальной стороны интерфейс это абстрактный класс, без реализации.

Answer 3

[serebro]

Может быть кто-то пробовал https://github.com/reactioncommerce/reaction ?

Comments

[Михаил]

присоединяюь к вопросу serebro

Answer 4

[Дмитрий Евграфович]

Во сколько обошлась такая переделка и сколько времени заняла, если не секрет? А вообще просто потому, что существующие решения покрывают 95% потребностей рынка. Тот же опенкарт создан для небольших магазинов, хотя люди и допиливают движок под большое количество товаров. Большой магазин можно запилить на мадженте, предварительно разобравшись с ней. Прикрутить кеширование, то да се и получить тот же самый результат, что и у вас с большей поддерживаемостью. Причем и мадженто и битрикс и все остальные движки появились на свет и решили проблемы разработчиков до появления ноды. Да и разработчику выгоднее работать с маджентой или другой системой вместо того, чтобы велосипедить на ноде.

Comments

[Itvanya]

Дмитрий Евграфович изначально проект был запилен на django(4 года назад) и работал лучше и быстрее, чем на opencart, но ввиду отсутствия нормальных python/django программистов проект был переписан на opencart. Кеширование ставили сразу :) сейчас появился в штате fullstack javascript программист, который по приходе переписал пару средних сайтов, один из которых работал на yii2, а второй на рельсах. Результат был положительным, поэтому было решено переписать магазин. К магазину также на phonegap прикручен эпликейшн на iOS/android, который просто летает. Разработкой занимался один человек, который переписывал и сайт, и писал эпп на мобильные. Все заняло около 2х месяцев и 300,000 рублей(зарплата нашего node.js программиста).

[SMA2]

Цена значения не имеет, если вы не знаете всех деталей функционала.
Запилить одну корзину и форму оформления заказа - это не то же самое что запилить поиск, фильтры, 100500 способов оплаты и способов доставки, несколько иерархий товаров и т.п.

[SMA2]

> Тот же опенкарт создан для небольших магазинов, хотя люди и допиливают движок под большое количество товаров.

При чем здесь проблемы опенкарт если речь идет о большом количестве товаров?
Он что - сразу весь миллион товаров пытается на страницу одну вывести?
Там вся нагрузка (если опенкарт грамотно сделан) идет на БД. А БД - все равно, что миллион, что 100 товаров.
Большинство посетителей просматривают отсилы сотни товаров.

Нагрузку по полному перебору миллиона товаров создают только поисковые роботы.

[Дмитрий Евграфович]

SMA2: когда появляется проблема n+1 запроса, базе становится далеко не все равно. Такое может появиться, например, при некорректно написанном модуле фильтра, который будет дергать доп атрибуты для каждого товара по по очереди (а если товаров окажется в разделе сто тысяч и на каждый по хотя бы два лишних запроса?), либо при модуле, который будет подбирать тем же не оптимальным способом сопутствующие товары - вариантов сотни. А спросил про стоимость потому, что мне интересно было, сколько стоит написать сферический магазин с нуля на ноде.

Answer 5

[Александр Таратин]

Потому что 99% хостингов php онли
VPS же еще админить нужно.
Готовые сервисы заточенные под ноду (типо хероку) стоят еще дороже чем VPS.
Короче не нужно. Php всем хватает.

Comments

[SMA2]

Кто вам сказал, что готовые сервисы стоят дороже чем VPS?
У меня сейчас клиент переводит с "типа Хероку" на классический ВПС свой интернет-магазин.
По причине, что там Крыму хостер блокирует доступ, а классический ВПС может быть где угодно, в частности, переводим на российского хостера.

Так вот - ВПС обходит этому интернет-магазину дороже.

[Александр Таратин]

SMA2: Можно, если не секрет, узнать. Каким ваш клиент пользовался на хероку и каким пользуется сейчас (цена/параметры). Я что-то как не пытаюсь пересчитать - хероку дороже выходит. Наверняка я чего-то недопонимаю...

[Илья Ерохин]

> VPS же еще админить нужно.

Не нужно. Поставьте Ubuntu LTS, врубите автообновления и забудьте о сервере на 5 лет. Остальное - вопрос квалификации разработчика.

[SMA2]

Александр Таратин:
за ВПС идет оплата всегда. помесячно. независимо от нагрузки.
а за облачный PaaS того же Хероку - по фактической нагрузке.
для того, чтобы Хероку не жрал денег - ПО было СПЕЦИАЛЬНО написано под него, для того, чтобы учесть все возможности PaaS.
из-за этого сейчас приходится в значительной мере переписывать под другую платформу.

[SMA2]

AirWorker:
> Поставьте Ubuntu LTS

Не нужно. Есть готовые ВПС с панелями и администрированием. Оплатите 300-500 рублей в месяц и забудьте.

[Илья Ерохин]

SMA2: зачем панели, когда есть нормальный ssh? Ставить конечно уже давно ничего не надо - просто выбрать образ, и через минуту сервер поднят.

[Unicom]

По наблюдениям шаред хостинги вымирают. Оно и понятно за сумму такую же или даже меньшую можно взять VPS KVM и делать вообще что угодно. У хостеров часто идут настроенные образы под вордпресс, какой-нибудь екоммерц и т/д, так что даже это уже не нужно админить становится. Поэтому падает доля коробочных PHP решений и растет доля альтернативных, более правильных решений. И это здорово. Засилие php коробок с их известными всем родовыми проблемами достало. Пускай теперь цветут все цветы.

[x404]

Бред)

[Александр Таратин]

Сергей Сыса: Что именно бред? Что на шаредах доступен исключительно php, а остальные языки в виде стат погрешности? Что vps нужно админить? Что vps общего назначения дешевле чем хероку? SMA2 уже написал, что по специально точилось под хероку, чтобы выиграть в цене.

[x404]

Александр Таратин: "Потому что 99% хостингов php онли"
Есть куча дешевых VPS где можешь играться с настройками как душе угодно. Ну и конечно же, сравнивать популярность PHP и JS(относительно свежей технологией) не совсем уместно.

Answer 6

[Zhandos M]

Потому что это javascript

Comments

[Itvanya]

Zhandos M а что с ним не так?

[Zhandos M]

Javascript has fundamental flaws... Mark S. Miller