Nová strategie kešování requestů (discovery)
Jako produkťák chci prozkoumat jiné metody/možnosti kešování odpovědí našich API, protože v současném řešení (apicache-plus/redis) evidujeme problémy a nejsme si jisti optimálností tohoto řešení.
Vychází z VP OG - dlouhý běh (pid#299 - closed) a Core (OG) - nahrazení node-redis za ioredis (#39)
Akceptační kritéria
- proběhne brainstorming vývoje a devops ze kterého vznikne závěr, jakou cestou se vydáme
Implementační poznámky
- podmínky pro keš:
- data z keš lze použít až po ověření tokenu
- identifikátor keš by měl být url path + url query
- měli bychom být schopni řídit ttl keše na úrovni endpointu (k diskuzi)
- příklad užití:
- lítačka by si měla stahovat polohy vozů s různými bounding boxy, to by nemuselo hitnout keš, s tím je potřeba taky počítat
- prozatím máme tyto možnosti:
- stávající řešení ukládá vše do cache/redis nehledě na http hlavičkách
- to nám zmenšuje zátěž DB, ale evidujeme problémy s redisem
- nejsme moc schopni řídit keš pomocí hlaviček, optimalizovat dotazy. Otázkou ale je, jestli to potřebujeme
- expressjs doporučení je použít nějak cache server před aplikací https://expressjs.com/en/advanced/best-practice-performance.html#cache-request-results
- tím se nabízí použití azure front door
- nechceme se ale zamknout na technologii, takže by to chtělo prověřit i nějaké opensource řešení
- je potřeba správně nastavovat http hlavičky a otestovat, jak se to chová, když někdo pošle
cache-control: no-cache
- zkusit vymyslet nějakou jinou možnost
- např. nekešovat v redisu, ale v paměti (vykašlat se na paralelismus a zkusit zajistit něco ve smyslu session persistance)
- najít jiný knihovny pro kešování a redis
- přidat zámek/semafor na obnovu keše
- a další...
- stávající řešení ukládá vše do cache/redis nehledě na http hlavičkách
- akceptuje @benaktom
Edited by Tomáš Benák