Задать вопрос
iskanderBS
@iskanderBS
GoLang developer

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

Всем здравствуйте.
Работаю 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, и вообще разработку станет вести легче и быстрее они оспаривают.
Хотелось бы узнать беспристрастное мнение знающих людей, в долгосрочной перспективе какое решение в действительности лучше себя покажет?
  • Вопрос задан
  • 407 просмотров
Подписаться 3 Средний Комментировать
Решения вопроса 1
notiv-nt
@notiv-nt
Как ваше ничего? Да, моё тоже
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
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
Robur
@Robur
Знаю больше чем это необходимо
В долгосрочной перспективе - то которое будет легче поддерживать.
Если ваш велосипед залить на прод, то остальным разработчикам надо будет во все это вникнуть, плюс поддержка и развитие, плюс все возможные будущие проблемы - все это надо будет пилить руками и с нуля. Так же архитектура должна быть хорошо подготовлена, и это вы должны явно показать, а учитывая что изначально все будут против - то и убедительно доказать.

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

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

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

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

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

Плюс велика вероятность что ваши девелоперы хотят "модно-молодежно" на "современных технологиях" это уже человеческий фактор и он будет самым проблемным.
Ответ написан
uvelichitel
@uvelichitel Куратор тега Go
habrahabr.ru/users/uvelichitel
Пишу backend на Go. Первым делом проектируется API и структуры данных. Фронтендеры говорят мне на каком URI они хотят получить какой JSON и моя задача предоставить это быстро и надежно. Как они собираются этот JSON рендерить мне вобщем то и неособо интересно.
не надо клиента грузить тоннами JS
категорически не согласен. Клиентов много а сервер один. Вычислительная мощность современных клиентов зачастую больше мощности сервера. Поэтому считаю, что на клиента нужно перекладывать столько работы сколько только возможно.
Ответ написан
Комментировать
@nrgian
Все мои аргументы, в том числе, что JS априори медленнее Go и не поддерживает многопоточность, нет нормального ООП, и что не надо клиента грузить тоннами JS ради full AJAX, и вообще разработку станет вести легче и быстрее они оспаривают.


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

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

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

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

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

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

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


При несложной логике - да.
При сложной логике - не все так очевидно.
Ответ написан
firedragon
@firedragon
Не джун-мидл-сеньор, а трус-балбес-бывалый.
Не насилуйте сервер клиентским кодом!
Отрисуйте все на сервере. закешируйте и отдавайте клиенту.
Дальше используйте фронт для подгрузки данных.
Какие плюсы:
1. 1 коннект к базе данных.
2. 1 статичный файл, который упадет в кэш.
3. 1 статичный файл проиндексируется поисковиками.
4. 1 раз проверяется токен, а не на каждый чих фронтэнда
Ответ написан
Комментировать
index0h
@index0h
PHP, Golang. https://github.com/index0h
Изоморфность дает буст только в случаях обычных crud+практически полного совпадения сущностей с бэка и фронта. Это годится для сатиков по заказу пиццы, или записи на стрижку. Но не для чегото среднего/крупного.
Ответ написан
Комментировать
@Anarmus
Рендерить страницы на Go, как мне кажется, не самая лучшая идея. Плюс зачем вам делать работу, которая, как я понял, не попадает в вашу зону ответственности? Ибо разбираться в этом и пользоваться не вам же, а фронтендщикам (у которых очень популярный фреймворк еле работает).
Если это аналог ozon.ru, то можно и подсмотреть стак у самого озона? Пишите бэкенд на Go, а фронт пусть фронтендщики пишут на связке Node.js + Nuxt.js + Vue.js, тогда вам и быстрый бэкенд, и возможность доступного рендера на стороне сервера, и изоморфность, и человеческий js-фреймворк для фронта.
P.S. Ну Angular реально дичь же.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы
ITK academy Нижний Новгород
от 80 000 до 120 000 ₽
ITK academy Воронеж
от 50 000 до 90 000 ₽