Юрий Ярош

Есть один важный аргумент против питона, ruby и php - относительно низкая производительность, и следовательно невозможность разработки полноценных "реактивных" решений. Node.js будет шустрее, а golang с Java (J2SE) и подавно...

Нужно выбирать язык исходя из полноты, качества поддержки и зрелости существующих инструментариев.
Если это вэб - лучше ити в сторону meteor + react <-> express + mongo и не парить одно место.
Если нужна производительность бэкенда - лучше смотреть в сторону ванильной Java с netty, это Vert.x.
Касательно зрелости и качества поддержки - история умалчивает, но аналогов особо то в других платформах нету.
Ещё стоит разобраться со вторым Angular'ом когда он выползет с альфы, правда там сначала был TypeScript, а теперь Dart + JS :x

Главным аргументом против Java является ужаснейший Overhead разнообразных J2EE поделок с сервлетами, подавляющее большинство существующих решений использует именно это окружение - по сравнению с ванильным Netty, Overhead составляет 1 к 30. Scala тоже имеет довольно большой overhead, но он не является проблемой, вот скорость компиляции просто ужасна - в ~100 раз медленнее Java. Для того что бы эффективно выполнять задачи в Scala (Python / Erlang / Clojure etc) - нужно проводить 80% времени в интерпретаторе, не всем это по душе, да и мешает внедрению нормального CI с TDD/BDD. Имхо Groovy более юзабелен сейчас чем Scala, особенно для скриптов, и оверхед у него минимальный (при правильном приготовлении), и скорость компиляции не доставляет неудобств.

C# + asp.net решение двузначное, я не знаю как сейчас обстоят дела с OpenSource проектами в оных местах - последние два года ситуация обещала исправится (CLR заOpenSource'или), но чуда так и не произошло.

Long story - short. Если тремя предложениями, то ...
Стоит вообще забить на Python, учить JS Meteor Express React MongoDB и опционально Dart со вторым Angular.
Также важно научится собирать фронтэнды gulp'ом со всякими минификаторами, livereload'ами (browsersync), stylus node-sass jshint jscs csslint jsbeautifier ... и прочим барахлом. Ruby'сткий Sass с compass'ом стоит обходить стороной из-за слоупочности.

Нужно отрефакторить схему, привести всё в божеский вид к 5-6 нормальной форме.
80% всех проектов с которыми приходилось иметь дело "аля магазин на РНР" индексирует varchar и еже с ним. Из-за этого "выборка 2К товаров" - просто непосильная задача. Стоит почитать книжку SQL Antipatterns и High Performance MySQL. Разобраться как работает InnoDB, и как вообще происходит оптимизация.

Пример "говно-схемы"
Table products
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL
group varchar(255) NOT NULL
oneAttr varchar(255)
otherAttr varchar(255)
anotherAttr varchar(255)
description varchar(255)
dateCreated DATETIME

Нужно разбить минимум на 4 таблички
Table products
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL
group_id unsigned int NOT NULL (FK)
description varchar(255)
dateCreated DATETIME

Table product_groups
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL

Table products_attrs
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL

Table product_attrs_values
product_id unsigned int (PK <- FK)
attr_id unsigned int (PK <- FK)
attr_value varchar(255) NOT NULL

Ну и т.п.

Это второй курс универа :)
И очень много обывателей даже до него не дотягивает, что меня довольно таки печалит.
И, конечно-же, нужно уметь использовать EXPLAIN.

Ну, во первых, стоит разобраться в чём же разница между аутентификацией и авторизацией - со стороны подобный вопрос выглядит довольно нелепо. Во вторых, если https считать небезопасной средой - можно пробросить ключики по Диффи-Хелману и шифровать трафик AES'ом, но это для полных параноиков, и ещё HMAC-SHA256 можно прикрутить... sha1(sha1(whatever)) с точки зрения криптографии полный "пэ". Обычно бэкенды принято делать stateless и всю инфу хранить в рамках пользовательской сессии, просоленной и пошифрованной. А, непосредственно, сами пароли в BCrypt / SCrypt etc.

Аутентификация в таком случае может выглядеть следующим образом
1. Происходит обмен ключами
2. Человек отправляет свой логин-пароль на сервак по шифрованному каналу
3. В ответ получает объект пользовательской сессии, который сохраняет в куках
Сессия представляет собой не что иное как сериализированный шифрованный объект с "солью" которая прописана на всех запущенных экземплярах бэкенда - таким образом куда бы запрос не пришёл, он везде обрабатывается одинаково, и отпадает потребность в session-storage.
4. Опционально, в рамках пользовательской сессии заводятся CSRF-токены.
5. Опционально, весь траф нужно эскейпить, включая всякие там JSONP и прочее. Ангуляр вообще с коробки требует весь JSONP префиксить таким чудом ")]}',\n"

Doctrine DBAL / ORM

Вышеописанный проект не является стартапом, так как не исследует и не порождает новых рынков сбыта.
Согласен с Назар Мокринский, вам стоит разобраться с терминологией.

Когда люди называют 1Гбит динамического http трафика highload'ом - это вызывает у меня довольно нелепую ухмылку.

Сравнивать php / python / ruby более-менее целесообразно так как это полностью интерпретируемые языки с кэшированием байткода, иногда с оптимизациями, как в случае с jRuby и Project Graal. Обычно такие вещи помирают на 14-17К запросов в секунду с пустыми ответами... В общем на одном гигабите трафика тут обычно всё и заканчивается. Node.js по производительности более корректно сравнивать с JVM языками типа Groovy или Scala, но никак не с самой Java. На практике через Netty на Disruptor'е под offheap'ом и Terracotta можно пропустить и 40Гбит живого трафика, без статики, - главное правильно профилировать и писать прямо pfRing.

