API a šetření přenosu odkazem na objekt

[Zopper]

Tohle se dělá buď u manuálně konstruovaných dat typu popis API, jako třeba Swagger (několik endpointů vrací nějaký objekt nebo kolekci objektů, tak se ten objekt nadefinuje jednou a pak se nemůže stát, že někdo zapomene upravit jeden endpoint z několika, když se něco změní). Nebo pokud se běžně vrací tisíce (či větší řády) položek, které by všechny něco sdílely, a tedy to rozdělení má měřitelný přínos. Tohle jsem to viděl třeba u meteorologických dat, kdy to API vrátí klidně statisíce či miliony záznamů pro každou měřící stanici, a data o těch stanicích jsou popsaná v samostatné části odpovědi, tak jak to chcete udělat s autorem. Ale to se bavíme o odpovědi, která má klidně několik MB na jeden dotaz, tam se už takovéhle optimalizace projeví (pokud to nezvládne kompresní algoritmus).

[Reklama]

[RDa]

Rozmyslam ake to ma negativa to takto riesit, ale zatial som nansiel nic dolezite, tak ze aky je konsenzus?

Ja bych do te normalizovane formy sel zejmena z duvodu optimalnosti vyuziti parseru - proc parsovat milionkrat ty same struktury.. to vidim jak dnesni programatori nemaji tuseni o narocnosti nekterych ukonu.

Par postrehu - muzes se podivat jak se serializuji objekty napr. v PHP - reference neni pouhe cislo, ale nese sebou i tridu. Na druhe strane spektra pak existuje zpusob, kdy vite ze treba nemate zaporne cisla v datech, takze vse minus-neco je reference, a pak existuje sdileny object-pool ktery se indexuje absolutni hodnotou toho cisla (tohle jsem videl v nekterych datovych formatech).

Doporucuji vymyslet zpusob, ktery bude transparentni - tj. na strane serveru se puvodni struktura zkomprimuje na tu rozlozenou, a na strane klienta se z te rozlozene struktury posklada puvodne minena forma. Zde pak nastava otazka, zda nekdo takove knihovny/framework na prenos dat uz nenapsal.

Tj. abys ten lookup opravdu nedelal na aplikacni vrstve / kodu (zadna indexace neceho necim - reference musi byt transparentni), a taky abys neresil odkud vybrat objekt na ktery se referencuje (datove domeny / tridy musi byt transparentni).

U toho kodu, co to sesklada na strane klienta je v pripade nasazeni tohoto transportu potreba jen obslouzit vyjimky, kdy jsou data nekonzistentni (tj. neexistuji data objektu na ktery odkazuje reference), coz pri onload seskladani lze zjistit a pak se proste neprovede zadny aplikacni kod, nez aby ten kod byl pusten na vadnych datech.

[Tomas-T]

Neznám aplikaci autora jako celek, ale v mé vlastní situaci, o které jsem se výše zmínil, byla pro mě hlavním impulsem pro implementaci tohohle řešení potřeba mít na klientovi k dispozici kompletní seznam položek (zde seznam channels).
A když už ho tam mám, je zbytečné tytéž údaje ještě přidávat duplicitně do ostatních objektů, tam stačí reference přes ID (vůbec na serveru nemusím dělat ten výše zmíněný join, protože vím, že na klientovi budu mít k dispozici všechny položky).
Je to samozřejmě také otázka velikosti seznamu položek, když jsou a budou jich desítky, je to OK, když jich budou desítky tisíc, není to dobré řešení.

[Zopper]

Ja bych do te normalizovane formy sel zejmena z duvodu optimalnosti vyuziti parseru - proc parsovat milionkrat ty same struktury.. to vidim jak dnesni programatori nemaji tuseni o narocnosti nekterych ukonu.

Nebo to ví velmi dobře, ale nezajímá je to, protože jejich čas na vývoj je mnohem omezenější zdroj a mají na práci důležitější věci, než takovouhle předběžnou optimalizaci. A když se pak ukáže, že se tady dají ušetřit peníze přepsáním, tak to přepíšou. A nebo taky ne, když se za stejné množství času a práce půjde někde vedle dát něco zoptimalizovat ještě víc.

Dovolím si tu odkázat na legendární Programming sucks, konkrétně pak kapitolu All code is bad.

[RDa]

Ja bych do te normalizovane formy sel zejmena z duvodu optimalnosti vyuziti parseru - proc parsovat milionkrat ty same struktury.. to vidim jak dnesni programatori nemaji tuseni o narocnosti nekterych ukonu.

Nebo to ví velmi dobře, ale nezajímá je to, protože jejich čas na vývoj je mnohem omezenější zdroj a mají na práci důležitější věci, než takovouhle předběžnou optimalizaci. A když se pak ukáže, že se tady dají ušetřit peníze přepsáním, tak to přepíšou. A nebo taky ne, když se za stejné množství času a práce půjde někde vedle dát něco zoptimalizovat ještě víc.

Dovolím si tu odkázat na legendární Programming sucks, konkrétně pak kapitolu All code is bad.

Nemuzete srovnavat opici v korporatu, na ktereho tlaci cas, zdroje, sef a nenaplnene pudy.

Tazatel resi SVUJ projekt, takze ma zajem na tom to udelat technicky lepe za vlivu zcela jinych omezujich podminek.

Neznam pojem predbezna optimalizace - ale za to lenivost na nas huci ze vsech stran (vnaseni naroku na zdroje, kterym by slo predejit, vnaseni omezujicich podminek, protoze to neudelame univerzalne, ale na miru - ehm, bare minimum!, atd)

[Reklama]

[Zopper]

I soukromý čas je omezený zdroj. Je velmi snadné zaseknout se párkrát na nějakém detailu. A pak zjistit, že už to člověk dělá dva měsíce a přestává ho to bavit, žena chce, aby se začal zas věnovat dětem, a tak ten zbytek splácá nějak dohromady. A výsledek je horší, než kdyby ty detaily prostě nějak zbastlil, ale měl víc času na ten zbytek.

Samozřejmě, můžeme se bavit, jestli to je špatně, nebo dobře, a jestli cílem je udělat funkční věc, nebo si jen tak programovat, a praktický výsledek bude vedlejší. Ale to si už musí tazatel přebrat sám. Stejně jako nevíme, o jaké objemy dat se bude jednat, jak často se to bude provádět, jestli to poběží na nějakém flákajícím se notebooku, cloudové virtuálce placené od času s předřazeným cachováním, nebo ESP32, co sotva stíhá chrlit data, natož nad tím ještě něco komprimovat.

[Filip Jirsák]

Neznam pojem predbezna optimalizace

Jako začátečník nemůžete znát všechno. Ale zrovna tohle je důležitá věc, kterou byste se měl naučit brzo.

Možná vás mate to slovo „předčasná“ (premature). Problémem předčasné optimalizace není to, že by program fungoval uspokojivě i bez ní, jak si asi myslíte. Podstatnou předčasné optimalizace je to, že se nedělá na základě zjištění toho, co a jak je potřeba optimalizovat, ale na základě ničím nepodložených pocitů – takže v lepším případě se věnuje energie na změnu, která nepřinese žádný efekt, v horším případě je ten efekt negativní.

Je to právě lenost zjistit, co má doopravdy smysl optimalizovat.

ale za to lenivost na nas huci ze vsech stran (vnaseni naroku na zdroje, kterym by slo predejit, vnaseni omezujicich podminek, protoze to neudelame univerzalne, ale na miru - ehm, bare minimum!, atd)

Čas programátorů je rozhodně řádově vzácnější zdroj, než zdroje (CPU, RAM) potřebné pro rozparsování 50 záznamů, o kterých byla řeč. Navíc v tom vašem příkladu s ušetřením práce parseru jste neuvažoval všechny ostatní věci, které to ovlivní. Přiděláte práci serveru, přiděláte práci klientovi, když bude muset dohledávat hodnoty v hashmapě. Vymyslel jste si jednu věc, kde možná zdroje ušetříte, ale v úplně ignorujete všechny ostatní dopady na zdroje, které ta změna způsobí. Navíc vaše řešení je méně univerzální a vnáší omezující podmínky, tedy přesně to, co kritizujete.

[RDa]

Neznam pojem predbezna optimalizace

Jako začátečník nemůžete znát všechno. Ale zrovna tohle je důležitá věc, kterou byste se měl naučit brzo.

Možná vás mate to slovo „předčasná“ (premature). Problémem předčasné optimalizace není to, že by program fungoval uspokojivě i bez ní, jak si asi myslíte. Podstatnou předčasné optimalizace je to, že se nedělá na základě zjištění toho, co a jak je potřeba optimalizovat, ale na základě ničím nepodložených pocitů – takže v lepším případě se věnuje energie na změnu, která nepřinese žádný efekt, v horším případě je ten efekt negativní.

Je to právě lenost zjistit, co má doopravdy smysl optimalizovat.

Pokud se bavime o optimalizaci, tak je efekt vzdy pozitivni.
Ale chapu, ze Vy, jakozo neprogramator, jste schopen uspesne optimalizace i s negativnim efektem. Gratuluji.

[Filip Jirsák]

Pokud se bavime o optimalizaci, tak je efekt vzdy pozitivni.
Ale chapu, ze Vy, jakozo neprogramator, jste schopen uspesne optimalizace i s negativnim efektem. Gratuluji.

A to vám není trapné, že podle vás „neprogramátor“ rozumí optimalizacím programu podstatně víc, než vy?

Za prvé, všem je jasné, že se celou dobu bavíme o „pokusu o optimalizaci“ nebo „snaze o optimalizaci“. Zda to má opravdu pozitivní efekt zjistíte až měřením.

Za druhé, optimalizovat je možné různými způsoby a to, co bude mít v jednom směru pozitivní efekt, bude mít často v jiném směru efekt negativní. Klasický příklad je výpočetní výkon × spotřeba paměti. Mnoho algoritmů můžete zrychlit za cenu vyšší paměťové náročnosti, nebo naopak snížit jejich spotřebu paměti za cenu větší výpočetní náročnosti. Klasickým příkladem je jakákoli (rozumně implementovaná) cache.

Stejně tak je to i v tomto případě. Kde chcete mít pozitivní efekt? Na době mezi přijetím požadavku a odesláním odpovědi ze serveru? Na množství přenesených dat mezi aplikačním serverem a klientem? Na době mezi odesláním požadavku a zobrazením dat na klientovi? Na množství přenesených dat mezi DB a aplikačním serverem? Na bezchybnosti kódu (i v okrajových případech)? Na rychlosti dodání změn v programu? Na to všechno (a mnoho dalšího) se dá kód optimalizovat. Což byste měl vědět, když se pořád snažíte tvářit, jaký jste expert na programování.

[RDa]

Pokud se bavime o optimalizaci, tak je efekt vzdy pozitivni.
Ale chapu, ze Vy, jakozo neprogramator, jste schopen uspesne optimalizace i s negativnim efektem. Gratuluji.

A to vám není trapné, že podle vás „neprogramátor“ rozumí optimalizacím programu podstatně víc, než vy?

Kdyby to rekla respektovana autorita, budiz. Ale trvrdite to jen sam o sobe, takze jste duveryhodny jako self-signed certifikat od scammera.

Stejně tak je to i v tomto případě. Kde chcete mít pozitivní efekt? Na době mezi přijetím požadavku a odesláním odpovědi ze serveru? Na množství přenesených dat mezi aplikačním serverem a klientem? Na době mezi odesláním požadavku a zobrazením dat na klientovi? Na množství přenesených dat mezi DB a aplikačním serverem? Na bezchybnosti kódu (i v okrajových případech)? Na rychlosti dodání změn v programu? Na to všechno (a mnoho dalšího) se dá kód optimalizovat. Což byste měl vědět, když se pořád snažíte tvářit, jaký jste expert na programování.

A vy jste si ani neprecetl alespon nazev vlakna do ktereho prispivate opakovane tunou nesmyslneho textu?

API a setrenie prenosu linkovanim na objekty namiesto embedovania

Prosim. Zadani je jasny - setrit se ma traffic, protoze to je typicky extra zpoplatnena vec a ma to zrejme vliv na provozni naklady sluzby. Neni treba nad tim filozofovat a vest meta-diskuze.

K technickemu reseni dotazu nebo problemu jste zde neprispel nicim. Je videt ze se vam osobne do toho nechce, protoze nejste schopen vytvorit tuhle vec a budete si vymyslet milion veci proc to nejde, proc by to nebylo potreba, proc to bude spatny. Takove lidi velice dobre znam a jsou totalne k nicemu. Jen tlachaji na netu nebo v hospode a niceho nedosahli.

