CacheDecorator pro WebService about skautis HOT 12 CLOSED

Podle mě tam trvalé cache uložiště mezi spojeními nepatří do této knihovny. To ať dělá každý ve svém modelu. Ta cache pro jeden běh PHP mi příjde vhodná, ale jen pro některé služby. Tím by se vyřešili i další otázky jako predávání dat pouze oprávněné osobě, klíč( např: function . $args).

Ještě mě napadlo, jestli není lepší tedka dotáhnout verzi 2.0 do stabilního stavu s popisem apod a až pak tam dodělavat další vychytávky. Zatím by se dala už prezentovat a testovat verze 2.0 a vývoj by bežel už na další verzi

from skautis.

trvalé cache uložiště mezi spojeními nepatří do této knihovny

Byl jen navrh toho co se da udelat s jiz existujicimi komponentami. Urcite staci zakladni decorator pro 1 request, dodelat cache je pak trivialni pro kohokoliv.

ale jen pro některé služby
klíč( např: function . $args)

Tech sluzeb je spousta a muselo by se neustale upravovat se zmenama tech sluzeb, navic rozhodnout co je a co uz neni cachovatelne by take bylo prijnemensim sporne. (takhle z hlavy me napada adresa strediska, zbytek tam jsou spousty osobnich informaci predevsim deti)
Jako nejbezpecnejsi, neujdrzitelnejsi a zaroven nejefektivnejsi bych videl:

• aby cache vracela data vyzaduje alespon 1 uspesny pozadavek na server Skautisu
• klic(functionName, args, sessionToken nebo userID)

jestli není lepší tedka dotáhnout verzi 2.0 do stabilního stavu s popisem apod

To dost mozna je, ale minimalne cast tohoto navrhu (WebServiceInterface) je dost velka zmena na to aby byla zahrnuta do 2.0
Pred vypustenim 2.0 je potreba mit hotove veskere zmeny v architekture. Popis, dokumentace etc. je u takovychto zmen, ackoliv stejne dulezite, az to posledni, Napr. je potreba rozhodnout jestli chceme implementovat batch requesty #29, ktere pravdepodobne budou vyzadovat nejake vetsi zmeny take.
Mam ted do skoly spoustu veci, ale az budu mit volneji tak se pustim i do dokumentace.

from skautis.

Byl jen navrh toho co se da udelat s jiz existujicimi komponentami. Urcite staci zakladni decorator pro 1 request, dodelat cache je pak trivialni pro kohokoliv.

Jako návrh to beru, proto jsem k nemu dopsal svůj pohled.

klic(functionName, args, sessionToken nebo userID)

Asi jsem to myslel tak, že by ani nebylo potreba tam resit jeden fungujici pozadavek nebo sessionToken. Myslel jsem to tak, že pokud se při načtení jedné stránky zeptám 2x na detail jednotky s ID 123, tak si to tu první odpověd uschová jen do pole například pod klic unitDetail_ID_123 a z koncem načítání stránky se vymaže i to docasne pole. To co navrhuju je cache na velmi krátkou dobu, ale může podle mě pomoc a zároveň nijak neohrozit uník dat.

verze 2.0

pokud tam mají být ještě velké změny, tak můžem počkat, jen bych nerad, aby jsme to tak dlouho vylepšovali, až to nevydali... ale to zatím nehrozí.

from skautis.

To co navrhuju je cache na velmi krátkou dobu, ale může podle mě pomoc a zároveň nijak neohrozit uník dat.

To je pravda, ale implementaci cache muze pridat kazdy sam a nemas nad ni zadnou kontrolu, proto bych, pro jistotu, pridal nejakou kontrolu do WebServiceCacheDecorator. Rad bych aby knihovna sama o sobe zajistovala urcitou uroven bezpecnosti, protoze jeji ucel je pristupovat k sluzbe jejiz obsah je spousta osobnich informaci vcetne fotek, veku, adres a telefonich cisel. Coz v kombinaci s tim ze se da predpokladat ze strediska nebudou najimat profesionalniho vyvojare muze vest ke slusnemu problemu.

from skautis.

