Как избавиться от зависимых запросов. Помогите с архитектурой

[Silentland]

Одностраничное приложение.
Обрабатываем переход по адресу: site.ru/spb/museums/best

1. Получаем объект города api.site.ru?city=spb, берем из него cityId: 123
2. Получаем объект категории api.site.ru?categories=museums, берем из него categoriesId: 456
3. Получаем список лучших музеев Питера api.site.ru/museums?city=123&categories=456&type=best

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

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

Можно хранить урезанные списки соответствий url — id, что отсрочит первую проблему, но усложнит бэкенд и фронтенд.

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

Можно переделать бэкенд, чтобы он понимал запросы вида api.site.ru/museums?city=spb&categories=museums&type=best, но тогда придется постоянно делать запросы по нескольким таблицам и возрастет нагрузка на сервер, чего очень не хочется.

Какие еще есть варианты? Как бы вы сделали? Как сделать правильно?

 

[hell0w0rd]

Можно переделать бэкенд, чтобы он понимал запросы вида api.site.ru/museums?city=spb&categories=museums&type=best, но тогда придется постоянно делать запросы по нескольким таблицам и возрастет нагрузка на сервер, чего очень не хочется.

По твоему обработать 3 запроса, вместо одного - увеличение нагрузки?)

 

[Absinthe]

По твоему обработать 3 запроса, вместо одного - увеличение нагрузки?)

В случае простых действий на тормозных фреймворках типа symfony - практически в 3 раза увеличение.

 

[ksnk]

А если использовать в "финальном" запросе не ID категорий и городов, а их имена? Немного усложнится запрос, появится лишняя пара join'ов. Тестирование покажет стоит оно того или нет.

 

[Silentland]

По твоему обработать 3 запроса, вместо одного - увеличение нагрузки?)

Даже если в 2 раза, даже если в 1,5. Эта задержка будет практически у всех операций, т.к. они все зависимы, и даже тогда, когда клиент уже располагает всеми необходимыми данными. Как работает технология ЧПУ? Тоже с лишними запросами к БД или для нее придумано красивое решение?

 

[riff]

Создать индекс-таблицу путей. (?)
city | cat | type | path
123 | 456 | best | spb/museums/best

 

[hell0w0rd]

Absinthe, в 4 час утра оговорился) имел ввиду что обработать одним запросом то, что сейчас обрабатывается тремя по мнению ТС - увеличение нагрузки?
Кстати в случае с симфони можно сделать просто саб-реквесты.

 

[Silentland]

А что если использовать строку url в качестве айдишника. Это решит все проблемы кроме одной, когда понадобиться переименовать этот айдишник. Можно ли потом пройтись по всему коду, всем БД и заменить всё. Существуют инструменты для этого или это фантастика?

И как вы это делали? По-любому, у каждого была такая задача, получить из пути айдишник.

 

[hell0w0rd]

По мне так запрос должен выглядить так:
GET api.site.ru/museums/spb/museums?type=best
По моему ТС хочет соблюсти какую-то абстрактную абстракцию, которая тут не нужна

 

[Dez]

ЧПУ не простая тема.
Сначала нужно определиться с понятием что у вас страница.

Вот кстати интересный момент. Вот такой адрес страницы у него:

museums?city=123&categories=456&type=best

В друпале вот такого типа роутинг

?q=node/1

аргумент будет вытащен самим движком и передан в контроллер. И все, сразу никаких проблем.

Кто знает в других фреймворках как роутинг работает? Есть так как в друпале?

 

[hell0w0rd]

Dez, при чем тут ЧПУ?

 

[grigori]

hell0w0rd, ЧПУ его волнует

 

[grigori]

>Какие еще есть варианты?
их довольно много, включая web sockets, подгрузку значений в виде JS и кеширование его на клиенте, а так же "забить и не париться", и другие

>Как бы вы сделали?
я бы проанализировал бизнес-логику, бюджет разработки и эффект от изменений

>Как сделать правильно?
нет никаких правил, как и ложки

 

[Dez]

Dez, при чем тут ЧПУ?

Как причем? А что он в пунктах 1 и 2 делает?
Можно ведь сразу в базе хранить соответствие внутреннего и внешнего пути:

spb/museums/best  |  museums?city=123&categories=456&type=best

и никаких шагов 1,2.

 

[ksnk]

Dez, кстати, да. Правда чем этот вариант (+1 запрос) принципиально лучше первоначального (+2), надо еще подумать.
Ну и без фанатизма. Например этот форум в базу было бы неразумно сливать. А вот ограниченное количество сопроводительных статей форума с фиксированными ссылками - довольно разумно. И у ЧПУ сразу такая гибкость образовалась

 

[Dez]

Дело в том что с помощью ЧПУ сеошник может конструировать свою "логическую" структуру сайта.
И полный контроль над ЧПУ желательно ему предоставить.
Это понятно что для сайтов которые без постоянной поддержки от программиста.
Просто возникает второй вопрос - не только разбора входящего запроса, но и нахождения внешних ссылок по внутренним. Потому что в таких ручных вариантах как у ТС, эти вещи в общем случае не решаются.

 

[hell0w0rd]

Dez, ЧПУ - человеко-понятный урл, каким образом использоваие АПИ на клиенте относится к ЧПУ?
Мне кажется то что ты хочешь сказать - называется роуты и их давно пишут вот так:
/spb/{type}/{city}/{categories}

 

[ksnk]

hell0w0rd, насколько я понял, мысль Dez - нужно иметь соответствие адресной сроки, произвольной задаваемой сеошником формы, структурированому API-шному адресу. Чтобы не разрешать spb в индекс города и museums в категорию отдельным запросом. То есть роуты, как класс, вообще говоря, не нужны. Ну разве что в качестве оптимизации при большом количестве однотипных страниц, до которых шаловливые ручки сеошников еще не добрались.

 

[hell0w0rd]

Какие нахрен сеошники?? Мы тут доступ к АПИ обсуждаем

 

[Dez]

Какие нахрен сеошники?? Мы тут доступ к АПИ обсуждаем

Читаем внимательно первое сообщение:

Обрабатываем переход по адресу: site.ru/spb/museums/best

Откуда то же этот путь пришел?
То что он аяксом три раза один за другим будет слать запросы чтобы вытянуть нужный контент не считаю оптимальным.
Какая разница запрашивалась бы эта информация сразу через пхп или аяксом на АПИ. Цель то одна - получить данные.