Protoze delam zrejme ponekud vetsi a slozitejsi veci nez vy nebo tazatel, tak vidim prinos (resp. jako jedine reseni onu normalizovanou formu) z duvodu, ze ty slozite datove objekty maji vazby ve forme grafu a delat ruzne reprezentace na BE vs FE by bylo nesmyslne. Takze transport MUSI ty reference podporovat rovnou.

Pro @petersveter - zagoogli kolem "circular json", najdes par realnych zpusobu reseni referenci i hotove knihovny.

[Filip Jirsák]

A vy jste si ani neprecetl alespon nazev vlakna do ktereho prispivate opakovane tunou nesmyslneho textu?

Přečetl.

Prosim. Zadani je jasny - setrit se ma traffic, protoze to je typicky extra zpoplatnena vec a ma to zrejme vliv na provozni naklady sluzby. Neni treba nad tim filozofovat a vest meta-diskuze.

To je vaše ničím nepodložená domněnka. Třeba petersveter myslel rychlost přenosu, ne objem přenesených dat. To by také dávalo smysl, protože uživatelé preferují rychlejší aplikaci.

Objem dat se nejrychleji zmenší zapnutím komprese přenášených dat. A to vaše řešení může v některých případech objem dat po kompresi zvětšit.

K technickemu reseni dotazu nebo problemu jste zde neprispel nicim.

Přispěl jsem tím, že takhle od stolu vypadá jako nejlepší řešení zapnout kompresi na transportní vrstvě a na strukturu dat nesahat. Pokud chce petersveter opravdu něco optimalizovat, nezbyde mu nic jiného, než měřit a porovnávat výsledky měření.

Je videt ze se vam osobne do toho nechce, protoze nejste schopen vytvorit tuhle vec a budete si vymyslet milion veci proc to nejde, proc by to nebylo potreba, proc to bude spatny.

Já už jsem tazateli poradil nejlepší možné řešení – pokud chce něco vylepšovat dál nad rámec toho doporučení, bude muset měřit jeho konkrétní případy použití, to už za něj neudělám. Teď už jenom vyvracím vaše bludy, protože se tváříte, jak tomu rozumíte, přitom neznáte základní pojmy, netušíte, co vlastně je podstatou optimalizace. Jenom jste navrhl, jak současný jednoduchý návrh zkomplikovat jakousi vrstvou abstrakce, přitom vůbec nevíte, jaký dopad to bude mít na to, co chce řešit tazatel. Evidentně vás ani nenapadlo, že to vaše řešení by mohlo mít i na ten objem přenášených dat negativní dopad, tedy že by se objem přenášených dat zvýšil.

Protoze delam zrejme ponekud vetsi a slozitejsi veci nez vy

Zmiňoval jste tu PHP. Tak se pochlubte, který telekomunikační operátor, mezinárodní finanční instituce nebo vláda řeší velké a složité věci v PHP.

ty slozite datove objekty

Já seznam článků s jejich autory nepovažuji za složitý datový objekt.

[oss]

Myslim, ze sa tostandardne robi cez $ref a $id, ale otazne je kolko parserov to zvladne.

[Filip Jirsák]

Myslim, ze sa tostandardne robi cez $ref a $id, ale otazne je kolko parserov to zvladne.

Ano, podobně to používá třeba OpenAPI – v $ref je cesta k objektu, který se má použít. Tj. ten identifikátor není jednoduché ID, ale celá cesta – tudíž je to univerzálnější a v jedné struktuře mohou být odkazované různé typy objektů. Obávám se ale, že v případě, který byl uveden tazatelem, by to ID mohlo být podobně dlouhé, jako samotná data – takže úspora dat by tam nemusela být žádná.

Tenhle princip se hodí v případě, kdy potřebujete zrekonstruovat na cílové straně tu strukturu objektů – třeba jak psal Tomas-T, že se třeba seznam autorů zároveň použil pro naplnění nějakého číselníku.

[oss]

Ten identifikator moze byt akekolvek unikatny string vramci jsonu. Len OpenAPI si zvolilo velmi ukecany format.