T
T
tamtakoe2013-12-08 12:22:47
PHP
tamtakoe, 2013-12-08 12:22:47

How to get rid of dependent queries?

Single page application.
We process the transition to the address: site.ru/spb/museums/best
1. Get the city object api.site.ru?city=spb, take cityId: 123 from it
2. Get the category object api.site.ru?categories=museums, take categoriesId: 456 from it
3. Get a list of the best museums in St. Petersburg api.site.ru/museums?city=123&categories=456&type=best
As a result, we have a couple of transit requests that complicate the frontend code and slow down the response.
On the one hand, you can get a list of all cities, categories, etc., immediately upon loading, but if the lists are large, this may slow down the first load.
You can store truncated lists of url - id matches, which will delay the first problem, but complicate the backend and frontend.
You can come up with something on the frontend that will load lists of cities and categories in the background and defer the execution of tasks that require data from them if they have not yet been loaded. This will greatly complicate the frontend.
You can remake the backend so that it understands queries like api.site.ru/museums?city=spb&categories=museums&type=best, but then you will have to constantly make queries on several tables and the load on the server will increase, which you really don’t want.
What other options are there? How to do it right? How such problems are solved in fullstack frameworks

Answer the question

In order to leave comments, you need to log in

5 answer(s)
M
Masterme, 2013-12-08
@Masterme

modify api so that it understands requests like
api.site.ru/museums?city=spb&categories=museums&type=best

A
Andrey Bezpalov, 2013-12-08
@Andrbez

api.site.ru?city=123&categories=456

D
Damir Makhmutov, 2013-12-08
@doodoo

If the data rarely changes, then pull everything with one request and cache it.

_
_ _, 2013-12-08
@AMar4enko

You have already been correctly told that you need to make a separate API method for this situation. In essence, this is a REST method for getting a collection with a filter.
Your city and category will act as a filter.
For the city and category, you store alias and id, alias flies to you from the front.
You check to see if you have cached id's for the passed city and category aliases. If not, then build a large query with joins that filters by aliases. As a result of execution, in addition to information on museums, you will receive the city id and categories that you put in the cache. Subsequent requests will take the id from the cache and the request will be to one table without joins with a filter for specific ids.

W
Walt Disney, 2013-12-22
@ruFelix

@tamtakoe @Masterme told you everything correctly, if the joins do not fit ideologically, make three simple selects in a row, no one forces you to make one request. And the base caches them perfectly, which most likely will not happen with the joins.
And it would be even better if you expand the initial dataset of the client, so that he could immediately do api.site.ru/museums?city=123&categories=456&type=best

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question