Plnohodnotná Evidence lobbistických kontaktů

Moderátoři: Republikové předsednictvo - asistenti, Vedoucí centrálních orgánů, Personální odbor - celý

Pravidla fóra
Úkoly nyní postupně převádíme do nového specializovaného systému Úkoly. Nové úkoly prosím dávejte přímo tam. Diskuse k úkolům je tam také možná, pouze musíte být přihlášeni. Jakmile dojde k odladění nového systému a převedení veškerých úkolů, bude toto fórum uzavřeno, archivováno a zrušeno.
Děkujeme za pochopení.
Zamčeno
Uživatelský avatar
Jan.Bednarik
Administrativní odbor
Příspěvky: 2789
Registrován: 24 říj 2017, 00:23
Profese: vývojář SW
Bydliště: Olomouc
Dal poděkování: 6106 poděkování
Dostal poděkování: 7199 poděkování

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Jan.Bednarik »

No on ten registr má jen API. To webové UI co vidíš, je aplikace, co to vyzobává z API na jiném serveru 8-) Je to tak schválně, aby nějaká aplikace neměla výhodu dostat se k něčemu, co není součástí API.

API je dle specifikace GraphQL a běží na https://lobbyapi.pldev.eu/graphql Na stejné adrese se v prohlížeči otevře nástroj GraphiQL, který umožňuje procházet strukturu a dokumentaci toho API, a hrát si s tím. Například pokud budeš chtít získat základní info o reportu se jménem autora, uděláš to tímto dotazem. API splňuje specifikaci serveru pro Relay, proto jsou tam na první pohled divné věci jako "edges" a "node".
Tito uživatelé poděkovali autorovi Jan.Bednarik za příspěvek:
Ondrej.Profant

„Vidíš-li, že se člověk mýlí, nehněvej se naň. Pomni, že není možné mýlit se schválně.“ Seneca

člen CF • člen a dělník v TO (vývoj a správa systémů) • člen AO • předsedající CF
RV (11/2019–3/2023) • předseda OLK (6/2018–11/2019) • místopředseda MS Olomouc (12/2017–6/2018)
jan.bednarik@pirati.cz • 603 439 481 • pište mi na Zulip

Uživatelský avatar
Petr.Vileta
Člen KS Plzeňský kraj
Příspěvky: 34711
Registrován: 22 črc 2009, 18:12
Profese: Celkem Spokojený Důchodce
Bydliště: Plzeň 2
Dal poděkování: 31639 poděkování
Dostal poděkování: 25736 poděkování
Kontaktovat uživatele:

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Petr.Vileta »

Jan.Bednarik píše:Například pokud budeš chtít získat základní info o reportu se jménem autora ...
To vypadá, že bych to snad mohl pochopit i já. Ještě pár trknutí a třeba se mi to povede. :D

Když tedy budu chtít získat:
a) posledních pět ID, jak se zeptám?
b) všechna ID od 25.02.2018 0:0:0 do 25.02.2018 23:59:59, jak se zeptám?
c) všechna ID, kde author firstName = "Jan" a author lastName = "Posvar", jak se zeptám?

Řadový člen, stínový ministr švihlých nápadů a fórista

Fide, sed cui fidas, vide.
Věř, ale komu věříš měř.

(Perchta z Pernštejna - Bílá paní)

Uživatelský avatar
Jiri.Koudelka
Člen KS Praha
Příspěvky: 158
Registrován: 19 dub 2017, 21:41
Profese: programátor
Dal poděkování: 1251 poděkování
Dostal poděkování: 400 poděkování
Kontaktovat uživatele:

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Jiri.Koudelka »

Petr.Vileta píše:Když tedy budu chtít získat:
Specifikace GraphQL je tady: http://facebook.github.io/graphql/October2016/#

Za mě je to trochu bourací kladivo na mravence, ale kecat do toho autorovi nebudu :)
Uživatelský avatar
Petr.Vileta
Člen KS Plzeňský kraj
Příspěvky: 34711
Registrován: 22 črc 2009, 18:12
Profese: Celkem Spokojený Důchodce
Bydliště: Plzeň 2
Dal poděkování: 31639 poděkování
Dostal poděkování: 25736 poděkování
Kontaktovat uživatele:

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Petr.Vileta »

Jiri.Koudelka píše:
Petr.Vileta píše:Když tedy budu chtít získat:
Specifikace GraphQL je tady: http://facebook.github.io/graphql/October2016/#

Za mě je to trochu bourací kladivo na mravence, ale kecat do toho autorovi nebudu :)
Vidím GraphQL poprvé v životě a učím se metodou LOFFTOPICearn BOFFTOPICy EOFFTOPICxample, čili jeden fungující příklad nad konkrétními daty je pro mě víc než 1000 přečtených stran manuálu. ;)

Prosím, můžeš napsat řešení těch 3 příkladů?

Řadový člen, stínový ministr švihlých nápadů a fórista

Fide, sed cui fidas, vide.
Věř, ale komu věříš měř.

(Perchta z Pernštejna - Bílá paní)

Uživatelský avatar
Jan.Bednarik
Administrativní odbor
Příspěvky: 2789
Registrován: 24 říj 2017, 00:23
Profese: vývojář SW
Bydliště: Olomouc
Dal poděkování: 6106 poděkování
Dostal poděkování: 7199 poděkování

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Jan.Bednarik »

Petr.Vileta píše:To vypadá, že bych to snad mohl pochopit i já. Ještě pár trknutí a třeba se mi to povede. :D

Když tedy budu chtít získat:
a) posledních pět ID, jak se zeptám?
Ideálně tak, že si řekneš o `first: 5` seřazených dle data od nejstaršího (což zatím nejde, zatím to vrací reporty jen dle data od nejnovějšího). Druhá možnosti je použít stránkování výsledků, kdy uděláš dotaz na `first: 5, after: "MTIwNQ=="` (ukázka zde), kde to after je cursor šestého nodu od konce (získaný jako `base64(totalCount - 5)`).
Petr.Vileta píše:b) všechna ID od 25.02.2018 0:0:0 do 25.02.2018 23:59:59, jak se zeptám?
Hledat dle data schůzky zatím nejde, ale časem půjde.
Petr.Vileta píše:c) všechna ID, kde author firstName = "Jan" a author lastName = "Posvar", jak se zeptám?
Hledání v autorech podle jména zatím nejde. Nicméně když si najdeš jeho ID ve výpisu všech autorů, můžeš se pak dotázat na něj a jeho reporty podle ID v Node interface.

„Vidíš-li, že se člověk mýlí, nehněvej se naň. Pomni, že není možné mýlit se schválně.“ Seneca

člen CF • člen a dělník v TO (vývoj a správa systémů) • člen AO • předsedající CF
RV (11/2019–3/2023) • předseda OLK (6/2018–11/2019) • místopředseda MS Olomouc (12/2017–6/2018)
jan.bednarik@pirati.cz • 603 439 481 • pište mi na Zulip

Uživatelský avatar
Petr.Vileta
Člen KS Plzeňský kraj
Příspěvky: 34711
Registrován: 22 črc 2009, 18:12
Profese: Celkem Spokojený Důchodce
Bydliště: Plzeň 2
Dal poděkování: 31639 poděkování
Dostal poděkování: 25736 poděkování
Kontaktovat uživatele:

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Petr.Vileta »

Jan.Bednarik píše:Ideálně tak, že si řekneš o `first: 5` seřazených dle data od nejstaršího (což zatím nejde, zatím to vrací reporty jen dle data od nejnovějšího). Druhá možnosti je použít stránkování výsledků, kdy uděláš dotaz na `first: 5, after: "MTIwNQ=="` , kde to after je cursor šestého nodu od konce (získaný jako `base64(totalCount - 5)`).
Díky za trpělivost. Budu potřebovat víc příkladů, zatím dost tápu :?

Mimochodem, ten base64() to samozřejmě neumí, takže si musím jedním dotazem hrábnout pro totalcount, pak si to na své straně převést na base64 encoded string a dalším dotazem si hrábnout pro data, že? Chápu, že dnes má rychlý internet každý :D , ale mě přijde např. MySQL chytřejší v tom, že si můžu jedním dotazem o více řádcích (definice proměnných atd.) říct rovnou o data.

Řadový člen, stínový ministr švihlých nápadů a fórista

Fide, sed cui fidas, vide.
Věř, ale komu věříš měř.

(Perchta z Pernštejna - Bílá paní)

Uživatelský avatar
Andrej.Ramaseuski
Jednatel/ka republikového výboru
Příspěvky: 3453
Registrován: 28 srp 2016, 20:49
Profese: programátor
Bydliště: Sedlíšťka (Radhošť)
Dal poděkování: 2627 poděkování
Dostal poděkování: 5066 poděkování
Kontaktovat uživatele:

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Andrej.Ramaseuski »

Petr.Vileta píše:Mimochodem, ten base64() to samozřejmě neumí, takže si musím jedním dotazem hrábnout pro totalcount, pak si to na své straně převést na base64 encoded string a dalším dotazem si hrábnout pro data, že? Chápu, že dnes má rychlý internet každý :D , ale mě přijde např. MySQL chytřejší v tom, že si můžu jedním dotazem o více řádcích (definice proměnných atd.) říct rovnou o data.
Opravdovy samuraj nikdy nehleda nejkratsi cestu. Nasim cilem neni udelat zivot jednodussim :)

V tomto pripade existuji dve cesty - pracovat primo z databazi, a aplikacem tretich stran, z duvodu bezpecnoti, nedat zadny pristup, nebo, vyuzit komplikovanejsi nadstavbu, nejlip tak narocnou a komplikovanou, aby vyvojari externich aplikaci to vzdali sami, no, a za to zaplatit jenom vyssi provozni rezii a komplikacema pro sebe. a nejaka stredni cesta - spravne nastaveni pristupovych prav k databazi (i kdyz, pravda, ani na cteni nedavam rad prava nekomu cizimu) nebo (pro tento pripad naprosto dostacujici) REST api - to je pro amatery.
Tito uživatelé poděkovali autorovi Andrej.Ramaseuski za příspěvek:
Petr.Vileta

0x8DE5F4739D2A2F0B | Ceterum censeo Facebook esse delendam

Uživatelský avatar
Jan.Bednarik
Administrativní odbor
Příspěvky: 2789
Registrován: 24 říj 2017, 00:23
Profese: vývojář SW
Bydliště: Olomouc
Dal poděkování: 6106 poděkování
Dostal poděkování: 7199 poděkování

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Jan.Bednarik »

Andrej.Ramaseuski píše: 26 úno 2018, 09:03
Petr.Vileta píše:Mimochodem, ten base64() to samozřejmě neumí, takže si musím jedním dotazem hrábnout pro totalcount, pak si to na své straně převést na base64 encoded string a dalším dotazem si hrábnout pro data, že? Chápu, že dnes má rychlý internet každý :D , ale mě přijde např. MySQL chytřejší v tom, že si můžu jedním dotazem o více řádcích (definice proměnných atd.) říct rovnou o data.
Opravdovy samuraj nikdy nehleda nejkratsi cestu. Nasim cilem neni udelat zivot jednodussim :)

V tomto pripade existuji dve cesty - pracovat primo z databazi, a aplikacem tretich stran, z duvodu bezpecnoti, nedat zadny pristup, nebo, vyuzit komplikovanejsi nadstavbu, nejlip tak narocnou a komplikovanou, aby vyvojari externich aplikaci to vzdali sami, no, a za to zaplatit jenom vyssi provozni rezii a komplikacema pro sebe. a nejaka stredni cesta - spravne nastaveni pristupovych prav k databazi (i kdyz, pravda, ani na cteni nedavam rad prava nekomu cizimu) nebo (pro tento pripad naprosto dostacujici) REST api - to je pro amatery.
Přístupovými právy k databázi by se nic nevyřešilo. Musela by se do té databáze přesunout celá business logika toho registru, což by teoreticky možná šlo (naprogramovat to tam pomocí PL/Python), ale byl by to pořádný masochismus. Bylo by náročné to zdokumentovat, aplikace komunikující s tím registrem by byly velmi náchylné na rozbití při každé změně schematu databáze, a čistě prakticky by se narazilo na omezení počtu spojení do databáze. A taky je tam ten Elasticsearch pro vyhledávání, tak to není jen o jedné databázi, ale API kombinuje údaje z více zdrojů.

Ono se v tom registru děje mnohem víc věcí, než jen CRUD operace. REST API by na to jednoduše nasadit nešlo (jako jen vrstvu nad databázi). Navíc v dnešní době mobilních webů a aplikací je třeba umět jedním dotazem na API získat pokud možno všechna související data (třeba jméno a příjmení autora a k němu datum a titulek všech jeho schůzek) a zároveň nestahovat nic navíc (nechce se tahat vždy všechny informace o autorovi či schůzce). REST API se dá ohnout, aby tyhle věci šly dělat, je to ale hrozný opruz na implementaci, testování a dokumentaci, a ve výsledku je to hrozně krkolomné na použití (milión všelijakých parametrů v URL). GraphQL je taková přirozená evoluce v oblasti API, která ty potřeby řeší přímočaře a jednoduše bez potřeby to náročne zdokumentovat.
Tito uživatelé poděkovali autorovi Jan.Bednarik za příspěvek:
Vit.Fux

„Vidíš-li, že se člověk mýlí, nehněvej se naň. Pomni, že není možné mýlit se schválně.“ Seneca

člen CF • člen a dělník v TO (vývoj a správa systémů) • člen AO • předsedající CF
RV (11/2019–3/2023) • předseda OLK (6/2018–11/2019) • místopředseda MS Olomouc (12/2017–6/2018)
jan.bednarik@pirati.cz • 603 439 481 • pište mi na Zulip

Uživatelský avatar
Andrej.Ramaseuski
Jednatel/ka republikového výboru
Příspěvky: 3453
Registrován: 28 srp 2016, 20:49
Profese: programátor
Bydliště: Sedlíšťka (Radhošť)
Dal poděkování: 2627 poděkování
Dostal poděkování: 5066 poděkování
Kontaktovat uživatele:

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Andrej.Ramaseuski »

Jan.Bednarik píše: 01 bře 2018, 12:17
Andrej.Ramaseuski píše: 26 úno 2018, 09:03 V tomto pripade existuji dve cesty - pracovat primo z databazi, a aplikacem tretich stran, z duvodu bezpecnoti, nedat zadny pristup, nebo, vyuzit komplikovanejsi nadstavbu, nejlip tak narocnou a komplikovanou, aby vyvojari externich aplikaci to vzdali sami, no, a za to zaplatit jenom vyssi provozni rezii a komplikacema pro sebe. a nejaka stredni cesta - spravne nastaveni pristupovych prav k databazi (i kdyz, pravda, ani na cteni nedavam rad prava nekomu cizimu) nebo (pro tento pripad naprosto dostacujici) REST api - to je pro amatery.
Přístupovými právy k databázi by se nic nevyřešilo. Musela by se do té databáze přesunout celá business logika toho registru, což by teoreticky možná šlo (naprogramovat to tam pomocí PL/Python), ale byl by to pořádný masochismus. Bylo by náročné to zdokumentovat, aplikace komunikující s tím registrem by byly velmi náchylné na rozbití při každé změně schematu databáze, a čistě prakticky by se narazilo na omezení počtu spojení do databáze. A taky je tam ten Elasticsearch pro vyhledávání, tak to není jen o jedné databázi, ale API kombinuje údaje z více zdrojů.
PL/Perl, Pl/pgsql... ano, urcita mezivrstva abstakce by asi byt mela, ale kdyz se ti zmeni schema databazi, tak stejne budes muset zmenit databazovy model v API, takze to bude rozbity tak nebo tak. A, kdyz uz jses uspesne premigrovany na postgres, tak asi by bylo logicky pouzit nativni Postgres FTS misto mostrozniho Elasticsearch?
Jan.Bednarik píše: 01 bře 2018, 12:17Ono se v tom registru děje mnohem víc věcí, než jen CRUD operace. REST API by na to jednoduše nasadit nešlo (jako jen vrstvu nad databázi). Navíc v dnešní době mobilních webů a aplikací je třeba umět jedním dotazem na API získat pokud možno všechna související data (třeba jméno a příjmení autora a k němu datum a titulek všech jeho schůzek) a zároveň nestahovat nic navíc (nechce se tahat vždy všechny informace o autorovi či schůzce). REST API se dá ohnout, aby tyhle věci šly dělat, je to ale hrozný opruz na implementaci, testování a dokumentaci, a ve výsledku je to hrozně krkolomné na použití (milión všelijakých parametrů v URL). GraphQL je taková přirozená evoluce v oblasti API, která ty potřeby řeší přímočaře a jednoduše bez potřeby to náročne zdokumentovat.
No, pamatuji si na pekny pripad API ktere take nepotrebovalo dokumentovat - SOAP. Ale nejak se mi nezda ze by se to moc rozsirilo mimo M$.
GraphQL, samozrejme, vypada lip. Ale, zas, ten puvod z facebook a ta vazba na react se mi moc nelibi... No, asi bych to mel nejak otestovat v praxi, treba se mi to bude libit...
Tito uživatelé poděkovali autorovi Andrej.Ramaseuski za příspěvky (celkem 2):
Jan.Bednarik, Rostislav.Reha

0x8DE5F4739D2A2F0B | Ceterum censeo Facebook esse delendam

Uživatelský avatar
Jan.Bednarik
Administrativní odbor
Příspěvky: 2789
Registrován: 24 říj 2017, 00:23
Profese: vývojář SW
Bydliště: Olomouc
Dal poděkování: 6106 poděkování
Dostal poděkování: 7199 poděkování

Re: Plnohodnotná Evidence lobbistických kontaktů

Příspěvek od Jan.Bednarik »

Andrej.Ramaseuski píše: 01 bře 2018, 14:03 PL/Perl, Pl/pgsql... ano, urcita mezivrstva abstakce by asi byt mela, ale kdyz se ti zmeni schema databazi, tak stejne budes muset zmenit databazovy model v API, takze to bude rozbity tak nebo tak. A, kdyz uz jses uspesne premigrovany na postgres, tak asi by bylo logicky pouzit nativni Postgres FTS misto mostrozniho Elasticsearch?
Ono to API neodpovídá 1:1 databázi. Ideálně bych se chtěl vyvarovat zpětně nekompatibilních změn, které by z API něco odebíraly. Rozšiřování / přidávání informací to nerozbije.

Jsem ten projekt začal, abych se na tom naučil něco nového pro sebe - Elasticsearch. FTS v PostgreSQL by možná mohl stačit, ale s Elasticsearchem mám celkem jistotu, že nenarazím na to, že by něco něšlo. Tak ho tam ponechám.
Andrej.Ramaseuski píše: 01 bře 2018, 14:03 No, pamatuji si na pekny pripad API ktere take nepotrebovalo dokumentovat - SOAP. Ale nejak se mi nezda ze by se to moc rozsirilo mimo M$.
GraphQL, samozrejme, vypada lip. Ale, zas, ten puvod z facebook a ta vazba na react se mi moc nelibi... No, asi bych to mel nejak otestovat v praxi, treba se mi to bude libit...
SOAP kdysi frčel, ale ten historický trend je jasný: SOAP -> REST -> GraphQL. Já jsem navrhoval, dokumentoval a vyvýjel REST APIčka ke spoustě služeb, ale poté, co jsem okusil GraphQL, už pro mě není cesta zpět :-)

„Vidíš-li, že se člověk mýlí, nehněvej se naň. Pomni, že není možné mýlit se schválně.“ Seneca

člen CF • člen a dělník v TO (vývoj a správa systémů) • člen AO • předsedající CF
RV (11/2019–3/2023) • předseda OLK (6/2018–11/2019) • místopředseda MS Olomouc (12/2017–6/2018)
jan.bednarik@pirati.cz • 603 439 481 • pište mi na Zulip

Zamčeno

Zpět na „Administrativa“