Nahrazení Databáze čtením dat z REST API

To je hodně široká otázka a asi se nikdo neodváží navrhnout řešení bez znalosti bližšího kontextu. Chceš nahradit docela rychlý spolehlivý resource (db) za dost možná pomalý a asi méně spolehlivý (REST API)? Většinou se dělá naopak replikace z API do db, abys měl data operativně po ruce. Už jen proto, že u vyhledávání můžeš využít indexy. U rest api budeš muset stáhnout vše a sekvenčně projít. Dost to hrozí slow downem systému, ale věštím z koule…

Pak bych nevynalézal kolo a nasadil elasticsearch.

Naopak to je dneska běžná věc, že se udělá aplikace, která zpřístupňuje data přes REST API, jelikož se s tím pak jednotně pracuje ve všech dalších systémech, jako třeba v Android appce, která se napřímo na SQL databázi napojit neumí. Líp se dělají pak pomocí API decentralizované databáze atd. atd.

Elastic se zase používá pro fulltext vyhledávání pro co byl navržen, takže to je komplet mimo mísu.

V rámci API a databáze vzniká jediný problém a to pomalejší čtení z API a to proto, že když se komunikuje s databází napřímo, tak tam není ten mezičlánek API, které řídí nějaká appka. Otázka je, jakým způsobem to API uchovává data. Pokud jde třeba o to, že API vnitřně data ukládá do RAMky, tak ta rychlost je v určitých případech s klasickými databázemi srovnatelná, ne-li někdy rychlejší, jelikož si algoritmus manipulace s daty navrhneš konkrétně na určitou operaci.

Otázka se tedy celá točí kolem implementace toho té aplikace, která má zprostředkovávat to API.

No a i kdyby to bylo pomalejší, tak je to ve výsledku úplně jedno, jelikož se běžně v aplikacích všechny dotazy do databází cachujou, takže jeden dotaz po expiraci cache je prd.

No a pokud chceš aby tě někdo nakopl informací jak v něčem dál, tak je potřeba specifikovat, co přesně potřebuješ udělat.
Máš za úkol vytvořit tu aplikaci, co bude nabízet to API, nebo to API dostaneš a máš jen na něj napojit aktuální aplikaci? Nebo máš v aplikaci udělat to, že máš překopírovat aktuální data z Postgresu do toho API?
Zkus přesně popsat problém a dostaneš přesnou odpověď :)

Polki napsal(a):

Naopak to je dneska běžná věc, že se udělá aplikace, která zpřístupňuje data přes REST API, jelikož se s tím pak jednotně pracuje ve všech dalších systémech, jako třeba v Android appce, která se napřímo na SQL databázi napojit neumí. Líp se dělají pak pomocí API decentralizované databáze atd. atd.

Elastic se zase používá pro fulltext vyhledávání pro co byl navržen, takže to je komplet mimo mísu.

V rámci API a databáze vzniká jediný problém a to pomalejší čtení z API a to proto, že když se komunikuje s databází napřímo, tak tam není ten mezičlánek API, které řídí nějaká appka. Otázka je, jakým způsobem to API uchovává data. Pokud jde třeba o to, že API vnitřně data ukládá do RAMky, tak ta rychlost je v určitých případech s klasickými databázemi srovnatelná, ne-li někdy rychlejší, jelikož si algoritmus manipulace s daty navrhneš konkrétně na určitou operaci.

Otázka se tedy celá točí kolem implementace toho té aplikace, která má zprostředkovávat to API.

No a i kdyby to bylo pomalejší, tak je to ve výsledku úplně jedno, jelikož se běžně v aplikacích všechny dotazy do databází cachujou, takže jeden dotaz po expiraci cache je prd.

