Diffins Laravel - это примерно как WP среди фреймворков. Да он популярен, но не потому, что качественно написан. Да, быстренько что-то небольшое на нем можно сварганить. Когда же ваш проект станет побольше - велик шанс что его поддержка будет экспоненциально усложняться потому, что фреймворк пропагандирует множество антипрактик.
Роман Жариков Под средние - может быть. Под крупные - строго нет. Синглтон - это бомба замедленного действия, чем крупнее проект - тем больше проблем он приносит. Для крупных проектов "взрывом" является внедрение нескольких подсистем инициализации и контроля зависимостей и их взаимная интеграция. Это источник огромного числа ошибок.
AR - это тоже паттерн не для крупных проектов, почитайте комментарии по ссылке, что я привел в ответе.
Задача менеджера - управлять процессом разработки. Терминологию знать стоит, языки программирования - скорее вредно знать, чем полезно. У менеджера, который знает чуть-чуть, с большой долей вероятности появится эффект Даннинга-Крюгера, а так как мнение менеджера часто весомее, чем у технического специалиста - результат может быть очень плачевным.
> я имел в виду без хитросплетенной "архитектуры" инструмента.
тот же ответ. Так не бывает. В случае конструктора вы всегда ограничены.
> Чтобы было все в доступности для меня.
Вот это вполне возможно. Становитесь fullStack инженером - и эта цель будет достигнута.
> Чтобы не смотреть по каждой кучу информации - сузить круг рассматриваемых.
Признайтесь, вы ничего не хотите учить)). Еще раз, взвешенный выбор можно сделать, только на основании опыта использования той, или иной технологии. И да, надо каждую развернуть, потыкать, посмотреть что/где, исследовать.
> Да и яваскрипт я открывал уроки для чайников - видимо мой мозг не заточен под это дело
возможно
> Может я просто не верно излагаю суть вопроса, это уже другая история.
Суть вопрос ясна вполне конкретно: вы хотите то, чего нет.
Понимаете, для построения rest api вам подойдет любой серверный язык. Но api - это только протокол взаимодействия между клиентом и сервером. Важно знать, что будет делать ваш сервер, получив некий запрос.
Для задач, не требующих хранить состояние php вполне подойдет, для задач, завязанных на событийную модель можно на ноду посмотреть, если завязан на винду - до-диез)) если на производительность - рест тут вероятно будет излишним, и т.д.
Короче язык для rest api - это как искать животное, зная, что у него есть рот и анус.
Ок, вы уже провели безуспешный поиск перловиков, вы можете продолжить искать, либо признать что только первую задачу решить не выйдет. Почистить код - опять же вам нужен перловик, но это не продуктовая задача, в смысле с 2004 года у вас оно как-то работало - и без чистки кода, очень вероятно, что в этом нет необходимости.
Если же вы признаете, что перловика вам не найти - даже не думайте в контексте "исправление старого". Это будет полностью новый проект, бизнес требования уже рекомендую написать. ТЗ пишите вместе с ним, чем оно будет подробнее - тем лучше для для вас И для исполнителя. Выбор CMS/фреймворка оставьте исполнителю, так как это в его компетенции, а не в вашей. Очень рекомендую ознакомиться: Как юридически грамотно возместить ущерб за некачественную разработку?
Еще раз, что бы реализовать стратегию защиты нужно понимать, от кого вы защищаетесь. От оператора связи у вас полноценной защиты не будет. DPI и тому подобные штуки уже давно есть, я уже молчу про MITM. Против подобного есть стенография.
