История изменений

React на сервере теперь

Чегоо?

когда ты на урл щелкаешь в браузере, тебе страничку рендерит JS на клиенте. Но гугл у тебя при переходе на тот же урл не сможет запустить настолько сложный JS, у него движок JS примитивный и ограниченный по времени. Кроме того, юзер может перейти на этот урл по внешней ссылке с ЛОР-а, и будет крайне огорчен, если ему страничка будет рендериться не сразу, а с промежуточными этапами. Поэтому у тебя два сценария: в браузере JS, а при прямом переходе тебе совершенно идентичную страничку нужно отрендерить на сервере.

так как UI у тебя весь написан на Angular / React / Vue / …, то если коротко, это означает, что и в браузере и на сервере у тебя должен быть один и тот же реакт (чтобы не перечислять их все, пусть здесь и далее героем будет реакт). Но так как реакт - это никакой не стандарт и не спецификация, то существует ровно один способ заиметь реакт - запустить его единственную на свете джаваскрипт реализацию прямо на сервере, и вот она будет тебе рендерить странички по прямой ссылке. Способности Джавы запускать JS даже с учётом GraalVM - крайне слабые, поэтому по сути, тебе нужно иметь на сервере Node.js в качестве генератора страниц по-любому. Куда ты уж его впендюришь - вопрос второй, но самый простой способ - поставить её фронт-сервером

заметь, что речь тут шла именно о server side rendering, а не о static site generation. Именно о случае, когда сгенерированный результат может варьироваться в зависимости от текущего состояния пользователя, параметров урла и других глобальных обстоятельств - то есть, заранее отрендерить это всё как статический сайт и вложить на nginx нельзя

а почему нужен именно Node.js на бэкэнде

на каком из бэкендов? Напоминаю, у тебя микросервисная архитектура, значит серверов (микросервисов) будет херова гора. Ноду я предлагал использовать в качестве фронт-сервера (то есть, того сервера, к которому напрямую обращается браузерный фронтенд, и дальше фронт-сервер передает вычислительные запросы сети микросервисов например на Java… или на Ruby?).

Почему нода удобна в качестве фронт-сервера: потому что это упрощает утилитарные вопросы вроде пресловутого протокола общения между браузером и фронт-сервером, у тебя на сервере протокол разбирает тот же код, что и в браузере, и это уменьшает количество ошибок в этом коде, и сами протоколы становятся все более навороченными потому что не нужно описывать «протокол» - достаточно написать какой-то код, который делает дело.

Упрощаются разные элементарные штуки вроде того, что всё равно тебе весь браузерный фронтенд нужно собирать Webpack-ом и Babel-ем, то есть нода уже используется в процессе сборки любой HTML страницы, и можно упростить процесс выкладки, заставив ноду же и отрабатывать простейшие запросы.

Всеми этими вопросами вроде провязки браузер-серверного API, выкладкой, управлением зависимостями, итп могут заняться фронтендеры без помощи бэкендеров. Каждый наконец находится на своём месте. Тем более, что джава-бэкендеры как правило срать хотели на богомерзкий JS и наоборот, а фронтендеры о том как работает бэк имеют самое смутное представление и SQL в последний раз видели в голливудских хоррор фильмах. У всех у них совершенно разыне пайплайны сборки, CI/CD, дистрибуции, итп, и это дополнительно развязывает руки.

Там есть более умные способы вроде GraphQL, который позволяет наладить диалог между фронтендерами и бэкендерами, но это еще один пласт истории.

Конечно, надо не забывать про Flutter, который может теоретически убить весь современный веб и мобайл, переведя всё на совершенно новый гибридный фронтенд, общий для мобилы и веба. Туда же Kotlin Native. И там везде будут свои нюансы. Не надо забывать про Progressive Web Apps, у которых пайплайн разработки и дистрибуции несколько другой.

React на сервере теперь

Чегоо?

когда ты на урл щелкаешь в браузере, тебе страничку рендерит JS на клиенте. Но гугл у тебя при переходе на тот же урл не сможет запустить настолько сложный JS, у него движок JS примитивный и ограниченный по времени. Кроме того, юзер может перейти на этот урл по внешней ссылке с ЛОР-а, и будет крайне огорчен, если ему страничка будет рендериться не сразу, а с промежуточными этапами. Поэтому у тебя два сценария: в браузере JS, а при прямом переходе тебе совершенно идентичную страничку нужно отрендерить на сервере.

так как UI у тебя весь написан на Angular / React / Vue / …, то если коротко, это означает, что и в браузере и на сервере у тебя должен быть один и тот же реакт (чтобы не перечислять их все, пусть здесь и далее героем будет реакт). Но так как реакт - это никакой не стандарт и не спецификация, то существует ровно один способ заиметь реакт - запустить его единственную на свете джаваскрипт реализацию прямо на сервере, и вот она будет тебе рендерить странички по прямой ссылке. Способности Джавы запускать JS даже с учётом GraalVM - крайне слабые, поэтому по сути, тебе нужно иметь на сервере Node.js в качестве генератора страниц по-любому. Куда ты уж его впендюришь - вопрос второй, но самый простой способ - поставить её фронт-сервером

заметь, что речь тут шла именно о server side rendering, а не о static site generation. Именно о случае, когда сгенерированный результат может варьироваться в зависимости от текущего состояния пользователя, параметров урла и других глобальных обстоятельств - то есть, заранее отрендерить это всё как статический сайт и вложить на nginx нельзя

а почему нужен именно Node.js на бэкэнде

