Всем привет! Вопрос по архитектуре проекта. Делаю интернет магазин, стэк angular

& php.

Так сложилось что вся бизнес логика зависит от одного запроса. Этот запрос - получение каталога.
Я достаю каталог и группирую их и создаю путь хлебных крошек.
Пример: главная -> смартфоны -> самсунг -> а20.

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

Получается так:
Я делаю запрос на получение всего каталога (800 обьектов, из за cloudfire занимает 1-2 сек, иногда 5 сек или 10 сек), затем я группирую их и создаю дерево с 3 мя уровнями вложенности. Пример: смартфоны и планшеты -> смартфоны -> apple, samsung...
Затем во время групптровки я нахожу нужную себе категорию, беру его id и делаю запрос на сервер на получения характеристик и тп.

По такой архитектуре если пользователь сразу переходить на странцу товара, он ждет пока загрузится каталог затем загрузиятся характеристики. Если каталог не загрузится то все хана).

Зависимость всего процесса от 1 запроса не очень, темболее если этот запрос порой занимает по 5-10 сек. Подскажите как решить данный вопрос?

Если предложете сохранить в localstorage, такое решение после получения каталога.

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

Может сначала характеристики каталога грузить, а потом крошки? Можно же без построения всего понять целевой каталог? Точнее сначала грузить товар

То есть при открытии карточки товара в приложение сразу загружается ВЕСЬ каталог из 800 позиций?

А забыл дописать. Если пользователь переходить сразу на страницу товара, то путь выглядит так domain.com/c/vse-smartphony/b-apple. Переход идет по keyword для seo. Фронтенд не знает какой id. Поэтому я получаю весь каталог, группирую их по ключевым слова и ищу по keyword. Я попросил бэкенд принимать keyword и по keyword доставать товар, но для бэка это будет слишком сложно, потому что фильтры продукта достаются по id, характеристики по id, хлебные крожки через рекурсию и еще есть такие моменты где нужно по id брать. И все переписать на keyword ну это не очень) легче фронту найти текущую категорию и отправить id но опять таки получение каталога занимает приличное время

На бэке это всяко проще и быстрее, чем на клиенте. Тем более если для этого нужен весь каталог

+ Очень плохая реализация В будущем может стать ещё хуже, нужно переделывать, пока не дорого

Да

Каталог меняется раз в пол года, я даже думаю на фронте захардкодить каталог как решение😂😂😂

Ну дело Ваше. Решение так себе в общем случае. Можно закэшировать и пользоваться, но фоном обновлять, но когда выстрелит - неизвестно. Узнаете ли когда выстрелит - неизвестно

Видите, у нас сайт и моб апп и 1 бэк. Если переписать бэк может сломатся моб апп. Апишка для мобилы делалась, под веб не планируют переписать (скорее всего)

Ну так бэк же можно расширить, а не изменить) Open closed principle, наконец то пригодился)

Ну да, ну упрямые не хотят)

Прояви софт-скиллс, объясни руководителю, что дешевле и эффективнее будет дописать бэк, чем коствлить фронт

Ну в целом это ненормальная х.ня. Команды должны одну цель преследовать. Если они 'не хотят' - это проблема

На бэке это все связано по id. фильтры, характеристики, фотки товара и хлебные крожки. Переписывание на keyword займет очень много времени, а сроки до конца месяца.

Это не займёт больше времени, чем на клиенте. Ну или по крайней мере судя по имеющейся информации, просто не хотят делать, не во времени дело

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

Ну или на бэке совсем все плохо

Скорее всего не хотят делать

Короче Главное- получить апрув от тимлида или кого то ещё на решение и уведомить, что бэк отказался. Вот с этого начать стоит А то потом крайним окажетесь

Я тим лид, бэкенд ведет руководитель)

Что за реакция😂😂😂

Ну странно все это. Если тимлид, то странно выглядят проблемы с бэком и решения

Я тимлид на фронте

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

а есть тимлид тимлидов?

Нет, мы договорились с бэком сначала по keyword делать, они даже начали делать, но потом поняли что очень много связок по id и апи для мобилы ламалось, поэтому я ищу альтернативное решение чтобы им было легче работы

Есть руководитель) Я на фронте, коллега на бэке, и есть руководитель проекта вот он все решает.

Ну типа странно, нахер трогать существующее если нужно новое сделать. Делали для фронта - сломали мобилки

У него апрув берите

Новое апи?

Новые методы, вестимо. Или тесты должны быть, насколько они там радикально меняли то все?

сделали небось generic через generic вот и ломается если что-то сверху дописать

Да я тоже так думаю. Апи прям так и знаывается mobapi😂