Hirdetés

Új hozzászólás Aktív témák

  • martonx
    veterán

    A redux valóban egy fura találmány, de mindenki siet Hookokra átállni, most az a menő.
    Én sem értem, hogy tudott elterjedni a redux.

    A GraphQLnek annyi előnye van a REST APIval szemben, hogy rugalmasan kezeli az átvitt adatmezőket, tehát a kliens adja meg, mely mezőkre van szüksége az eredményhalmazból, míg hagyományos RESTnél mindent le kell töltened.

    Lehet, hogy az alkalmazásodnak az adott lekérdezésből mindössze 2-3 mező kell, de az adattípus 10-20 mezőt tartalmaz, esetenként még néhány mező tartalmaz további elemeket (tömb/objektum).

    Ez egy nagy eredménylistánál sok adatot jelent, amivel nem terheled a lassú 3/4G hálózatot.

    Valamint a GraphQL támogatja több lekérdezés összefűzését, így egy roundtrip latencyvel megúszod ami hagyományos REST APInál 2-3-4 lekérdezés lenne 2-3-4x roundtrip latencyvel, és a felhasználónak minden századmásodperc számít.

    Egy nagyon meggyőző GraphQL use case a PostGraphile ami Postgres tárolt eljárásokat tud elérhetővé tenni GraphQL APIn keresztül, így automatikusan generálva az APIt, ezzel minimálisra csökkentve a boilerplate kódot.

    A végére pedig a sokkkkkkhatás. Még ma is használnak FTPn keresztül CSVt, mert a rendszer amiből az adat jön az egy ősszörnyeteg, és így exportál bizonyos adatokat periodikusan.

    "Lehet, hogy az alkalmazásodnak az adott lekérdezésből mindössze 2-3 mező kell, de az adattípus 10-20 mezőt tartalmaz, esetenként még néhány mező tartalmaz további elemeket (tömb/objektum).
    Ez egy nagy eredménylistánál sok adatot jelent, amivel nem terheled a lassú 3/4G hálózatot.
    Valamint a GraphQL támogatja több lekérdezés összefűzését, így egy roundtrip latencyvel megúszod ami hagyományos REST APInál 2-3-4 lekérdezés lenne 2-3-4x roundtrip latencyvel, és a felhasználónak minden századmásodperc számít."

    Ez így elméletben tök jól hangzik, gyakorlatilag, amikor saját SPA alá REST API-kat írunk, eddig se küldtünk ki minden szemetet, csakis azt, ami kellett. Más kérdés, hogy 3rd party API-knál ennek lenne létjogosultsága, viszont 99%-ban pont ők azok, akiktől FTP-n csv-ben tudod leszedni az adatot...

    A több lekérdezés összefűzése elméletben faszán hangzik, gyakorlatban meg plusz js komponenseket kell használni, hogy az ember megspóroljon pár (lehet, hogy épp semennyi) roundtrip latency-t.. Miközben a plusz js letöltésének, feldolgozásának is van ideje.

    No mindegy, mondom a koncepciót értem, azt az őrült nagy hozadékát nem érzem, mint anno amikor egy full fos, senki senkivel nem kompatibilis SOAP-ot, vagy FTP-s csv API-kat, leváltotta a Rest API.
    Sajnos viszont a gyakorlat nálam is azt mutatja, hogy például a GLS most szuper büszke az újonnan elkészült új API-jára idézem: legkorszerűbb eszközök alkalmazásával jobb felhasználói élményt biztosítunk.
    Na ez az új interfészük ősi .Net Framework 4.5.2-vel készült, WCF technológiával, ami olyan 2005 táján volt menő. Jó, mondjuk ahhoz képest, hogy az előző (mármint a jelenleg használt) API-juk meg VB scriptes classic ASP-s volt, ahhoz képest végülis ugrottak az időben 10 évet előre.

Új hozzászólás Aktív témák