@SpaceMaster1

Nodejs ssr и микросервисы, как правильно готовить?

На реализованном 80% на php. Появились мысли вынести фрондетнд из основного репозитория.
В целях структурировать кодовую базу, внедрить декларативный стиль в js, упростить поддержку, понизить порог входа, и иметь возможность нанимать более компетентных и узкоспециализированных разработчиков и прочие существенные для проекта плюсы.

Проект чувствителен к сео поэтому рендерить страницу нужно на сервере.

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

В связи с этим вопрос, как правильно готовить? возможна ли работы между нодой и php по постоянным соединениям? возможно ли использовать бинарные протоколы? возможно ли параллелить запросы на сервисы, и какой профит ждать?

Есть ли у сообщества пример таких кейсов из жизни, с цифрами?
  • Вопрос задан
  • 399 просмотров
Решения вопроса 1
@Fortop
Tech/Team lead
Нода на хите рендерит страницу на основе запросов в другие сервисы. В связи с высоким количество компонент на странице, запросов к сервисам может быть десятки. Десятки http запросов в одни и те же сервисы, это повторяющиеся накладные расходы на инициализации соединений, проверки прав, аналитики и т.п.

Примеры есть. Примеры в целом негативные.

В виде API на php и фронта на angular + angular Universal (как раз ваш кейс рендеринга на стороне бекенда).
Все это дело глючит. Мидлы полностью справиться не в состоянии на протяжении больше полугода. А синьоры палочкой его потыкают и сбегают.

Причем, что забавно, профита как такового нет. Сам Universal появился как попытка заткнуть дырку сео в том числе.

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

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

Но более правильным было бы выполнять анализ рассматривая конкретную структуру проекта
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
index0h
@index0h
PHP, Golang. https://github.com/index0h
Появились мысли вынести фрондетнд из основного репозитория.

Рендеринг же на бэке, зачем?

иметь возможность нанимать более компетентных и узкоспециализированных разработчиков

Это как бы вообще не связано))

упростить поддержку, понизить порог входа

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

Если я правильно понял - нода вам не нужна. Для рендеринга страниц php в принципе создавался.
Я не знаю, что у вас за проект, но вполне возможно микросервисы вам тоже не нужны.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы