iMegaMaximus

Да состояние собирается на сервере для каждого клиента (request'a), скажем на уровне мидлвара мы собираем состояние (текущего авторизованного пользователя, какие-то другие глобальные данные), далее отрабатывает обработчик маршрута, мы получили данные какой-то страницы из бд и передали их как контекст, примерно так:

import React from 'react';
import { StaticRouter } from 'react-router'
import { Provider } from 'react-redux'
import ReactDOMServer from 'react-dom/server';

import App from './client/components/App.jsx'

ReactDOMServer.renderToString(
	<Provider store={ReduxStore}>
		<StaticRouter
			location={Url}
			context={Context}>
			<App/>
		</StaticRouter>
	</Provider>
);

Где, ReduxStore сгенерированное нами глобальное состояние (redux) запроса, Url запрошенный урл, Context контекст (будет передано как this.props.staticContext в компонент). Реакт вытянет нужный контейнер роута (по вашим маршрутам в App) и передаст ему контекст, компонент рендерится исходя из полученных данных. Результатом работы метода renderToString будет html строка (размеченная реактом), которую мы шаблонизатором или как угодно впиливаем в блок моунта компонента (в верстке), дополнительно в шаблонизатор передаем сгенерированное состояние, в документации выглядит вот так:

window.__PRELOADED_STATE__ = JSON.stringify(preloadedState || {}).replace(/</g, '\\u003c')

Теперь что происходит после того как страница загрузилась и подхватились клиент-скрипты? Все просто мы подхватываем состояние из window.__PRELOADED_STATE__ и вообщем-то все, глобальное состояние передано, компонент уже отрендерен, стоит учитывать что результаты при клиент-рендере и при сервер-рендере должны быть всегда одинаковыми, так же не использовать методы доступные браузеру, но не доступные серверу (на уровне моунта и первого рендера) и хорошенько следить за своим кодом в плане памяти, иначе при какой-либо утечке, память на сервере не будет вычищаться после каждого рендера.
---
Как-то так, надеюсь помог, хотя там еще довольно много заковык

я делаю `clean` или `refactor`, если код разбивался или переносился между модулями.

Основная функция git checkout это перемещать указатель HEAD, т.е. то куда смотрит ваша локальная копия. Вы можете переместить его на вершину ветки: git checkout <branch> или на отдельный коммит: git checkout <sha>Ну а вспомогательные это создание веток:git checkout -b, отмена изменений в файле:git checkout -- <file>

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.