Почти в каждом случае где есть сборка мусора нужно использовать offheap кэширование, или любые другие методы контроля роста кучи. Во время самой сборки в очень больших (16Гб и более) старых поколениях возникают проблемы с планировщиками и контролем приоритетов - в итоге получаем очень большое, критическое, увеличение текущих задержек на обработку запросов.

Если вы хотите строить что-то действительно стоящее - стоит смотреть в сторону CQRS-ES'a и реактивных приложений в рамках SOA. Возможно внедрение микросервисных архитектур если нет требований к задержкам на выполнение запросов. Но, учитывая что вы задаёте здесь вопросы о том "что лучше node.js или python" не думаю что у вас хватит опыта для построения подобных вещей.

Можно пробовать golang - яндекс слез с python'a на golang по причине слоупочности оного, и довольно хорошо так слез. В golang'е сейчас самый лучший RAD, гораздо круче того же node.js. Идеоматичность самого языка решает достаточно много потенциальных проблем ещё на этапе разработки. Да и сообщество сейчас довольно активно пилит его runtime - внедряют многопоточный gc и ещё пару вкусностей. Даже не умея всех этих асинхронностей и прочей лабуды с golang'ом можно получить довольно хороший выхлоп. Правда меня немного смущает отсутствие нормальных datamapper'ов и scaffolding'a под golang.

На самом деле всё равно на чём писать магазин, так как это банальный CRUD и AAA сервисы, на практике обычно даже до нормальной модели БД не доходит.

Браузерные SPA (одностраничные приложения) сулят проблемами с SEO, а нормально написать на react'е изоморфное приложение не каждый сможет, да и prerender.io с angular.js не всегда хорошо себя ведёт, хотя можно поиграться и рендерить angular.js в jsdom'e... в общем найти человека который в этом всём нормально разбирается сейчас очень сложно.

Для описанной архитектуры аля CQRS-ES нужны бюджеты от 3000$+, что, собственно точно не самая лучшая идея для среднестатистического магазина, либо нужен энтузиазм разработчиков на котором далеко не уедешь, и мотивировать одним лишь энтузиазмом очень сложно. Готовых решений в этом плане просто нет в природе, а проверить не пишут ли там пятиколёсные велосипеды не всегда представляется возможным.

Проще взять любой среднестатистический РНР фреймворк и не заморачивать себе одно место, покрыть нормально тестами (Codeception к примеру), прикрутить полнотекстовый поиск и отчёты, разобраться как правильно реализовать ААА, убедится что у вас нормализирована модель БД. В последнее время, я всё реже и реже вижу даже 3тью нормальную форму, про остальные 3 история умалчивает.

Если у вас есть нормальный бюджет, 8000-10000$ на разработку магазина - можно думать о всех, описанных выше, вещах, но вам нужно правильно организовать процесс разработки и контроль качества, разобраться в мотивации разработчиков, и только потом можно будет думать не тратятся ли эти деньги не понятно на что, потому что, на моём веку люди так миллионы у.дмурдских е.жей запускали в космос изобретая никому ненужное нечто, и среди таких контор есть даже IBM, Logitech, и TI.

В общем для начала стоит разобраться в более простых вещах, а потом пытаться строить андроидов, иначе нас всех ждёт Skynet им. Kokaas'a.

p.s. php для меня уже года 2 как мёртв, а в 7ом будет больше от Java чем от php.

Можно почитать/посмотреть записи с различных конференций, посмотреть как шардят большие конторы.
1. Аутентификация != Авторизация
2. Нужно понимать что при горизонтальном масштабировании сервер не должен хранить состояний - обычно люди хранят данные сессии в просоленной куке, а не в базе.
3. Распределять нагрузку нужно в зависимости от текущей, соответственно должен производится мониторинг, и запросы должны отправляться на наименее нагруженный сервер
4. В куке сессии должен записываться IP cервера который обрабатывает запросы от текущего пользователя, а DNS в свою очередь должен отдавать адрес сервера который работает с данной сессией. Таким образом с одним пользователем может работать только один сервер, и между ними не нужно гонять никаких редиректов, но на первое время можно просто редиректить.
5. В случае с push-нотификациями, и кэшированием там вообще всё очень сложно и нужно крутить CQRS-ES, иногда нужно решать задачу консенсуса Raft'ом.

С РНР/Python/Ruby проблема - в них нет возможности нормально писать масштабируемые реактивные приложения.
Нет возможности постоянно держать соединения для push'a без костылей типа gearman / beanstalk / celery / sidekiq etc, и там уже не MVC, a CQRS-ES ... в общем весело.

Советую присмотреться больше к Java / Golang'у.
Вот к ноде лезть не советую - слишком мелкая производительность, и сомнительная обратная совместимость.

Вопрос очень плохо сформулирован, не ясно какую задачу нужно реализовать подобным образом.
Берём и читаем как настраивается rewrite в nginx'е и Apache.

Знаком почти со всеми популярными MVC-фреймворками которые сейчас есть на рынке, и даже с Catalyst'ом :)
Нет универсальных решений - у всех есть свои недостатки.

Ввиду движений в сторону реактивностей от себя могу выделить Play2 / Xitrum и Grails.
Но у них тоже хватает проблем с производительностью, хоть они и на много (очень-очень много) быстрее тех же рельсов или джанги, или всяких симфоний / Yii2 и экспрессов с Sails.js'ами.

Вот что писал раньше по поводу того же питона.

Если нужна асинхронность и push-нотификации в РНР - проще уж прикрутить ворекров для очередей типа Gearmand / Beanstalk.