No a pokud chceš aby tě někdo nakopl informací jak v něčem dál, tak je potřeba specifikovat, co přesně potřebuješ udělat.
Máš za úkol vytvořit tu aplikaci, co bude nabízet to API, nebo to API dostaneš a máš jen na něj napojit aktuální aplikaci? Nebo máš v aplikaci udělat to, že máš překopírovat aktuální data z Postgresu do toho API?
Zkus přesně popsat problém a dostaneš přesnou odpověď :)

Je to tak, že můžu ovlivnit to API ve stylu, řeknu kolegovi jaká data budu potřebovat.
Můj úkol je původně DB aplikaci upravit tak aby místo té DB používala to API.
Tzn. původní DB nahradit tím API. Rychlost asi není tak podstatná nejedná se tam primárně o velké množství dat. Jsou to spíš jednotky položek, REST API tam už funguje, ale jak jsem psal mám možnost ovlivnit co dostanu zpět, potažmo na jaký dotaz dostanu jaká data.

grovik napsal(a):

Je to tak, že můžu ovlivnit to API ve stylu, řeknu kolegovi jaká data budu potřebovat.
Můj úkol je původně DB aplikaci upravit tak aby místo té DB používala to API.
Tzn. původní DB nahradit tím API. Rychlost asi není tak podstatná nejedná se tam primárně o velké množství dat. Jsou to spíš jednotky položek, REST API tam už funguje, ale jak jsem psal mám možnost ovlivnit co dostanu zpět, potažmo na jaký dotaz dostanu jaká data.

No tak to by pak nemělo být těžké. Záleží, jak je ta původní ‚DB aplikace‘ navržená, ale pokud má odstíněnou DB vrstvu nějakým šikovným adapterem/fasádou/proxy v modelu (což jsem tu na fóru zmiňoval několikrát a vždy mě lidi zlinčovali :D ), tak by neměl být problém a jen vyměníš ty třídy, co se připojovaly k Postgresu za třídy, které se budou nově připojovat k REST API a zbytek aplikace zůstane nezměněný.

Pokud to tak nemáš, doporučuju si nejdřív veškerou práci s databází vyextrahovat do zvláštní sekce v aplikaci (Většinou tzv. Repozitáře) která ty data zpřístupní, takže aplikace se bude například na data o uživateli ptát třídy UserRepository a jestli ty data ta třída UserRepository vezme z Postgresu, nebo z nějakého API je zbytku aplikace úplně jedno.

Příklad by mohl být nějak takto:

Původní třída:

class ArticleRepository
{
	public function search(string $searchText): array
	{
		return $this->database->table('article')
			->where('content LIKE ?', '%' . $searchText . '%')
			->fetchAll(); // Případně konverze na nějaké třídy
	}
}

Nová třída

class ArticleRepository
{
	public function search(string $searchText): array
	{
		return $this->makeCurlRequest(
			url: '/articles',
			method: 'GET',
			data: [
				'content' => $searchText,
			],
		);	// Případně konverze na nějaké třídy
	}
}

A všude v aplikaci budeš mít jednoduše volání $articles = $this->articleRepository->search($searchText);

Právě kvůli těmto případům, že se může stát, což se dneska stává častěji, než si člověk může myslet, že se změní databáze, by se takto měly aplikace psát a to tak, že volání jakékoliv jiné služby/využívání knihovny, kterou si nepíšu sám by mělo být podmíněno nějakým adapterem/proxy atp., aby práce s tou danou třídou/knihovnou/microservicou byla od aplikace odstíněná a dalo se to jednoduše kdykoliv nahradit za jinou.

Fíjo. Tak to je mazec.
Když dostanu zakázku, kterou dělal nějaký nováček, nezkušený, nebo se na tom vystřídalo více lidí a každý si to dělal po svém, tak už postupuji jen tak, že doporučím komplet přepis a pokud zákazník nesouhlasí, tak to šupnu nějakému žákovi/méně zkušenému kolegovi, aby se na tom naučil aspoň.

Chápu ale, že se takto jednoduše nejde zbavit problému vždy :D

