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

Redmine.

Ну 6, хотя по факту, там от версии к версии немного меняется api, что-то помечают депрекейтед, что-то удаляют/добавляют, обновляют версию движка V8 и всё такое. Глобальных изменений, когда меняется всё и вся, такого нет.

Вобще это всего лишь платформа для выполнения javascript кода, расширенная собственным api для работы с файлами, потоками и т.д. Если требуется использовать что-то из api nodejs то открыл доку и почитал, какие там есть свойства/методы и что вообще делает модуль. Всё. Это же не язык программирования, скажи что там можно изучать?

Вероятно "Документы больше 10Мб не индексируются", а не "сайты".

Очевидно, речь идёт о размере html-страницы, не считая всех её ресурсов.

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

Подкласс нужно создавать тогда, когда у вас есть дополнительная логика что называется для конкретных случаев. По вашему примеру, если Magick - это класс всяких магов, то подкласс водяных магов может определять свой magick, который он умеет кастовать. Ну или образовывать более конкретную, "водяную" магию.

Второй вариант подразумевает, что магия может полностью задаваться извне, и Magick только кастит её, но в её "формировании" не участвует.

Сейчас вы не решили для себя, что такое Magick. Вам нужно это сделать, и вопрос отпадёт сам собой.

Изоморфный фреймворк - это как раз то что нужно для индексации. Благодаря рендерингу страниц на стороне сервера, поисковики увидят все что нужно. Кроме того, современные поисковики вполне себе учатся понимать SPA-сайты, вот, например тот же Яндекс рассказывает как это сделать. Google предпочитает Progressive enhancement

Зачем вообще нужно? Затем чтобы сайт работал как приложение (точно так же, как на смартфонах и прочих девайсах). В ситуациях, когда ваш продукт это не только веб-сайт, но еще и куча других устройств, это позволит вам сильно упростить серверную часть. 1 сервер и Rest API для всех, вместо того, чтобы делать отдельно сайт со своим собственным сервером, и отдельно инфраструктуру под мобильные приложения.

Структура и интерпретация компьютерных программ

forever, pm2, запуск процесса в бекграунде и т.д.

Вы ищите то, чего нет. Нет понятия "правильных" частей системы, или "правильных" паттернов.
Вот вам пример: OAuth, что вы привели имеет 2 версии, это что получается, первая была не правильная?))
RBAC - это подход, который далеко не всегда уместен, часто его проще и лучше заменить ACL (безусловно, это не всегда так).

PSR-3 - это не совсем паттерн, это скорее рекомендуемое соглашение.

Конкретно по php миру: рекомендую реализовывать следующие требования, проникнуться Symfony way, активно использовать паттерны: DTO, VO, код писать вместе с тестами (вот это капец как критично для крупных систем).

Что касается более высокоуровневых паттернов, в стиле OAuth, RBAC - они вам потребуются только в случае, если это требуется бизнесу, для которого вы пишете систему.

Возможно. Раз очень срочно нужно, я сэкономил ваше время, составив релевантные поисковые запросы:
javascript выполнение функции через определенное время
javascript смена класса элемента

Вы не проверяете вставляемый роут, а что если я туда объект вместо строки влеплю? Если что-то влетело не так - бросайте исключение.

Не используйте супер глобальные переменные. В начале создайте объект Request и уже с ним работайте.

Не ясно, зачем нужны trim-ы, urldecode и т.д. Если что-то пришло не так как надо - роут не найден, и ничего более. Это не проблема роутера, что ему могут каку вбросить.

callable - это довольно специфическая хрень. Это может быть массив из двух строк, функция, объект со строкой, просто строка. Нахрен это дерьмо. Используйте тогда уже \Closure.

Если у вас все равно регулярки всюду - имеет смысл использовать именованные последовательности:

|(?P<id>\d+)|
|(?P<name>[a-Z]+)|

Замены паттернов имеет смысл делать при вставке роута, а не на момент диспатча.

Форматирование...
Почитайте про PSR-2

З.Ы. Когда наиграетесь - возьмите готовое и качественное в Symfony/Silex))

PHP для начинающих» 2005-го года, где это сделано так: если логин и пароль правильные, то создаётся сессия с единственной переменной в ней user_id, в которой хранится айди пользователя в базе или 0, если пользователь не залогинен. Она же и используется для проверки доступа. Но у меня есть подозрение, что это не совсем правильно и не очень безопасно.

Кажется эта книга напечатана с еще более старой.
1. в базе - ид, логин и хешированный пароль.
2. в сессии какой нибудь uid. Если uid в сессии нет - пользователь гость.
как это между собой взаимодействует - на ваше усмотрение.