Souhlasím s tím, že si nebudou najímat profesionála, ale to podle mě povede jen na to, že to nebudou mít cachované a většina z nich bude využívat WS na svém webu hlavně na přihlášení. Příjde ti to cachování pouze v rámci požadavku jako málo efektivní? nevím jestli tedka uplne chapu, kam míříš

from skautis.

Návrh na zavedení WebServiceInterface se mi líbí - ideální by bylo, kdyby definoval nějakou čitelnější metodu pro SOAP cally, ta magie v __call() se mi právě moc nelíbí.

Taky si myslím, že kešování na delší dobu než jeden request do této knihovny nepatří. A ani v případě kešování jen v rámci jednoho requestu si nejsem jistý, jak to rozumně implementovat - jak by se nakešované údaje invalidovaly? Co když si nejprve vyžádám ze skautISu nějakou hodnotu, pak ji dalším voláním změním a pak zas opět jiná komponenta webu bude chtít to samé číst?

from skautis.

jak by se nakešované údaje invalidovaly?

Například zavolanim metody clearCache

Já si tím cachováním v rámci požadavku, také nejsem jistý, ale pokud nějaké, tak podle mě maximálně toto.

from skautis.

@sinacek To se mi právě vůbec nelíbí - pak na jednom místě po změně dat zapomeneš zavolat clearCache() a máš zaděláno na příjemně strávený víkend debugováním chyby, která se dost těžko reprodukuje (A je klidně možné, že uběhne dlouhá doba než se vůbec poprvé projeví).

from skautis.

nevím jestli tedka uplne chapu, kam míříš

Cachovani v ramci pozadavku mi prijde pro drtivou vetsinu dostatecne efektivni i bezpecne.
To kam mirim vypada asi takto:
new WebServiceCacheDecorator(WebServiceInterface $webService, CacheInterface $cache);
CacheInterface je tam proto aby si kazdy mohl dodat jakoukoliv implementaci chce, nad tou nema knihovna kontrolu. Proto bych pro jistotu implementoval nejaky overovaci mechanismus primo do WebServiceCacheDecorator.

Návrh na zavedení WebServiceInterface se mi líbí - ideální by bylo, kdyby definoval nějakou čitelnější metodu pro SOAP cally, ta magie v __call() se mi právě moc nelíbí.

S tim naprosto souhlasim, Pekny interface by vypadal treba takto:
WsdlManager::getService($name);
Skautis::getService($name);

jak by se nakešované údaje invalidovaly?

Pocital jsem s zadnou automatickou invalidaci. Doba cachovani zalezi na implementaci cache => neni zalezitost teto knihovny.
A pro komponenty co vyzaduji aktualni data jsem v kodu v prispevku navrhl $args['skautis_cache'].

Muj cil neni aby knihovna implementovala cache nybrz mela zaklad pro to aby se dal jednoznacne implemnetovat. Treba uz kvuli Nette a Symfony balickum. => jednotny zaklad pro Decorator.

zapomeneš zavolat clearCache()

Pokud nekdo pise aplikaci ktera intenzivne meni data proste ty cache nepouzije. Proto je navrhuji pomoci decoratoru. Navic kolik % aplikaci data upravuje?

from skautis.

@xificurk to máš pravdu, že to může být matoucí. Je to problém každé cache

@JindrichPilar původně jsem myslel, že tam chceš přidávat i implementaci rovnou do knihovny, ale tedka uz jsem to pochopil a jsem klidně pro interface, který si každý naimplementuje jak bude chtít a jen pokud bude chtít

from skautis.

Ano, navrhoval jsem i nejakou zakladni implementaci tohoCacheInterface. Napriklad pomoci pole pro ten 1 request. S tim ze aby to clovek pouzil musi ten decorator rucne pouzit. Hlavne cache pro ten 1 request bude pravdepodobne ta nejvice vyuzitelna varianta a tak by si zaslouzila misto primo tady.

from skautis.

Něco základního bych sem klidně dal, ale právě složitější cache operace jsou už příliš vzdálené a bude dobré jen pro ně něchat prostor, ale neřešit je.

from skautis.