Сергей Протько

у доброго такого процента банков внутренняя кухня в дотнетах варится.

а зачем? Может вам в менеджмент?

1) добавляем ачивку манагера (тимлидерство, менеджмент и т.д.)
2) ???
3) profit

А таки зачем вам?

На junior-а вряд-ли будут интересоваться работой сети ниже чем на прикладном уровне (HTTP).

В принципе достаточно почитать на вики про HTTP (сам протокол, заголовки, статус коды основные, SSL), можно для развития про DNS почитать мельком... и в принципе этого достаточно.

В контексте PHP стоит еще пробежаться по документации и разобраться с SAPI. В частности у вас в голове должно сформироваться представление о том, как например PHP куки сэтит и получает их в $_COOKIE

по клиент-серверному взаимодействую - web api, REST, SOAP.

Фреймворк - каркас. Дословный перевод который в общем хорошо отражает суть. Это какая-то структура которой придерживается приложение.

В основе любой системы лежит какой-то каркас. Структура, способ организации кода, хоть какой-то. Берете класс маршрутизации (который связывает запрос и код, который должен выполниться для обработки оного), класс для работы с базой, менеджер конфигураций... и как-то так выходит что у вас уже есть фреймворк.

В основе любой CMS есть фреймворк. Даже в том же wordpress. Это внутреннее API этой CMS на основе которого она построена.

Сложность и уровень фреймворка определяет уровень абстракции которые он вводит. Если приводить пример - Symfony2 и все та же отправка почты. Отправка почты сама по себе относительно жирная операция. То есть из 200 милисекунд обработки запроса, 100 из них может занимать отправка почты. То есть пользователь получит страницу позже. В Symfony2 реализован слой абстракций над запросами ответами и потому, есть полный контроль за всем потоком данных. Фреймворку не составляет труда узнать когда мы закончили обрабатывать основной запрос. Так же у PHP (в зависимости от SAPI) есть возможность сказать серверу что "мы закончили обрабатывать запрос, можно отдавать его пользователю" и делать что-то еще. В результате мы можем вместо отправки писемь, помещать из в очередь и отправлять только после того как запрос ушел пользователю получая улучшение отзывчивости системы.

Важно заметить, что код приложения вообще никак не отличается. Если у нас внезапно не будет хватать мощностей серверов и у нас узким местом будут как раз таки такие вот отложенные операции - можно безболезненно, без внесения изменений в бизнес логику и основной код приложения, добавлять все в очередь на другом серваке и там все обрабатывать. Таким образом мы можем вносить изменения в систему максимально быстро без ущерба качеству.

Если мне нужен блогообразный сайт, то я возьму вордпрес и перепишу и допишу недостающий функционал в итоге создание сайта на wp займет в разы меньше времени, чем на фреймворке.

А вот тут не всегда так. Как минимум потому, что время реализации функционала под wordpress на базе его внутреннего фреймворка может занять у вас значительно больше времени, чем написать все на популярном нормальном фреймворке, не оптимизированном на конкретное решение + дописать блог.

я бы брал побольше только за счет неадекватности требований и их расплывчатости. Нет никакой информации ни о бизнес логике ни вообще ниочем.

Ну а так все зависит от рейта. Как по мне 10К для какого-либо продукта адекватная стоимость.

Применение нестандартных методов защиты от XSS атак, SQL инъекций и спам-роботов;

Особенно эта строчка радует... ну и про уникальность модулей с целью обеспечения защиты. Писал профан.

1) кеширование
2) горячие данные, например очередь сообщений для обмена данными между компонентами приложения.

Больно похоже на самопис на основе Symfony1 + Propel

Вы знаете зачем нужен полимер? Начните с этого. Затем вы сможете сделать для себя выбор.

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

гугл аналитика вам в помощь (если сайт уже существует).

ну если у вас должны быть push-уведомления или что-то в этом духе то проще будет взять node.js. С другой стороны можно на node.js реализовать ТОЛЬКО push-уведомления а сам корпоративный портал писать на ruby + объеденить все это шиной данных на каком zeromq.

Если вам любопытно потыкать node.js на чем-то сложнее websocket-сервера, то почему бы и да...

Почему бы просто не зарефакторить проект? Как по мне от этого толку будет явно больше с учетом ваших требований. И это не может быть сложнее переноса на python.

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

Если же так считает руководство - пусть они и переписывают. Достаточно просто набросать риски на бумажке сходить к ним и сказать "это будет в 3 раза дороже" и возможно они одумаются. Ну а коль уж переписывать всеравно заставят то можно спокойно менять структуру всего и вся. Риски от этого не увеличатся сильно уже.

Я бы пытался настаивать на постепенном развязывании системы и рефакторинге с последующим переводом на Symfony2

В дополнение к отвечающим выше - подобный вид маршрутизации удобнее реализовывать на уровне DNS. Тогда просто для каждого запроса будет подсовываться ближайший сервер и все будет прозрачно для пользователя.

Могу предложить вариант генерации на основе шаблона UI (формочки) для редактирования выводимого оными контента.

знания ООП (получены в ходе обучения языку с++),

“Я придумал термин ‘объектно-ориентированный’, и вот что я вам скажу: я не имел в виду C++.”

Алан Кей.

в целом же от вас требуется желание развиваться, учиться... Если у вас есть голова на плечах, идите джуниором куда. ~$500-$600 для джуниора норм, найти такие вакансии по сути не сложно. Если джуниор толковый... Возможно со старта будут давать меньше, может через пару месяцев если будет виден рост будет расти и ЗП... все просто.

Я думаю вам сразу можно начать с getjump.github.io/ru-php-the-right-way а дальше по мере необходимости обращаться к официальному мануалу.