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

Question

[Александр]

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

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

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

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

Есть ли у сообщества пример таких кейсов из жизни, с цифрами?

Answer 1

[Fortop]

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

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

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

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

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

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

Но более правильным было бы выполнять анализ рассматривая конкретную структуру проекта

Comments

[Александр]

Расскажите пожалуйста чуть подробнее, что именно глючит? какие еще есть подводные камни?

Профита нет по сравнению с чем? вы до этого тоже на php рендерили?

Вопрос не столько про скорость работы апи, сколько про связи Ноды с php.

[Fortop]

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

Вопрос не столько про скорость работы апи, сколько про связи Ноды с php.

Связывайте их между собой через БД, мемкеш, очереди данных.
Это если абстрактно. Т.е. вы передаете данные в первую очередь.
Соответственно сервисы становятся language-agnostic.
Достаточно выбрать формат обмена данными (json, msgpack, protobuff, xml) и вперед.

Если нужен более конкретный кейс, то попробуйте получше описать что же именно за вопрос вы решаете

[Александр]

Т.е. Нода все таки не узкое место? И держать клиетсайд на ней вам нравится? Вопрос от куда брать данные?

[Fortop]

Т.е. Нода все таки не узкое место? И держать клиетсайд на ней вам нравится?

Не не, не путайте теплое с мягким :)

На ноде можно писать приложения. Но в общем случае скрещивать ноду и пхп практически не требуется. Они +/- равноценны.

Вопрос от куда брать данные?

Вам их генерируют сервисы вашего приложения.
Но обмен между ними лучше производить через БД. Т.е. нода должна брать их из БД/очереди/мемкеша

Answer 2

[index0h]

Появились мысли вынести фрондетнд из основного репозитория.

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

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

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

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

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

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

Comments

[Александр]

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

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

Декларативный стиль, сам по себе существенно упрощает поддержку, переделанная компонентная структура где стили и скрипты очевидно взаимодействуют с версткой тоже даст эффект. А также бэкенд разработчики перестанут взаимодействовать с версткой. Переход на ноду в основном связан именно с декларативным стилием разработки, без нее не отрендерить, v8js не предлагать.

Микросервисы возможно не нужны соглашусь. Зависит от того как сложится рендеринг в итоге.

[Fortop]

Александр,

связи между версткой стилями и скриптами нет

А ее и не должно быть. С версткой и стилями скрипты никак не связаны. С ними должны быть связаны наборы данных, которые генерируются этими скриптами.

А также бэкенд разработчики перестанут взаимодействовать с версткой.

В общем случае не перестанут. Если только не разносить на собственно фронт приложение и набор API
Но оно не всегда нужно, что забавно.

Что касается этого

Переход на ноду в основном связан именно с декларативным стилием разработки

Нода сама по себе не дает декларативный стиль. Декларативный стиль разработки это SQL, XML, шаблоны (на любом языке).

[Александр]

А ее и не должно быть. С версткой и стилями скрипты никак не связаны. С ними должны быть связаны наборы данных, которые генерируются этими скриптами.

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

В общем случае не перестанут. Если только не разносить на собственно фронт приложение и набор API
Но оно не всегда нужно, что забавно.

В этом и цель разнести бэкенд и фронтенд.

Нода сама по себе не дает декларативный стиль.

Нода дает поддержку декларативного стиля именно в js.

[index0h]

Александр

Вынести фронтенд из репозитория потому что он по структуре сейчас находится в каше, часть кусками в структуре срм,

Т.е. вы хотите кашу вынести в отдельный репозиторий и надеетесь, что в нем она перестанет быть кашей, я ничего не путаю?

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

Так себе заявление если честно.

Хочется сделать по уму, навести красоту и к вопросу не возвращаться.

Вот тут у вас глобальное не понимание. Качество кода - это постоянный труд, его нельзя сделать раз и хорошо. Он развивается и переписывается. Что бы у вас был красивый код - выносить его в отдельный репозиторий не поможет.
Тут нужны жесткие соглашения, например такие

Декларативный стиль, сам по себе существенно упрощает поддержку

С чего вы это взяли?))

А также бэкенд разработчики перестанут взаимодействовать с версткой

Э.. чо?? Вы ж с самого начала написали, что на бэке рендеринг!

Переход на ноду в основном связан именно с декларативным стилием разработки

Да ни как не связан декларативный стиль с нодой. Вы ничего не выиграете вынося рендеринг в ноду. Я понимаю, если бы у вас было некое SPA, и нода нужна была только для сборки через какой-нить webpack+less+gulp. Это ясно.
Но вынеся рендеринг на ноду, по сравнению с php вы сразу же столкнетесь с сложностями поддержки асинхронного кода. То что в php пишется как последовательность вызовов - в ноде будет писаться как вереница из промисов в промисах в промисах. Асинк/Авейт вас вот ни капли от этого безумия не спасет.

Нода дает поддержку декларативного стиля именно в js.

Может я чего не понимаю, что вы вкладываете в понятие "декларативный стиль"?

[Александр]

Уважаемый index0h.

Т.е. вы хотите кашу вынести в отдельный репозиторий и надеетесь, что в нем она перестанет быть кашей, я ничего не путаю?

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

Так себе заявление если честно.

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

Вот тут у вас глобальное не понимание. Качество кода - это постоянный труд

Про красоту имелась ввиду архитектура взаимодействия, по качеству кода иллюзий не питаем.

Э.. чо?? Вы ж с самого начала написали, что на бэке рендеринг!

рендеринг на ноде не перестает быть рендерингом на бэкенде. Но поддерживать его уже будут другие специалисты.

С чего вы это взяли?))

Да ни как не связан декларативный стиль с нодой.

Может я чего не понимаю, что вы вкладываете в понятие "декларативный стиль"?

У нас есть довольно много опыта в разработке и поддержке SPA приложений, мы используем фреймворки с декларативным стилем. Для нас декларативный стиль удобен, дает скорость, качество и делает процесс разработки приятным. Это конечно не делает этот подход серебряной пулей, и мы не уговариваем ни кого его использовать. Однако наш выбор обусловлен цифрами в том числе. Мы хотели бы его использовать в проекте чувствительном для СЕО. И других способов кроме ноды не видим, v8js нас не устраивает.

По поводу поддержки промисов, асинхронности мы понимаем как это поддерживать с точки зрения кода.

Большое спасибо за комментарий. Но данный топик был сформулирован в поисках отзывов от сообщества у кого был опыт работы с данным кейсом. Интересуют подробности девопс, и отзывы из реально работающих проектов. Если у вас есть чем поделится в данном контексте, очень просим.