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

• #7990 martonx veterán instantwater #7988

  Új Válasz 2020-07-24 23:35:19 #7990

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz instantwater #7988 üzenetére

  "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.

• #7989 estro csendes tag instantwater #7988

  Új Válasz 2020-07-24 23:03:01 #7989

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  estro

  csendes tag

  válasz instantwater #7988 üzenetére

  A rest api-t úgy kellene tervezni, hogy ne legyen felesleges property a jsonben. Ezért írnak DTO-kat backend oldalon, hogy azt kapja a frontend amire szüksége van.
  Bár ez sok esetben sajnos nem így történik és iszonyú mappalésekbe kezd a js, hogy használható legyen az adat.

  Nem használatam még GraphQL-t, de úgy tudom az-az előnye, hogy nem kell a folyton változó üzleti igényekhez igazítani a backendet is ha valami plusz property kell a UI-ra, hanem elég csak js kódot módosítani. Normál esetben ilyenkor a backend-et kell megkérni hogy ezt meg azt is rakja bele a responseba, de ez kihagyható GraphQL-el. Sokkal függetlenebb a frontend. Viszont ennek sok hátránya van backend oldalon (sql lekérdezések optimalizálása, authorization, stb.)

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