No já doporučuji jak jsem psal extrakci práce s databází do samostatných tříd, díky čemuž pak napojení na API bude hračka.
Možná ještě někdo něco poradí a když ne, tak přeji hodně pevné nervy a trpělivosti :)

Však když bude potřeba, tak se ptej komunita je vstřícná a poradí. :)

Tak jo vrtám se v tom celý den a mám tu jeden příklad za všechny :-).
Původní metoda:

public function getLocalities()
	{
        if (!isset($this->localities)) {
            $sql = "
                SELECT DISTINCT o.id, o.obec
                FROM modemy AS v
                JOIN obec AS o ON o.obec=v.obec
                ORDER BY o.obec
            ";
            $this->localities = $this->db->query($sql)->fetchPairs('id', 'obec');
        }
        return $this->localities;
	}

REST API má v podstatě dovede vrátit to stejné:

curl -X 'GET' \
  '/api/v1/admin/locality' \
  -H 'accept: application/json' \
  -H 'Authorization: Basic YWRtaW46eGVQOHphaDk='

Teď otázka zní, jak nejlépe ten vrácen JSON, Příklad níže, dostat do stejné podoby a tu vrátit.

JSON příklad:

[
  {
    "localitytId": 1,
    "cfgCode": "velka_bites",
    "name": "Velká Bíteš",
    "cmtsConfigurationId": null,
    "created": "2021-10-02T09:50:21.212453+02:00"
  },
  {
    "localitytId": 2,
    "cfgCode": "hustopece",
    "name": "Hustopeče",
    "cmtsConfigurationId": 6,
    "created": "2021-10-02T09:50:21.212453+02:00"
  }
]

Editoval grovik (1. 12. 2021 15:51)

>

Nebo tak :)

PS: Promiň, že ti odpovídám až teď :D Spal jsem po 37 hodinách práce :D

@Polki Proboha jen se neomlouvej, to já jsem vděčný za kopnutí správným směrem!!
Vypadá to velice elegantně to by mohlo dobře fungovat, ono tam bude víc takových míst tady se jedná o takové malé nasazení.
Jinak těch dat je v tomhle případě celkem dost, ale není to krytické. Tu funkcionalitu použe někdo jednou za hodinu a je celkem fuk jestli bude čekat 10 vteřin nebo 15. Takže tady asi i pro mě logickou optimalizaci neprotlačím (není to tak podstatné).

Ještě jednou díky. Zkusím sem pak dát nějak použitý výsledek aby to tu mělo finální řešení :-). Protože to je myslím moc důležití.
Díky!

Json::decode() určitě ve výchozím stavu nic na žádný výstup nesype.

Toto dekódování jsonu dělá věci úplně stejně jako JavaScript, tedy to, co je v [] závorkách vezme jako pole a to, co je v {} závorkách vezme jako objekt a tedy jako stdClass. Alternativně můžeš vynutit, aby vše bylo pole/asociativní pole a to druhým parametrem Json::FORCE_ARRAY.

Takže ten JSON, který jsi ty poslal v příkladu se díky Json::decode() přeloží do tohoto:

array
	0 => stdClass
		localitytId: 1
		cfgCode: 'velka_bites'
		name: 'Velká Bíteš'
		cmtsConfigurationId: null
		created: '2021-10-02T09:50:21.212453+02:00'
	1 => stdClass
		localitytId: 2
		cfgCode: 'hustopece'
		name: 'Hustopeče'
		cmtsConfigurationId: 6
		created: '2021-10-02T09:50:21.212453+02:00'

což je iterovatelný a ten můj úryvek kódu bude fungovat.

Takže chyba bude nejspíš někde jinde.

Tak jsem to nakonec prokopl.
Problém byl v tom že CURL do $response zapsal výsledek a data se vypsaly přímo do HTML.
Pomohlo doplnit parametr:

curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE);