Anubis

• layouts - целиковые страницы: главная, авторизация, регистрация
  Внутри для каждой страницы папка, в которой можно держать сколь угодно относящихся только к этой странице компонентов - шапка этой страницы, меню этой страницы, вспомогательная фигня этой страницы, подвал этой страницы
  
• components - повторно используемые в разных местах компоненты - инпуты, селекторы, галереи, эмбед видеоплеера и т.д.
  Также можно выделять сюда куски страниц (шапки, подвалы), используемые в нескольких layouts
  
• styles - общеиспользуемые стили (здесь можно задать некий index с подключением к нему reset/normalize, шрифтов, эмоджи и т.д., а затем подключать его к App.jsx)
  

Опционально можно выделить отдельную папку для App.jsx (при желании папку styles можно перенести туда же), либо определить его в layouts, как больше нравится, тут субъективно опираемся на внутреннее чувство фэн-шуя

Какой примерно код должен быть в скрипте для NodeJS для выполнения серверного рендеринкга SPA на React?

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

Не поверишь - для централизованного хранения всех данных сайта/приложения/сервиса/чего-угодно )))00
А реакт удобно и шустро нарисует посетителю то, что пришлёт бэкенд

test: /\.jsx?$/,
loader: 'babel-loader'

.babelrc presets env & react

Ну и npm i --save-dev их все соответственно

Мне помогло добавление resolve-url-loader перед postcss-loader/less-loader

https://redux.js.org/docs/recipes/ServerRendering.html
Я по этому гайду смог достичь желаемого функционала. Вместо Express заюзал более современный Koa. Суть в том, чтобы при обращении к нужной к рендерингу страницы, (если нужно, асинхронно) заполучить некие данные, выстроить на их основе первоначальное состояние store, выполнить renderToString из 'react-dom/server', полученный html внедрить в основной html, также внедрить в основной html состояние стора после рендеринга (см. window.__PRELOADED_STATE__ по ссылке) и выдать итоговый ответ в браузер. Далее на клиенте заюзать createStore, используя содержимое переменной стора, полученной от сервака, и юзать не ReactDOM.render, а ReactDOM.hydrate.

div с css-свойствами:

background-size: cover;
background-position: center;
background-image: url("...путь к фоновому изображению");

...и вписывайте в него нужное содержимое.
При желании можно как в примере указать ему фиксированную высоту.

Александр, доброго времени суток. Полагаю, на свой вопрос ответ уже нашли, теперь хотел бы обратиться к вам за консультацией. Сам проектирую браузерку — клиент на Unity, сервер на node.js, бд на redis (orm для неё на jugglingdb, очень похожа на mongoose), связь на tcp. Хочу сразу попробовать кластерную архитектуру, дабы потом не пришлось в спешке переписывать логику под неё в случае неожиданного роста онлайна.

Как и у вас, игрушка будет пошаговой (боёвка — в стиле jrpg). Единственное, что в бою завязано на таймер — выдача тому или иному игроку права хода на определённый лимит времени (таймаут хода) и централизованное управление просмотра анимаций ударов и заклинаний («анимация удара файрболлом 5 секунд, после передача хода следующему игроку»).

Вне боёв персонажам нужен временной луп для постепенного восстановления параметров.

Какого рода задачи логично распределить в воркеры? Допустимо ли использовать redis pub-sub для обмена очень большим количеством сообщений между потоками? Буду очень признателен вашим советам.

Для разработки игр есть хорошая среда Corona SDK. Как раз мультиплатформенна, правда лицензии нужно покупать отдельно. Для разработки под Android достаточно PC, если нужно писать под iOS — без Мака не обойтись. Код гораздо менее громоздкий, чем в нативном Xcode.