Стоит ли использовать изоморфное приложение в высоконагруженном e-commerce проекте?

Question

[Искандер Байгужаев]

Всем здравствуйте.
Работаю backend-разработчиком (golang) в одном достаточно крупном e-commerce проекте, ранее работал full-stack разработчиком. Сам проект представляет собой по функционалу аналог ozon.ru, то есть агрегирует товары от разных поставщиков. Сейчас это веб-приложение на angular без нормального SSR, клиент тянет кучу js-лапши и все это работает медленно и печально.
Я набросал mvc фреймворк на go, и написал прототип в котором рендерю страницы на сервере и отдаю статический html c очень маленьким js (только для ajax поиска, фильтрации, все постарался вырулить за счет css). Скорость работы космическая, page refresh даже не заметен глазу. Вдобавок мой фреймворк периодически опрашивает бэкенд и кэширует результаты в память (шаблоны страниц также храню в памяти), что также его ускоряет и делает более отказоустойчивым.
Но когда я предложил данный проект начался настоящий холивар. Все фронтендеры твердят, что это старье и не модно, не есть best practice и вообще они могут сделать изоморфное приложение с SSR, и все будет хорошо и page speed они 100 из 100 выбьют спокойно.
Все мои аргументы, в том числе, что JS априори медленнее Go и не поддерживает многопоточность, нет нормального ООП, и что не надо клиента грузить тоннами JS ради full AJAX, и вообще разработку станет вести легче и быстрее они оспаривают.
Хотелось бы узнать беспристрастное мнение знающих людей, в долгосрочной перспективе какое решение в действительности лучше себя покажет?

Answer 1

[Михаил]

1. Angular дичь, для вывода hello-world нужно собрать ракету, а для всего остального есть провайдеры.
2. Помимо ангуляра есть более удобные фреймворки, vue/react/svelte
3. Без SSR печально, ваш сайт не найдут (гугл найдет)
4. Компонентный подход легче чем разгебать кучи css/js файлов и собирать их для каждых страниц отдельно, а не в 1 огромный файл. Но было бы желание и прямые руки.
5. SPA можно написать быстрым, главное не засирать всякой дрянью по типу jquery/слайдеров/и прочего 100+кб говна
6. Сравнивание клиентского js и серверного go довольно странновато
7. "не надо клиента грузить тоннами JS ради full AJAX" ну ка бы да, пните фронтеров
8. "и вообще разработку станет вести легче и быстрее" на уровне прототипа может быть да, а в дальнейшем? На каждый запрос страницы генерить все заного, или просто подгрузить шаблон и данные?

вообще они могут сделать изоморфное приложение с SSR

На это вспомнил фразу: Да я отсюда запросто смог бы доссать до унитаза, но мне лень и по-этому я обоссался

Но раз уж начали, то доделайте, в конечном счете есть и MPA и SPA приложения, которые вполне себе живут и здравствуют
И да, добавьте SSR

Comments

[Искандер Байгужаев]

"и вообще разработку станет вести легче и быстрее" на уровне прототипа может быть да, а в дальнейшем? На каждый запрос страницы генерить все заного, или просто подгрузить шаблон и данные?

1. По идее проблем быть не должно, вся верстка компонентов описана в отдельных файлах и их структура соответствует структуре sass и js описывающих стили и логику компонента. На каждый эндпоинт вешается метод контроллера, в котором можно тянуть данные с моделей и обращаться к другим пакетам. Вообщем простой mvc.
2. Для неавторизованных пользователей отдаем статику с кэша, для авторизованных собираем c памяти, точнее вставляем в шаблон данные и отдаем.

Answer 2

[Robur]

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

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

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

Что можно сделать:
- определить реальные проблемы
- определить критерии их решения (скорость, размер, page speed и так далее)
- определить время за которое команда готова оптимизировать ангулярное приложение до нужных параметров

Если не сделают - поднять вопрос еще раз, показав свой вариант.

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

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

Comments

[Искандер Байгужаев]

есть достаточно серьезные объективные причины почему этого не стоит делать

Если можно описать немного подробнее пожалуйста.

[Robur]

