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

Уважаемый index0h.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой php open source срипт/движок использовать для хранения/распространения изображений?

Алексей Романенко: сжатие имею ввиду компрессию по размеру, 20кб -> 10кб без потери качества, нет такого?

Какой php open source срипт/движок использовать для хранения/распространения изображений?

Подскажи, минио сервер это хранилище, а ресайзер работа с размером. Не нашел функций сжатия изображений и еще желательно удаление белого фона)

Почему nginx недоступен во время reload?

Актуально еще? часто пересобирается? сорцы докачиваете? покажите nginx -V

От куда вебсервер берет параметр host?

да точно спасибо

Оцените запрос с точки зрения производительности?

Можно, но у вас openserver древний, хорошобы его обновить сначала, и использовать современную версию Mysql

Оцените запрос с точки зрения производительности?

dmsirotenko: Признаться я не умею работать с движком MyIsam и не смогу дать дельного по оптимизации запроса при текущих индексах и типах таблиц.
Первоначальная рекомендация сводится к разделению запроса минимум на 2
1. SELECT BookId, Title FROM libbook WHERE book.Title LIKE '%стартап%' ORDER BY book.BookId ASC;
2. Во втором запросе по полученным BookId добрать остальное
avtorname.FirstName, avtorname.LastName
FROM libavtor avtor, libavtorname avtorname
WHERE avtor.AvtorId = avtorname.AvtorId AND avtor.BookId in ( )

Это немного облегчит тем что интерпритатор при поиске и сортировке не будет в теле таскать 3 таблицы, но не уверен что намного.

Вообще хорошо бы обновиться до 5.6 изменить движки на innodb повесить кластерные индексы на libavtor, libavtorname, и полнотекстовый индекс на BookId

Оцените запрос с точки зрения производительности?

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

Оцените запрос с точки зрения производительности?

Rsa97: увы одним explain сыт не будешь, тем более в данном случае, или предлагаете послать изучать dev.mysql.com/doc ? зачем тогда вообще нужен тостер если есть мануалы

Оцените запрос с точки зрения производительности?

сделайте SHOW VARIABLES LIKE "%version%";

Erlang как получить текущий урл?

Спасибо! подошло)