vkdv

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

Я это вижу примерно так :

1) Наймите Дизайнера / UХ-дизайнера и менеджера проекта. Начните разрабатывать интерфейсы, затрачивая на это по 3 - 4 часа вашего личного времени , все время менеджера и дизайнера.

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

Задачи дизайнера - понятны , он может начать с uikit и стилизации и переходить к самому сложному , как только менеджер подготовит тз для основным моментов(именно с самого главного я бы и начинал, например форм личного кабинета по объектам и коммиссии)

2) Как только будет появляться готовый дизайн (1-2 месяц) , вводите в работу верстальщика , Верстка должна быть сразу адаптивной . Скорее всего bootstrap. Первым делом верстальщик должен создать стили для UIKIT, после чего приступить к верстки страниц

3) Когда будет готова верстка страниц ЛК , нанимайте backend и front-end(при необходимости) разработчиков(например php - laravel и javascript/vue.js) Верстальщик пусть переходит к общим страницам и главной . Бэкенд и фронтенд разработчик бдут работать в паре несколько месяцев

Даже если вы решите использовать CMS или Bitrix - первые два пункта придется сделать заранее . К этому моменту будет примерно понятно , как лучше поступить с 3-м пунктом. И самое главное для исполнителя будут подготовленны все материалы , а вы сможете отвлечься на подготовку промо материалов

Апач и nginx не нужен (в идеале конечно нужен но в данном случае не обязателен )
На всякий случай убедись,что не упала нода ps ax|grep node
Убедись что нода слушает все айпи на сервере (0.0.0.0)

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
}).listen(3000, "0.0.0.0");

Открой порт наружу
iptables -A OUTPUT -p tcp --dport 3000 -j ACCEPT
iptables -A INPUT -p tcp --dport 3000 -j ACCEPT

проверь мой_серверный_айпи:3000 - Должно работать
Хотя это все не правильно конечно, правильно будет сделать поддомен или домен с обычным 80 портом и в nginx для данного хоста сделать редирект(proxy pass) на 127.0.0.1:3000

Можно, но с помощью костыльных либ - reactphp.org (https://toster.ru/q/233230)
Но это будет уже немного не тот "код" что был до этого, так как память выгружаться не будет, и как следствие возможны неожиданности в рабочем коде

Может я не понял проблему, но я ее не вижу, если дата заранее известна, то betwen.
Если хочешь сгруппировать в выборке по дням, можно делить на сутки (60*60*24), тогда
получишь порядковые номера дня от текущей даты в обратную сторону, а в пхп, если надо получить дату использовать встроенные функции и приводить к виду date() - index day

Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

Ссылка на SOLID

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

Один из наиболее часто встречающихся мне примеров, это пример принципа "Принцип открытости/закрытости" , когда класс - описывающий некую сущность(например модель комментария) , описывает только свои базовые назначения( создание, удаление, редактирование), при этом такие механизмы, как модерация, прикрепление файлов, лайки , реализуется другими классами и "прикручиваются" к классу моделей через интерфейсы и наследование/ трейты / примеси

При этом :
1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

Из википедии :

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

Оттуда же про SOLID

Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

Принцип единственной ответственности (The Single Responsibility Principle)
Существует лишь одна причина, приводящая к появлению класса.

Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

Принцип разделения интерфейса (The Interface Segregation Principle)
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»

1) vuejs - простой и ненавязчивый фреймворк который призван максимально просто и тесно взаимодействовать с произвольной версткой, в этом плане он очень похож на angular 1 , только проще, чище и чуть логичнее. При этом оп предоставляет инструменты для компонентного подхода(для фанатов клиента) и даже серверный рендеринг. На мой взгляд vuejs - это идеальное решение для быстрой разработки с допустимым уровнем качества.

2) Backbone - это далеко не библиотека и он в прошлом. Его главный минус - это невозможность управлять поведением dom, если этот dom не был сформирован через backbone-engine. Что делает его почти бесполезным, если только ты не хочешь написать проект , который будет намертво зависеть от выбранного инструмента и в котором будет невероятное множество клинтских шаблонов

3) React - это скорее концепция + движек для ее реализации, чем фреймворк Его существенный плюс в том, что верстка идет с изолированной логикой в паре, но это плюс скорее концептуальный , точно также можно поступать и используя jquery в изолированом скоупе прямо в верстке в html- фалах - виджетах (Я пробовал уже после реакта и это очень просто и надежно, но я fullstack и мне от клиента большего не нужно)
Минус реакта в том, что верстка должна рендериться только через шаблонизатор реакта, это значит что весь проект нужно рендерить через реакт иначе же в проекте будет хаос.

4) Ember - тоже говорят вещь хорошая, но я бы никогда не выбрал Ember по той же причине что и backbone.
5) Riot и еще 50 подобных фреймворков похожи либо на Angular, либо подражают React, либо идут по пути Backbone&Ember или же какие-то "гибридные" со своими фишками.
6) Angular 2 - я пока не понял его фишку.

Если рассматривать весь этот зоопарк с точки зрения бизнеса - то лучше выбрать то, что максимально проще и либеральней

Прости что лезу не в свое дело, но мое мнение, что yii2 лучше вообще не изучать. Изучай Laravel/Symphony etc

Приведу несколько аргументов (в сравнении с laravel):

1) Yii2 довольно слабо следует принципам SOLID и более того, не предоставляет в достаточной мере архитектурного решения разработчику, чтобы он сам им следовал
2) Yii2 Костылен, а его исходники мягко говоря не очень. Например behaviors (костыль) против middlware(прозрачное решение)
3) Yii2 Имеет устаревшие сервисы из коробки относительно Laravel , который развивается куда более активно.
Помимо прочего в Laravel намного больше готовых сервисов (Elixir , scheduling, Queue , Blade, Storage, Broadcast , Notifications) Вместо этого в yii2 есть только bower assets - который представляет с собой дикий костыль и откровенно ужасен, да еще и не безопасен, а также вроде в yii2 есть сервис для работы с файловой системой, но я с ним не работал. Остальные сервисы типа bootstrap , console etc есть и там и там
4) Магия Yii2 не способствует контролю за кодом и прозрачности
5) Yii2 имеет довольно плохо продуманную архитектуру, о чем говорит например тот факт, что jquery вшит в ядро фреймворка (возможно и некоторые другие ассеты) и это очень странно. Особенно когда тебе нужно запускать консольные приложения
6) ActiveRecord в yii2 доволбно запутан, по сравнению с https://laravel.com/docs/5.3/queries (кончено это субъективно)
7) Yii2 не особо популярен в мире, у него плохая документация и я думаю он серьезно отстоет от конкурентов.

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