Когда использовать "маршрутизацию на стороне клиента" или "маршрутизацию на стороне сервера"?

Я немного запутался в этом, и я чувствую себя немного глупо, задавая этот вопрос, но я хочу это понять.

Итак, скажем, я работаю с веб-картой на стороне клиента, например Backbone, Angular или Durandal. Эта структура включает в себя маршрутизацию.

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

Теперь мой вопрос:

Когда использовать "маршрутизацию на стороне клиента" или "маршрутизацию на стороне сервера"?

Как принято решение о том, выполняется ли маршрутизация уже на стороне клиента или первый запрос отправляется на веб-сервер?

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

Я был бы очень благодарен, если бы кто-нибудь мог объяснить, как эти две системы маршрутизации работают вместе.

P.S.: Я не включал примеры кода, потому что я не ищу ответа о конкретной структуре, но касаюсь процесса маршрутизации вообще.

Ответ 1

TL;DR:

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

Представьте, что пользователь нажимает на простую ссылку: <a href="/hello">Hello!</a>

В веб-приложении, использующем маршрутизацию на стороне сервера:

Браузер обнаруживает, что пользователь нажал на элемент привязки.
Он делает HTTP-запрос GET URL-адресу, найденному в теге href
Сервер обрабатывает запрос и отправляет новый документ (обычно HTML) в качестве ответа.
Браузер полностью отбрасывает старую веб-страницу и отображает недавно загруженную.

Если webapp использует маршрутизацию на стороне клиента:

Браузер обнаруживает, что пользователь нажал на элемент привязки, как и раньше.
Клиентский код (обычно это библиотека маршрутизации) ловит это событие, обнаруживает, что URL-адрес не является внешней ссылкой, а затем запрещает браузер делать запрос HTTP GET.
Библиотека маршрутизации затем вручную изменяет URL, отображаемую в браузере (используя API истории HTML5 или, возможно, URL-адреса хэширования в старых браузерах)
Библиотека маршрутизации затем изменяет состояние клиентского приложения. Например, он может изменить исходный файл React/ Angular/etc в соответствии с правилами маршрута.
Приложение (в частности, библиотека MVC, например React), затем обрабатывает изменения состояния. Он отображает новые компоненты, и при необходимости он запрашивает новые данные с сервера. Но на этот раз ответ не обязательно является цельной веб-страницей, он также может быть "сырыми" данными, и в этом случае клиентский код превращает его в HTML-элементы.

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

Существует несколько сторон маршрутизации на стороне клиента: вы загружаете меньше данных, чтобы отображать новый контент, вы можете повторно использовать элементы DOM, отображать уведомления о загрузке пользователю и т.д. Однако веб-приложения, которые генерируют DOM на стороне сервера, намного проще сканировать (поисковыми системами), тем самым упрощая оптимизацию SEO. Комбинирование этих двух подходов также возможно, отличный пример Router SSR является хорошим примером для этого.

Ответ 2

Я думаю, что маршрутизация клиентской стороны используется одностраничными приложениями, где фактический сайт никогда не остается.

Маршрутизация работает, присоединяясь к текущей странице, на которой реагируют рамки маршрутизации на стороне клиента.

index.html #/mysubpage

Маршрутизация на стороне сервера похожа на то, что apache делает по умолчанию при вызове дочернего узла по его URL-адресу, но node.js делает это с помощью маршрутов, потому что html файлы должны отображаться первый.

Если у вас есть SPA с инфраструктурой маршрутизации на стороне клиента, и вы используете node.js, вам все равно нужна маршрутизация на стороне сервера для переключения между сайтами.