cachování na úrovni dotazování se na API

kleinpetr

Ahoj, už pár večerů přemýšlím nad tím jak je vlastně dobré cachovat. Načítám si nějaká data z REST API a potřebuji je nějak smysluplně cachovat.

Jak to mám vyřešené teď:

mám nějaký model, který se mi stará o curl requesty, v tomhle modelu mám dvě hlavní metody a těmi jsou getAll() a getOne($id) jediné co tyhle metody mají za úkol, je nastavit potřebnou path, kterou pak metoda proceedGet() zavolá v url requestu, v tomhle případě GET, nic složitého.

jednotlivé dotazy pak vypadají třeba takhle:
http://neco.cz/api/messages
http://neco.cz/api/message/{id}

Dejme tomu že každý request bych chtěl cachnout, tak jsem tenhle model rozšiřil o to, že v metodě proceedGet() se nejprve zjistí zda existuje nějaká cache jejíž KEY je PATH requestu takže např: /messages, a pokud neexistuje, tak zavolá request a uloží se do cache, pokud existuje, tak ji vytáhne z cache.

No to je všechno super, až na to, že když pak volám metodu` getOne($id)` tak se provede úplně stejná operace, co to znamená ? že sice existuje cache kde jsou uloženy všechny messages, ale neexistuje cache ktera by mela KEY právě té jedné message, tudíž se provede request a vytvoří se nová cache pouze pro jednu zprávu.

CO CHCI TEDY VĚDĚT ?
Jde mi o to, zda by nebylo lepší, třeba v metodě getOne($id) nejprve zjistit jestli náhodou neexistuje v některé z cache.. tudíž vzít si třeba tu cache která se uložila z getAll() a nějakým způosbem ji prohledat(nejspíše procyklit) zda v ní není záznam s požadovaným ID. Co si o tom myslíte ? jak byste to řešili vy ? Díky za vaše názory.

Editoval kleinpetr (2. 4. 2015 20:13)

Filip Klimeš

Předpokládám, že když dostaneš odpověď z messages, bude obsahovat i idčka. Byla by možnost jako klíč v cache použít např message-{id}, místo URL zdroje?

kleinpetr

Myslíš jako, že když hodím dotaz na messages getAll() tak si neuložím celý response do cache, ale například ho procyklim a uložim pomocí message-{id} ? to by určitě šlo, jenže né vždy jsou obsahem response záznamy, které mají ID :/

Editoval kleinpetr (2. 4. 2015 20:16)

kleinpetr

To by bylo v podstatě to samé, mě jakoby je asi jedno, že se bude cachovat postupně podle toho jak se bude na záznamy dotazovat. Jde mi spíše o to, jestli to neni ošklivé řešení (cachovat zvlášť každý záznam).

Editoval kleinpetr (2. 4. 2015 20:19)

Filip Klimeš

Přesně to jsem myslel. Procyklení samo o sobě nevidím jako velkou prasárnu, náročnost je lineární a pravděpodobně budeš odpověď cyklem procházet i na jiném místě. Jestli ale nemáš IDčka, je to problém. Ještě se zeptám, jak víš kdy invalidovat takovou cache?

kleinpetr

Nemyslím jako prasárnu procyklení, ale ukládání cache na úrovni jednoho záznamu. takže třeba 3000 záznamů = 3000 cache souborů. O to mi jde.. potom ve finále je jedno jestli těhle 3000 záznamů cachnu v cyklu v metodě getAll() a nebo se mi tam vytvoří postupně řešením jakým to mám dělané teď.

Invalidace je věc druhá, kterou jsem zatím neřešil :D a abych pravdu řekl tak nemám tušení. Až k tomu dojde, určitě zase toto téma obnovím.

Každopádně příklad s tím, že budu cachovt vše je blbost. Cachuji tímto způsobem pouze takové konfigurační údaje něco jako seznam všech států, seznam všech jazyků, seznam všech typů uživatelů, atd, atd, zkrátka opravdu taková nastavení, který se budou měnit opravdu jen zřídka a mimořádně, takže mě pak jedině napadá mít někde v adminu něco jako smazat cache a odstranit ji ručně.. nebo opravdu jsem nad tím zatím nepřemýšlel :) ale kdybys měl nějaký nápad určitě se nebudu bránit :) jinak díky za rady.

Filip Klimeš

Tak pokud budeš cachovat pouze takovéhle dotazy, myslím si, že je Tvůj přístup v pořádku. Jinak není zač :)

Taco

Invalidovat cache se hodí na akcích, které mění záznamy. Tedy, máš-li správné API, tak read, readAll ti cache vytváří, a delete, update, create ti ji promazává. Samozřejmě za předpokladu, že všechno chodí skrze toto API.