Kickoff GraphQL servera pre Otvorené API

[michalkvasnicak]

Rýchly kick off GraphQL servera https://github.com/michalkvasnicak/open-api-graphql

Je to robené na rýchlo tak som previedol len CRZ avšak pozmenil som schému response aby mala tvar vhodnejší pre GraphQL.

Vytvárajte PR pre ďalšie schémy :) prípadne pre opravy.

[jsuchal]

@michalkvasnicak sorry za neznalost, ale aka je vyhoda v tomto?

[michalkvasnicak]

Ani by som nepovedal, že je to nejaká výhoda, skôr len enhancement ak by niekto chcel skladať nejakú appku a nechcel mať v response všetky dáta ale len to čo potrebuje.

[jsuchal]

ok chapem, inak aktivite sa medze nekladu, ale momentalne by sme skor prijali nejake tie appky a ziskavanie dalsich dat :)

[michalkvasnicak]

Rozumiem, ináč je niekde dostupný endpoint na získanie zoznamu zmlúv? Pretože som sa dopátral len k detailu. Možno som to prehliadol v noci.

[jsuchal]

@michalkvasnicak zoznam zmluv? je tam api na synchronizaciu vid https://ekosystem.slovensko.digital/otvorene-api#získanie-zmenených-zmlúv-od-daného-času to by nestacilo?

Lebo zmluv je vela celkom

[michalkvasnicak]

Ide to, že takto musím vytvoriť vlastný backend k tomu aby som tieto zmluvy uložil, tento graphql server slúži len ako jednoduchý wrapper okolo existujúceho API.

Momentálne nie je možnosť prechádzať si zoznamom zmlúv. Je nejaký dôvod prečo na to nie je API endpoint? Klasická paginácia page + limit?

[jsuchal]

@michalkvasnicak klasicka paginatia page + limit ma velky problem tu http://use-the-index-luke.com/no-offset

• isli sme na uvod minimalisticky. Ak by som pridal paginate tak take api je sice pekne ale realne ho nikto nebude pouzivat lebo by videl asi nieco taketo.

Co sice na prvy pohlad vyzera rozumne, ale prakticke pouzitie je uplne nulove, kedze tych zmluv je cez milion a nikto to takto nebude realne robit. Resp. budem cakat kym ma niekto presvedci o opaku. Skor ma zmysel search api a tam radsej pockam na aplikaciu.

Cize pokial nemame poziadavku na toto z realnej aplikacie, tak to je IMHO predcasne.

[michalkvasnicak]

Rozumiem. Ide o to, že na to aby som mohol použiť detail zmluvy, tak musím vedieť jej ID. Viem momentálne nejako zistiť toto ID? Alebo je to na komunite aby vzala dataset a spravila nad ním vlastné API?

[jsuchal]

Cez synchronizacne API sa dostanes k vsetkym ID aj obsahom.

Ale vratme sa este raz spat, to ID asi nechces len nejake nahodne. Co ma splnat ta zmluva, ktorej ID ta zaujima? Na toto musi by realisticky scenar. Ja ho nevidim.

Samozrejme radi dorobime API, len to musi mat zmysel.

[msimulcik]

@michalkvasnicak chvalim iniciativu s GraphQL. Pohol si sa s tym niekam dalej od augusta?

@jsuchal na to co potrebuje @michalkvasnicak by bolo treba pridat filtrovanie, sorting a cursor based pagination, aby to bolo pouzitelne. Tam potom ale moze byt problem ustrazit kombinacie vsetkych filtrov a sortingu, tak aby queries boli performant. Asi naozaj bude treba use case, aby sa to oplatilo robit.

Kazdopadne s tymto rad pomozem, keby bolo treba.

[michalkvasnicak]

@msimulcik nemal som čas na to odvtedy moc + chcelo by to preniesť do nového stacku (napríklad, ktorý používam v práci) kde je generovanie schém jednoduchšie atď.

[jsuchal]

Hlavne stále nemáme reálny usecase na toto. Až príde tak budem prvý kričať
že toto spravme.

On Thu, 3 Nov 2016, 10:19 Michal Kvasničák, [email protected]
wrote:

@msimulcik https://github.com/msimulcik nemal som čas na to odvtedy moc

• chcelo by to preniesť do nového stacku (napríklad, ktorý používam v
  práci) kde je generovanie schém jednoduchšie atď.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABm5sacBz7-NZ0n9sbXJBA5EwIixcIzks5q6acKgaJpZM4Jn_Fs
.