на каком из бэкендов? Напоминаю, у тебя микросервисная архитектура, значит серверов (микросервисов) будет херова гора. Ноду я предлагал использовать в качестве фронт-сервера (то есть, того сервера, к которому напрямую обращается браузерный фронтенд, и дальше фронт-сервер передает вычислительные запросы сети микросервисов например на Java… или на Ruby?).

Почему нода удобна в качестве фронт-сервера: потому что это упрощает утилитарные вопросы вроде пресловутого протокола общения между браузером и фронт-сервером, у тебя на сервере протокол разбирает тот же код, что и в браузере, и это уменьшает количество ошибок в этом коде, и сами протоколы становятся все более навороченными потому что не нужно описывать «протокол» - достаточно написать какой-то код, который делает дело.

Упрощаются разные элементарные штуки вроде того, что всё равно тебе весь браузерный фронтенд нужно собирать Webpack-ом и Babel-ем, то есть нода уже используется в процессе сборки любой HTML страницы, и можно упростить процесс выкладки, заставив ноду же и отрабатывать простейшие запросы.

Всеми этими вопросами вроде провязки браузер-серверного API, выкладкой, управлением зависимостями, итп. Каждый наконец находится на своём месте. Тем более, что джава-бэкендеры как правило срать хотели на богомерзкий JS и наоборот, а фронтендеры о том как работает бэк имеют самое смутное представление и SQL в последний раз видели в голливудских хоррор фильмах. У всех у них совершенно разыне пайплайны сборки, CI/CD, дистрибуции, итп, и это дополнительно развязывает руки.

Там есть более умные способы вроде GraphQL, который позволяет наладить диалог между фронтендерами и бэкендерами, но это еще один пласт истории.

Конечно, надо не забывать про Flutter, который может теоретически убить весь современный веб и мобайл, переведя всё на совершенно новый гибридный фронтенд, общий для мобилы и веба. Туда же Kotlin Native. И там везде будут свои нюансы. Не надо забывать про Progressive Web Apps, у которых пайплайн разработки и дистрибуции несколько другой.

React на сервере теперь

Чегоо?

когда ты на урл щелкаешь в браузере, тебе страничку рендерит JS на клиенте. Но гугл у тебя при переходе на тот же урл не сможет запустить настолько сложный JS, у него движок JS примитивный и ограниченный по времени. Кроме того, юзер может перейти на этот урл по внешней ссылке с ЛОР-а, и будет крайне огорчен, если ему страничка будет рендериться не сразу, а с промежуточными этапами. Поэтому у тебя два сценария: в браузере JS, а при прямом переходе тебе совершенно идентичную страничку нужно отрендерить на сервере.

так как UI у тебя весь написан на Angular / React / Vue / …, то если коротко, это означает, что и в браузере и на сервере у тебя должен быть один и тот же реакт (чтобы не перечислять их все, пусть здесь и далее героем будет реакт). Но так как реакт - это никакой не стандарт и не спецификация, то существует ровно один способ заиметь реакт - запустить его единственную на свете джаваскрипт реализацию прямо на сервере, и вот она будет тебе рендерить странички по прямой ссылке.

заметь, что речь тут шла именно о server side rendering, а не о static site generation. Именно о случае, когда сгенерированный результат может варьироваться в зависимости от текущего состояния пользователя, параметров урла и других глобальных обстоятельств - то есть, заранее отрендерить это всё как статический сайт и вложить на nginx нельзя

а почему нужен именно Node.js на бэкэнде

на каком из бэкендов? Напоминаю, у тебя микросервисная архитектура, значит серверов (микросервисов) будет херова гора. Ноду я предлагал использовать в качестве фронт-сервера (то есть, того сервера, к которому напрямую обращается браузерный фронтенд, и дальше фронт-сервер передает вычислительные запросы сети микросервисов например на Java… или на Ruby?).

Почему нода удобна в качестве фронт-сервера: потому что это упрощает утилитарные вопросы вроде пресловутого протокола общения между браузером и фронт-сервером, у тебя на сервере протокол разбирает тот же код, что и в браузере, и это уменьшает количество ошибок в этом коде, и сами протоколы становятся все более навороченными потому что не нужно описывать «протокол» - достаточно написать какой-то код, который делает дело.

Упрощаются разные элементарные штуки вроде того, что всё равно тебе весь браузерный фронтенд нужно собирать Webpack-ом и Babel-ем, то есть нода уже используется в процессе сборки любой HTML страницы, и можно упростить процесс выкладки, заставив ноду же и отрабатывать простейшие запросы.

Всеми этими вопросами вроде провязки браузер-серверного API, выкладкой, управлением зависимостями, итп. Каждый наконец находится на своём месте. Тем более, что джава-бэкендеры как правило срать хотели на богомерзкий JS и наоборот, а фронтендеры о том как работает бэк имеют самое смутное представление и SQL в последний раз видели в голливудских хоррор фильмах. У всех у них совершенно разыне пайплайны сборки, CI/CD, дистрибуции, итп, и это дополнительно развязывает руки.

Там есть более умные способы вроде GraphQL, который позволяет наладить диалог между фронтендерами и бэкендерами, но это еще один пласт истории.

Конечно, надо не забывать про Flutter, который может теоретически убить весь современный веб и мобайл, переведя всё на совершенно новый гибридный фронтенд, общий для мобилы и веба. Туда же Kotlin Native. И там везде будут свои нюансы. Не надо забывать про Progressive Web Apps, у которых пайплайн разработки и дистрибуции несколько другой.