Искандер Байгужаев, частично в первом абзаце.
В общем - любой велосипед требует заметно больше усилий по поддержке и развитию.
Нет проверенного кода ядра на который можно опереться и который уже протестировали тысячи других пользователей в разных условиях.
Нет сообщества где можно спросить решение проблемы.
Нет каких-то готовых решений даже простых задач - все надо изобретать или прикручивать сторонние библиотеки.
Нет проработанной схемы деплоя/тестирования
При приеме на работу нового разработчика он сможет начать приносить пользу заметно позже.
Знания по системе становятся очень неявными и сидят где-то в головах, при любой необходимости надо ходить и всех опрашивать что и как, это сложно, часто некогда и сильно растет вероятность добавления говнокода при апдейтах (причем в нелинейной прогрессии - чем дальше тем быстрее)
В целом, в начала это может быть очень хорошо, а через год-два превратиться в ад.
Чтобы не превратилось в ад, велосипед должны поддерживать сильные разработчики, и их сил должно хватать на борьбу с энтропией.

это то что сразу в голову пришло.

[Антон Спирин]

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

[Robur]

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

Answer 3

[uvelichitel]

Пишу backend на Go. Первым делом проектируется API и структуры данных. Фронтендеры говорят мне на каком URI они хотят получить какой JSON и моя задача предоставить это быстро и надежно. Как они собираются этот JSON рендерить мне вобщем то и неособо интересно.

не надо клиента грузить тоннами JS

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

Answer 4

[nrgian]

Все мои аргументы, в том числе, что JS априори медленнее Go и не поддерживает многопоточность, нет нормального ООП, и что не надо клиента грузить тоннами JS ради full AJAX, и вообще разработку станет вести легче и быстрее они оспаривают.

В общем случае скорость языка в вебе не критична.
Полно высоконагруженных проектов на медленных языках.

Ибо основные задержки не зависят от языка - это сеть и СУБД (и пр. связанные с дисками операции).

Впрочем, при нагрузке сервера очень большим числом клиентов и/или при очень сложной логике обработки (но не связанной с СУБД/дисками, а завязанной только на процессор) - скорость языка значение уже имеет.

У вас - как? В чем именно узкое место?

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

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

и что не надо клиента грузить тоннами JS ради full AJAX

При несложной логике - да.
При сложной логике - не все так очевидно.

Comments

[Искандер Байгужаев]

У вас - как? В чем именно узкое место?

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

[nrgian]

Искандер Байгужаев,

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

Если вся проблема только в клиенте - тогда аргументация за Go/не за Go вообще не при делах.
Тут вопрос не столько технического совершенства, а насколько знакомы те, кто будут делать клиент с той или иной технологией - насколько быстро они сделают, насколько оптимизировать клиентскую часть смогут.
Не зная до мелочей особенностей проекта - ничего и сказать нельзя.

Бизнес/"Владелец продукта" будет смотреть по скорости разработки и по её стоимости.

В принципе современное железо вполне потянет Angular. И современные быстрые сети не являются проблемой.

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

Если "владелец проекта"/бизнес считает, что работа на плохих соединениях важна или вы сможете убедить, что это незначительно удлинит/незначительно удорожит разработку - тогда да.

А просто техническое совершенство ради технического совершенства, но если вы закончите из-за этого проект на год позже - это никому не нужно точно.

Answer 5

[Владимир Коротенко]

Не насилуйте сервер клиентским кодом!
Отрисуйте все на сервере. закешируйте и отдавайте клиенту.
Дальше используйте фронт для подгрузки данных.
Какие плюсы:
1. 1 коннект к базе данных.
2. 1 статичный файл, который упадет в кэш.
3. 1 статичный файл проиндексируется поисковиками.
4. 1 раз проверяется токен, а не на каждый чих фронтэнда

Answer 6

[index0h]

Изоморфность дает буст только в случаях обычных crud+практически полного совпадения сущностей с бэка и фронта. Это годится для сатиков по заказу пиццы, или записи на стрижку. Но не для чегото среднего/крупного.

Answer 7

[Анар]

Рендерить страницы на Go, как мне кажется, не самая лучшая идея. Плюс зачем вам делать работу, которая, как я понял, не попадает в вашу зону ответственности? Ибо разбираться в этом и пользоваться не вам же, а фронтендщикам (у которых очень популярный фреймворк еле работает).
Если это аналог ozon.ru, то можно и подсмотреть стак у самого озона? Пишите бэкенд на Go, а фронт пусть фронтендщики пишут на связке Node.js + Nuxt.js + Vue.js, тогда вам и быстрый бэкенд, и возможность доступного рендера на стороне сервера, и изоморфность, и человеческий js-фреймворк для фронта.
P.S. Ну Angular реально дичь же.