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

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

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

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

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

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

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

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

    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
    Ответ написан
    1 комментарий