Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: petersveter 25. 02. 2024, 00:07:38
-
Povedzme ze mam API ktore vracia zoznam clankov. Kazdy clanok ma nazov, obsah, kategorie, autora... a povedzme ze napriklad autor je objekt ktory obsahuje viacero udajov, mimo ID, ako je napriklad meno, url profilu, odkaz na avatar...
Bezne je kazdy clanok vo vratenom zozname samostatny objekt s plne vyplnenymi entitami. Co ak by som ale vratil odpoved tak, ze linkovane objekty by boli vedla vrateneho zoznamu a samotne embedovane objekty by boli len ID ako odkazy na konkretny objekt?
Cize namiesto:
{
"articles": {
123: {
"title": "foo",
"body": "bar",
"created_at": 1223456,
"created_by": {
"id": 45678,
"name": "Some User",
"avatar": "http://www.foobar.com/avatar.jpg"
}
}
}
}
by odpoved bola:
{
"articles": {
123: {
"title": "foo",
"body": "bar",
"created_at": 1223456,
"created_by": 963
}
},
"authors": {
963: {
"id": 45678,
"name": "Some User",
"avatar": "http://www.foobar.com/avatar.jpg"
}
}
}
A teda klient by si to musel vyskladat sam. Rozmyslam nad tym uz nejaku chvilu lebo mi pride celkom zbytocne robit vypisy objektov kde vratim 50 hlavnych zaznamov a 50x je tam rovnaky uzivatel, co je 49x viac informacii o uzivateloch nez je realne treba poslat. A samozrejme su tam aj dalsie objekty, mozno kategorie, obrazky s metadatami a proste cokolvek.
Rozmyslam ake to ma negativa to takto riesit, ale zatial som nansiel nic dolezite, tak ze aky je konsenzus?
Taktiez aj na backende je lahsie si len spravit zoznam objektov ktore treba nasledne nacitat podla id a len vlozit do odpovede nez prechadzat hlavny zoznam a hladat ktory objekt kam patri. Na frontende zase klient nemusit robit nic ine len response.authors[article.created_by] a ma autora.
-
kdyz posles vsecky data tak klient nemusi udrzovat nejaky vnitrni stav seance. jinek musi klient udrzovat stav a musis hlidat poradi posilani dat, aby ti treba stare data neprepsaly nove.
-
Přesně to samé jsem udělal loni v jedno projektu a fungovalo to bez problémů.
Jen jsem tam neměl zvláštní ID (jako máš v příkladu 963), ale použil rovnou ID autora (45678).
U mě to dávalo smysl i proto, že seznam osob nebyl rozsáhlý a na klientovi se s těmi vazbami pracovalo (nešlo jen o created_by) a k záznamu se daly osoby i přidávat (vybírat ze seznamu), takže jsem ten samostatný seznam osob stejně potřeboval.
-
Je to možné to tak udělat, ale nejspíš to bude typický příklad předčasné optimalizace. Máte změřené, o kolik se tou vaší optimalizací zkrátí nebo prodlouží čas potřebný na získání odpovědi? O kolik se zmenší objem přenášených dat? Je akceptovatelné to, že se čas pro získání odpovědi prodlouží kvůli zmenšení dat? Bude to zmenšení dat měřitelné, když používáte kompresi? A pokud vám to všechno vyjde tak, že to má přínos – je ten přínos adekvátní tomu, jak se zkomplikuje kód na serveru i na klientovi?
Mimochodem, dá se to udělat i tak, že ty data o autorech nebude posílat server rovnou, ale nechá jejich dotažení na klientovi. Klient může mít cache a bude se dotazovat jenom na ty autory, které v cache ještě nemá. Pro nacachované autory to pak bude ještě rychlejší, pro ty nenacachované ještě pomalejší.
Stejně tak může jít o předčasnou optimalizaci, pokud ta data budete na serveru spojovat dohromady. Pokud už máte na klientovi komponentu, která dostane ID autora, stáhne si k němu potřebné údaje a ty zobrazí, je předčasná optimalizace cpát ta data do seznamu článků a dělat druhou komponentu na zobrazení autora, která data dostane rovnou.
Závěr je stejný, jako u každé jiné potenciální předčasné optimalizace – nedělejte to, dokud nezměříte, že je v tom opravdu problém.
-
pripadne i json jde zkomprimovat a poslat mene dat.
-
Přesně to samé jsem udělal loni v jedno projektu a fungovalo to bez problémů.
Jen jsem tam neměl zvláštní ID (jako máš v příkladu 963), ale použil rovnou ID autora (45678).
U mě to dávalo smysl i proto, že seznam osob nebyl rozsáhlý a na klientovi se s těmi vazbami pracovalo (nešlo jen o created_by) a k záznamu se daly osoby i přidávat (vybírat ze seznamu), takže jsem ten samostatný seznam osob stejně potřeboval.
Samozrejme to 963 je blbost a malo to byt 45678 :D cize sa bavime o rovnakej veci. Ja uz mam par rout kde to pouzivam a rozmyslam to hodit na vsetky skratka. Ako som pisal, nevidim zatial ziadne nedostatky tohto riesenia kedze vsetky data su v odpovedi, ide len o to ako si ich klient spracuje a mysli mze je jedno ci napriklad meno autora bude response.results[0].author.name alebo ci to bude response.authors[response.results[0].author].name.
-
Ako som pisal, nevidim zatial ziadne nedostatky tohto riesenia
Nedostatky jsou následující:
- Je to složitější na implementaci na serveru.
- Je to složitější na implementaci na klientovi.
- Pokud má klient dostatečně rychlé připojení k serveru, bude déle čekat na odpověď.
Ten poslední bod mi připadá nejzajímavější, protože pokud by „dostatečně rychlé“ připojení bylo vše, co je dnes běžně dostupné, znamenalo by to, že tímhle vylepšením zkomplikujete kód a ještě zpomalíte aplikaci drtivé většině uživatelů.
-
Ako som pisal, nevidim zatial ziadne nedostatky tohto riesenia
Nedostatky jsou následující:
- Je to složitější na implementaci na serveru.
- Je to složitější na implementaci na klientovi.
- Pokud má klient dostatečně rychlé připojení k serveru, bude déle čekat na odpověď.
Ten poslední bod mi připadá nejzajímavější, protože pokud by „dostatečně rychlé“ připojení bylo vše, co je dnes běžně dostupné, znamenalo by to, že tímhle vylepšením zkomplikujete kód a ještě zpomalíte aplikaci drtivé většině uživatelů.
??????? mam pocit ze asi nezijeme na rovnakej planete. ani jeden z tych bodov nema absolutne ziadne opodstanenie. Najskor si vobec nepochopil co sa tu riesi, inak si tu odpoved neviem vobec vysvetlit.
-
Mozno pomoze ak to napisem ako schemu(kde posty su primarny objekt dopytu):
Response
{
"posts[]": {
"id": "ID",
"channel": "ID",
"title": "string",
"teaser_text": "string",
}
},
"channels[]": {
"id": "ID",
"name": "string",
"handle": "string",
"summary": "string",
},
}
Cize ak chcem pre prvy prispevok z posts najst kanal kam patri tak si ho vytiahnem z response.channels namiesto toho aby ten kanal uz bol priamo v poste. Jasne ze rychlejsie je to ak response.channels je mapa a nie pole ale to uz su implementacne detajly.
A takto mozem vratit 100 postov ale len 5 kanalov napriklad, cize usetrim 95x velkost co by zabrali duplicitne kanaly. A to moze byt kludne aj 1kb a ked za den bude takych requestov 1000 tak to je hned mega za den, 30 mega za mesiace alebo 365mb rocne. A to je len jedna routa. Cize ta datova uspora moze byt nesmierne vysoka.
-
??????? mam pocit ze asi nezijeme na rovnakej planete. ani jeden z tych bodov nema absolutne ziadne opodstanenie. Najskor si vobec nepochopil co sa tu riesi, inak si tu odpoved neviem vobec vysvetlit.
Nebojte, programovat se může naučit každý, i vy. Takže cesta na mou planetu vám není uzavřená.
Začneme klientem. Už ten váš kód je zjevně složitější, než prosté přečtení údajů o autorovi ze záznamu o článku. Když budete chtít mít kód bezpečnější, přidáte tam typy – a ta vazba na autora najednou nebude moc dobře typově kontrolovaná. Když k tomu vytvoříte třeba JSON schema, budete tu vazbu muset popsat slovně, nebude deklarovaná přímo ve schématu. V klientském kódu bude více míst, kde může něco chybět – s čímž byste se měl v bezpečném kódu vypořádat.
Na serveru bude kód také složitější. Předpokládám, že data jsou uložena v nějaké relační databázi. Takže místo jednoduchého joinu, který klidně bude schovaný za nějakým ORM, budete muset nejprve načíst data o článcích, pak si z nich na serveru vytaháte ID autorů a pošlete druhý dotaz na data o autorech. A výsledek pak spojíte. Takže opět komplikovanější a hůře spravovatelný kód. Databáze mají limity na to, kolik hodnot můžete vložit do klauzule IN, takže ten váš kód nebude univerzální. Až někdo za pár let použije tu samou funkci pro export všech článků, narazí na nějaké instanci s počtem autorů větším než 1000 na to, že to nebude fungovat.
No a zpomalení odpovědi serveru plyne z toho, jak to bude aplikační server zpracovávat. V případě jednoduchého joinu je to jednoduchý dotaz na databázový server, odpověď DB serveru a z ní už se sestaví odpověď pro klienta. Takže jeden roundtrip na databázový server. Když budete ta data o autorech donačítat dodatečně, budete mít nejprve dotaz na články, počkáte na odpověď – to je první roundtrip na DB server. Na základě odpovědi pak vytvoříte druhý dotaz na autory – takže druhý roundtrip na DB server.
Abyste se tomu vyhnul, musel byste se na aplikačním serveru buď vrátit k tomu joinu a na aplikačním serveru pak vyzobávat data o autorech a cpát je do samostatné struktury, nebo tu logiku přenést na databázový server a implementovat tam.
Tj. všechno jsou to jen komplikace (i když třeba drobné), ale vůbec nevíme, zda to bude mít nějaký přínos, nebo zda to pro uživatele dokonce nebude zhoršení.
-
Ocividne problem nie je v navrhu/rieseni ale individualnej interpretacii implementacie, lebo nic z uvedenho sa mna netyka ani na stranke serveru, ani na stranke klienta.
-
A takto mozem vratit 100 postov ale len 5 kanalov napriklad, cize usetrim 95x velkost co by zabrali duplicitne kanaly. A to moze byt kludne aj 1kb a ked za den bude takych requestov 1000 tak to je hned mega za den, 30 mega za mesiace alebo 365mb rocne. A to je len jedna routa. Cize ta datova uspora moze byt nesmierne vysoka.
Vy se nepohybujete v jiném světě, ale v jiném čase. Zdravím do roku 1998. Tady u nás v roce 2024 není 365 MB ročně nesmírně vysoká úspora. Je to něco tak malého, že ani nikoho nenapadne se o tom bavit. Je to třeba velikost méně než deseti fotek z mobilu (ano, dnešními mobilními telefony se běžně fotí).
Ten 1 kB, který „ušetříte“, to je velikost jednoho paketu. Takže z hlediska uživatele neušetříte žádný čas. Pokud klient není někde na pomezí pokrytí signálem, nepozná rozdíl mezi doručením krátkého a dlouhého paketu. Jediné, co klient pozná (když to bude měřit), je zpomalení o ten druhý roundtrip do databáze. To budou v jednom datovém centru desítky až stovky milisekund, takže reálně to uživatel nepozná – ale proč mu čekání na data prodlužovat, byť jen o desítky milisekund?
A pak jste v tom vašem výpočtu úplně zapomněl na to, že přenášená data se komprimují. Pokud nemáte na serveru zapnutou kompresi, začněte tím, že ji zapnete.
-
Ocividne problem nie je v navrhu/rieseni ale individualnej interpretacii implementacie, lebo nic z uvedenho sa mna netyka ani na stranke serveru, ani na stranke klienta.
Na straně klienta už jste sám uvedl příklad, kde se vás to týká. A tu implementaci na straně serveru, kde byste to nemusel řešit, bych teda chtěl vidět.
-
Pointa otazky bola: "ano, nasadili sme to, funguje to bez problemov", alebo "ano, skusali sme to, mali sme problemy s A, B, C tak sme sa vratili na povodnu schemu".
A pak jste v tom vašem výpočtu úplně zapomněl na to, že přenášená data se komprimují. Pokud nemáte na serveru zapnutou kompresi, začněte tím, že ji zapnete.
Co je to kompresia?
-
Pointa otazky bola: "ano, nasadili sme to, funguje to bez problemov", alebo "ano, skusali sme to, mali sme problemy s A, B, C tak sme sa vratili na povodnu schemu".
Ano, nasadili jsme to v některých specifických případech, kdy jsme si změřili, jaký to má přínos; zvážili jsme negativní dopady, kterým rozumíme; a z porovnání nám vyšlo, že se to vyplatí. Počítáme s tím, že pokud se do budoucna změní způsob použití, budeme to muset změnit.
Plošně jsme to nenasazovali, protože o problémech jsme věděli dopředu a nepotřebovali jsme to zkoušet, abychom na ně přišli. Držíme se obecného principu, že předčasná optimalizace, která není podložená daty, je špatná optimalizace.
Co je to kompresia?
Kompresia dát (https://sk.wikipedia.org/wiki/Kompresia_d%C3%A1t). Doporučuju přepnout si článek na češtinu nebo lépe angličtinu, v nich jsou články obsáhlejší než ve slovenštině.
Přenášená data komprimuje rovnou webový server, v aplikaci se o to vůbec nemusíte starat. Jenom se na serveru zapne podpora komprese a vyberou se algoritmy, které se mohou používat. Prohlížeč s požadavkem serveru pošle informaci, které kompresní algoritmy podporuje, server podle toho vybere ten nejlepší, který podporuje také, a data při přenosu online komprimuje a klient zase dekomprimuje. Opakovaná data v JSONu jde komprimovat velmi dobře. Výsledná velikost zkomprimovaného JSONu s opakujícími se daty a s vaší úpravou bude pravděpodobně hodně podobná, dokonce by po té vaší úpravě mohla být zkomprimovaná data i větší. Snadno to zjistíte tak, že si vyrobíte ty dva JSONy s plným a vaším „vylepšeným“ formátem a zkomprimujete je pomocí gzipu – to je základní kompresní algoritmus, který podporují všechny prohlížeče včetně historických. A uvidíte, jak moc se od sebe velikost těch zkomprimovaných souborů liší.
-
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).
-
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.
-
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í.
-
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 (https://www.stilldrinking.org/programming-sucks), konkrétně pak kapitolu All code is bad.
-
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 (https://www.stilldrinking.org/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)
-
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.
-
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.
-
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.
-
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í.
-
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.
-
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.
-
Myslim, ze sa tostandardne robi cez $ref a $id, ale otazne je kolko parserov to zvladne.
-
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.
-
Ten identifikator moze byt akekolvek unikatny string vramci jsonu. Len OpenAPI si zvolilo velmi ukecany format.