Názory k článku Tři nástrahy GraphQL: na co si dát pozor

Ne, neví a nevíš to evidentně ani ty.

Je to přesně naopak, než píšeš. U RESTu často narážíš na to, že různí klienti mají různé požadavky a tak pro ně děláš různé verze volání, které dělají podobné věci (nebo jedno různě parametrizované) a je v tom bordel. GraphQL poskytuje standardizovaný způsob, jak klient může říct, co chce a co nechce. Tedy jedním rozhraním můžeš efektivně obsloužit klienty s různými požadavky. Kapišto?

A tak pro ně děláš různé verze volání, které dělají podobné věci.

lol what :)

RemindMe! 1 year ... az budes obhajovat uplny opak :)

to fakt ani nema c ani c++ knihovnu pro klienta?

Neboj, že jsi kecka co plácá o něčem, o čem nic neví, jsme pochopili už z tvého prvního příspěvku, nemusíš nás v tom nadále ujišťovat ;)

V GraphQL nadeklaruješ datový model, u volání definuješ, jaký typ vrací a GraphQL sever side knihovna se už postará, aby klient dostal přesně ta data, která chce. A nádavkem k tomu máš kontrolu konzistence dat s deklarací (typy, povinnosti, ...) na vstupu i výstupu. Chápu, že pro člověka zahrabaného v zastaralých technologiích to musí být stejné sci-fi jako hooverboard pro Martyho McFlye, ale fakt to funguje :)

@L

Na to aby ti klient poslal v requestu seznam položek které chce potřebuješ GraphQL? A když budou mít různí klienti různé požadavky tak ty data nebudeš muset přidávat do GraphQL zdrojů, ony se tam budpu postupně zhmotňovat?
Jedinou výhodu vidím v tom, že si můžeš při vývoji vymýšlet vůči endpointu real time a neštudovat dokumentaci. Na samotné requesty pro hotového klienta už "seznam" parametrů stejně mít musíš a odpověď stejně oktrolovat musíš pokud chceš ty z response používat. Jako GraphQl proč ne, ale že by to byl nějaký zázrak ....

> Na to aby ti klient poslal v requestu seznam položek které chce potřebuješ GraphQL?

Samozřejmě, že ne. Viděl jsem už REST rozhraní, kde si klient specifikoval pole objektu, která chce vrátit. Jenže když je ono pole samo složený objekt, začíná to být složitější. Takže jistě, můžete si napsat vlastní něco-jako-graphql framework. Ale bude trpět všemi nectnostmi podobných in-house frameworků: Bere vám čas na psaní vlastní aplikace, nemáte čas na jeho údržbu, noví lidé se jej musí učit...

U GraphQL máte tohle všechno out-of-the-box včetně toolingu (Voyager, podpory v IDE, ...).

@L

Na druhou stranu GraphQL nemá oficiální implementace pokud vím což často taky není to co člověk chce. Argument hotového řešení uznávám, ale i ten má své neduhy ... AFAIK třeba spring.io má vlastní REST implementaci, takže není to jenom o in-house, ale s tím nepracuji. Většinou REST nepotřebuji, stačí specifické ajax datarequesty - stejně vím co potřebuji a nic navíc nechci ani deklarovat, ani selectovat ani vracet ani zpracovávat .... A až se to za ?čas změní, tak to změním nebo se to celé zruší i s částí klienta. Jenom chci říct, že na většinu denní práce je to IMO kanón na komára ...

Máte pravdu, ale já hlavně na GraphQL nechápu jednu věc a to je, proč se nelze jednoduše dostat k tomu, co vlastně klient chce vrátit za data. Protože typický namapování na databázi znamená, že když mu na jedno query můžu vrátit třeba data ze 4 tabulek tak musím udělat 3x JOIN. A to i za předpokladu, že chce data jenom z jedné, tak stejně bez nějakého "hackování" se prostě nemám jak dostat k tomu co klient chce, abych mohl udělat jednodušší SQL dotaz a musím z databáze tahat všechno (a jenom to nepošlu přes síť klientovi). Nevím jestli je to takhle i u všech implementací, ale minimálně v PHPku nic jednoduchého jako třeba $resolveInfo->getWhatFieldsCli­entWants() udělat nejde.

To je věc implementace, v princpu samozřejmě nic nebrání, aby resolver věděl, jaká pole klient chce. Nebo je možné navázané relace v základu nejoinovat, ale nadefinovat na pole (field) resolver, který data dotáhne. A ten bude zavolán pouze tehdy, pokud pole klient chce (pokud je ten PHP framework alespoň trochu smysluplně napsaný - v PHP jsem klienta nepsal). Samozřejmě, když to pole bude chtít, je to výkonově horší, než to rovnou joinovat, zase když h onebude chtít je to rychlejší - záleží pak už na konkrétní situaci, co je lepší řešení.

@Kokos

Ano, takové overkilly bývají většinou skvělý nápad. A na to myslím naráželi komentáře směrem k JS vývojářům které to často vůbec netrápí ...

"Neboj, že jsi kecka co plácá o něčem, o čem nic neví, jsme pochopili už z tvého prvního příspěvku, nemusíš nás v tom nadále ujišťovat ;)"

Kolik vas tam za timhle L. uctem je, ze pisete v mnoznem cisle? Jeden jakysi kecal co si vyka?
Mluvte za sebe. Ne za jine.

Kdo to kritizuje ten se v tom nevyzna! My delame budoucnost!

To jsou stejny kecy jak od vyvojaru systemd, flatpaku apod.

Ale nic proti GraphQL - ty nikomu zadne problemy nezpusobuji, jen nauci par dalsich vyvojaru proc je blbost skakat na kazdy bandwagon.

Přesně tak. Z těch super, hyper, duper, extra, speciál moderních frikulínských technologií přežije možná tak jedna z tisíce.

Já sám už jsem sarkastický. Když vidím, jak houfy nedomyšlených (a většinou i nedokončených) softwarových technologií skákají čím rychleji. Často ty technologie ani nedokáží říci, proč by se měly používat. A často z nich přímo čiší, že jsou spíše překážející. V poslední době už se obhajují softwarové technologie jen tím, že to používá facebook nebo google.

Mnoho z těch nepostradatelných technologií za pát let ani neuvidíte. GraphQL bude jednou z nich.

s tim rustem se ale vlastne nemylil, krome mozilly ktera ho tlaci je to par malych projektiku

V roce 2016 jsem napsal - tuším pod článkem Tišnovského -, že za pár let po Dartu a Rustu ani pes neštěkne. Nevím co svědčí pro to, že by to byly růzkvétající se a virově se rozšířující projekty.

Rust se teď snaží, jako chcípající kobylu, adaptovat Mozilla, a pár dalších projektů.

Nevidím ty tisíce projektů psaných v Dartu a Rustu, kde jejich počet exponenciálně stoupá každý rokem, ba každým měsícem.

Dokonce už i dávno zastaralý a vymřelý COBOL má více projektů, které jsou v něm napsány a dodnes jedou, než 8 let nový moderní, prosperující Dart či Rust.

Já sice moc nechápu, proč Ondra Satai Nekola se snaží silou mocí dokázat, že žije v matrix mimo realitu. Navíc nechápe základní matematické operace.

Růst (tedy součin) má tu geniální vlastnost, kterou vám popíši na příkladě:

a) Když má Pepa roce 2016 1 Kč, a v roce 2017 2 Kč = Pepa má úžasný růst o 100 % neboli na dvojnásobek.

b) Když má Karel v roce 2016 - 1 miliardu Kč, a v roce 2017 zase 1 miliardu Kč = žádný růst, špatný výsledek.

Podle Ondry Satai Nekoly a jeho kreativních ukazatelů je na tom Pepa ekonomicky skvěle, a má daleko lepší ekonomickou budoucnost, než ten nekňuba Karel, který nerostl.

Jsem zvědav, co za ptákoviny, hlouposti a nesmysly ještě Ondra Satai Nekola vymyslí - aby si vylhal, že Rust je na tom dobře.

Takže když Ondra Satai Nekola nemá už čím argumentovat poté, co si neosudně vycucal z prostu úžasný rozvoj Rustu, už došlo na útoky ad hominem. Smutný to závěr. Děkuji, že jste mi dal úplně za pravdu, že Rust umírá.

A v roce 2009 jsi napsal, ze nVidia do 3 let zkrachuje. Takze asi tolik k predvidani budoucnosti...

@deda.jabko

:-D :-D ale jednou mu to vyjde ... :-D

Možná pro ilustraci. Pan Tišnovský a další přemýšleli, který jazyk nahradí C/C++, a tipoval nejvíce Rust. Já ve stejné diskusi napsal, že Rust umře, a jediná náhrada Céčka, která má budoucnost je Céčko a pak C++. Docela rád bych se dozvěděl, v čem mi ta předpověď nevyšla.

https://www.root.cz/clanky/programovaci-jazyk-rust-nahrada-c-nebo-slepa-cesta/nazory/894038/

https://www.root.cz/clanky/programovaci-jazyk-rust-nahrada-c-nebo-slepa-cesta/nazory/894157/

Zatím se mi zdá, že Ondra Satai Nekola má těžkou poruchu vnímání reality. C a C++ jede znovu na výsluní, zejména kvůli embedded věcem. Rust chcípá, a navíc za 8 let nestačil ani zavést pořádný standard, v každé verzi je jazyk překopán. Počet projektů v Rustu je na hranici statistické chyby. Což je o to více svědčící pro chcípání, že Rust propaguje dokonce veleznámá Mozilla, a stejně je to Rustu víceméně houby platné.

@Miloslav Ponkrác

Dart? Akorát ho používá další projekt, jinak nic > https://flutter.io/

Kolik projektů používá jazyk C/C++? Kolik projektů používá jazyk Python? Kolik projektů používá jazyk Java? Kolik projektů používá JavaScript? --- Milióny? Statisíce?

Vy tady musíte tahat z paty pár projektů, aby vůbec jste mohli dát příklad něčeho v Rustu. Takže už máme celé 2 projekty, a když budete procházet internet, najdete ještě několik. --- Kolik je to v porovnání s počtem projektů v jazycích C, C++, Java, Python, Ruby, JavaScript a dalších?

Kobyla Rustu chcípá, stěží mi vyjmenujete několik projektů, které Rust používají. Ty projekty stejně zaniknou, nebo za pár let přejdou na rozumnější programovací jazyk. Případně se z Rustu stane muzeální kousek ve smysly internal Mozilla only.

Zatím vše, co jste vyjmenovali nesvědčí zrovna pro překotný rozvoj Rustu, spíše pro chcípání Rustu.

@Miloslav Ponkrác

V těch jazycích bylo za tolik let napsáno tolik projektů které už se nikdy nezmění, že i teď v Rustu začali psát všichni cšechno, tal budeš moci svou "úvahu" podkládat počtem projektů v .... ještě 10 let ....

Tím netvrdím že Rust nějak jede nebo nejede, jenom tvrdím že své úvahy podkládáš daty které o tom nemohou vypovídat.

Známe trend ale neznáme čísla které za tím trendem stojí. Ty ano? A pokud ano, jak můžeš trend argumentovat nějakým pohým statickým počtem v jednom bodě (dnes)?

Jsem na světě už nějaký pátek. V programování se pohybuji několik desetiletí. Kolik myslíte, že přežilo úžasných technologií, které měly změnit svět? Ty co přežily měly určité společné znaky: 1) Přinášly něco užitečného. 2) Někdo je masivně podporoval.

Když přišlo C - bylo to úžasná věc. Fungovalo to jako lepší assembler s tím, že se v něm programovalo asi 1000 x rychleji než v assembleru. Plus navíc to podporovala unixová komunita.

Když přišlo C++ - byla to úžasná věc. Něco co spojilo rychlost C s komfortem objektových jazyků. Protože C je opravdu jen ten lepší assembler. Navíc v C++ se vyvíjí rychleji než v C, a díky namespacům, objektům a pár dalším věcem se lépe vyvíjí v týmu. 8 let (stáří Rustu) od objevení se první verze C++ (tedy C s objekty) 1985 už v tom byl obrovský počet projektů. Já sám jsem už v roce 1993 několik let programoval v C++.

Když přišla Java - tlačil to obrovským způsobem Sun. Nalil do toho snad miliardy dolarů (a také možná proto zkrachoval). Nabídl přenositelnost, applety, mobilní vývoj, později enterprise, atd.

Další náhradou/alter­nativou C je Objective C, který se udržel kvůli Apple. A mimo Apple je jeho rozšíření na hranici statistické chyby.

=== Všimněte si, že zatímco prosadit první náhradu C, totiž C++, bylo relativně levné. Prosadit druhou náhradu C/C++, totiž Javu, bylo už pro Sun velice velice drahé. Prosadit třetí náhradu C/C++, třeba Rust - už bude stát zhruba celý Rotschildův majetek, aby se to podařilo. ===

Teď se vyrojila obrovská spousta projektů, které mají nahradit C. Jen těch náhrad C už je tolik, že NEEXISTUJE ŽÁDNÁ REÁLNÁ POTŘEBA po náhradě C. Prostor pro další jazyk Céčkového typu s Céčkovou syntaxí (třeba Rust) je minimální, ne-li nulový. Ten jazyk by musel být virtuózní dílo od génia jakých se rodí jeden za sto tisíc let. Zároveň bude třeba lít neskutečné peníze do rozvoje jazyka: udržování kompilátorů, napsání standardů, propagace, rozvoje, a mít tah na branku po minimálně 10-15 roků. Ta šance je prakticky skoro rovná nula.

Teď byla Mozilla a její peníze zneužity na propagaci a podporu Rustu. Ty peníze budou vyhozené do WC. To, že PRÁVĚ TEĎ se mluví o Rustu jako o život je příznačné pro dnešek. Právě teď se mluví o úžasném GraphQL, a za pár měsíců se zase bude mluvit o úžasném něčem jiném. Moderní doba přináší velký peek zájmu, aby za chvíli po tom ani pes neštěkl. A právě teď se Rust snaží o ten peek, poslední vrchol před jeho smrtí. Ty nové, úžasné tehcnologie se střídají rychleji než ponožky - a mají také podle toho životnost.

Vsetko splnuje C# uz 5 rokov

Céčko by se nahradit mělo. Nicméně pokud jazyk nebude skvěle postavený se vším co píšete tak, aby se vyplatilo investovat do přechodu z C na lepší jazyk - tak to neprojde.

A Rust upřímně řečeno žádný zázrak není. To není ten jazyk, který převálcuje C.

Mimochodem, znáte programovací jazyk Chapel?

https://chapel-lang.org/

Řekl bych, že je to mnohonásobně povedenější náhrada C pro paralelní programování, než všechny ty hipster jazyky jako Rust, apod.

@Miloslav Ponkrác

Já ti to neberu. Jenom ti říkám že své tvrzení o trendu podkládáš daty ze kterých trend nevychází. Což sice nevylučuje to že máš pravdu, a to mě ani tak moc nezajímá, ale podkládáš závěr špatnými daty. Přestože jsi takový zkušený pamětník tak ti navrhnu dvě řešení s ohledem na to že přestat plácat není volba: Buď si opatři správná data a nebo to prezentuj jako názor, bez dat.

Já tu ale nedělám vědecké studie, ani nedělám podklady pro znalecký posudek. Ani vy, ani nikdo jiný mě nebude platit za práci, kdy budu věnovat x hodin přesným datům. Já pouze diskutuji v diskusi. To si trochu pletete místo určení a styl komunikace.

Budoucnost má navíc tu povahu, že jí neodvodíte z číselných ukazatelů dneška. Můžete jí odhadnout pouze z úvah a trendů. Napsal jsem, proč Rust nemá budoucnost.

1) Navíc v okamžiku, kdy protistrana s veškerou snanou vyškrábne po veškerém možném úsilí, že v Rustu byly udělané celé DVA PROJEKTY, slovy POUHÉ DVA PROJEKTY (já sám vím ještě o pár dalších v Rustu, ale to nic na věci nemění) - a vydává to za úspěch a skvělou budoucnost Rustu - tak vidím, že hovořím s lidmi bez soudnosti a střízlivého vidění.

2) Dozvěděl jsem se, že počet keců o Rustu a příspěvků k Rustu rostl za rok 1,7 krát! Tý bájo! Až na ten základ tedy.

Závěr: Přesvědčovat někoho, kdo je zaslepený? Proč?

Když pan Tišnovský plácal nesmysly o tom, jak nahradí Rust Céčko - nikdo po něm fakta a data nechtěl. Po mně se chce snad abych dodal tisícistránkou studii či co?

Já jsem pouze reagoval na to, že jsem v roce 2016 napsal, že Rust umře za pár let. Přičemž "pár let" znamená v lidské řeči "za několik let - není určeno přesně kolik". A moje křišťálová koule stále funguje správně. Počkejte si a uvidíte.

@Miloslav Ponkrác

Nikdo po tobě studie nechce. Jaký je ale účel diskuze ve které něco tvrdíš o trendu a podkládáš to počty jiných jazyků v jednom časovém bodu?
Tak sem hoď počet projektů v Rustu 2015 - 2018 ať vidíme z jakého trendu teda vycházíš a je po celém problému - nemusíš, no pak se ale nediv že se ti někdo směje ...

Vycházím z toho, že Rust je naprosto zbytečný plonkový jazyk, který neplní žádnou užitečnou funkci. To, že je dočasně tažen uměle Mozillou mu DOČASNĚ na chvíli pomůže, to je všechno.

Budoucnost se nedá určit trendy. Tak prostě budoucnost nefunguje. Kdybyste dělali předpověď budoucnosti Třetí říše na počátku 1942 podle trendů, muselo by vám jasně vyjít extrapolací, že nacisté do pár let zaberou celý Sovětský svaz a Třetí říše se bude rozkládat na několika kontinentech.

Udržet programovací jazyk dlouhodobě naživu je obrovská práce, která. Zatímco u API typu GraphQL stačí v podstatě napsat pár specifikací, prosadit programovací jazyk je běh na dlouhou trať. A stojí to hodně peněz.

1) Co má Rust tak jedinečného a speciálního za killer funkci, aby se prosadil v nějaké nice? Killer funkci, která by mu dovolila excelovat v nějaké oblasti, a nebýt jen stodvacátousedmou kopií podobného programovacího jazyka jen s mírně jinou syntaxí?

2) Za 8 let od představení - kdybych věřil této diskusi - to Rust dotáhl na celé 2 projekty (+ nějaké další zde nezmíněné)! Na víc si tu nikdo nevzpomněl. To je nepopiratelná známka prudkého rozšíření Rustu, a trendu ovládnout svět. (Za stejnou dobu mělo C nebo C++ nebo Python desetitisíce projektů.)

3) Rust existuje už 12 let, Moziila do Rustu leje peníze už 9 let. V porovnání s jinými jazyky nic moc výsledek za ten čas.

4) Příliš jsem nepochopil cíl Rustu. Dokonce ani po přečtení FAQ na jejich stránkách. Na jedné straně chtějí rychlost, dokonce tím zdůvodňují i větší nenažranost datových struktur. Na druhé straně si stringy nacpou v UTF-8, takže stringové operace jsou pomalé jako prase. Nepodpora výjimek určitě zvýší ochotu lidí používat Rust (sarkasmus).
Objekty jsou taky taková podivná splácanina - dalo by se o tom psát hodiny.

5) Vývojem mi Rust připomíná PHP. Každá další verze je dokonale nekompatibilní s předchozí. Když budete hledat na internetu odpovědi na problémy s Rustem, nebudou vám většinou fungovat, protože to fungovalo v jiné verzi. Na to, že je na světě 12 let. Určitě to prospěje rozšíření Rustu (sarkasmus).

6) Rust míří na low level - tedy na systémové programování. Tam už je C a C++ a několik dalších jazyků. Rust míří někam mezi ně. Je lepší než C, ale neumí - a podle FAQ a cílů projektu - nikdy nebude umět tu šíři věcí, co C++. Kde je ty oblast, kde by měl Rust excelovat?

7) V Rustu se skoro nic nepovedlo, všechno je to taková divná směsice. Stringy jsou v UTF-8, objekty jsou poněkud divné, atd.

Pro Rust jednoduše není místo na světě. Rust sám neví, čím by vlastně chtěl být, kam patřit a co umět. Zkouší to jako Pat a Mat neustále všechno překopávat, nikam naplno nemířit.

https://www.rust-lang.org/en-US/faq.html

@Miloslav Ponkrác

Mysli si co chceš, já ti to neberu, jenom jako argumenty neuváděj nesouvisející data ...

a tohle "Vývojem mi Rust připomíná PHP. Každá další verze je dokonale nekompatibilní s předchozí." je naprostá hloupost. Nechápu proč máš potřebu do svých tvrzení zatahovat ještě další, nota bene hlouposti ...

Ano, dnešní webové MVC se liší především tím, že to není psáno ve Smalltalku. :-) MVC je především architekturní vzor, nic jiného.

Doufam ze ste v tom smalltalku aspon neco napsal, ale popravde nepripada mi to tak... jen mate neco nacteny z wikipedie.

Ještě mám doma image 3,5" diskety, která se bootovala do PC jako operační systém. Ten operační systém se jmenoval Smalltalk, a potřeboval alespoň 286. Na jediné 3,5" disketě (1,44 MB) se vešel celý bootstap včetně celého Smalltalku. A nebylo to odbyté, umělo to samozřejmě GUI, a také preemptivní multitasking.

Jediný rozdíl mezi Smalltalkem a dnešní jazyky je ten, že Smalltalk byl čistě navržený a čistě objektový. Dědičnost v něm neznamenala typovou informaci, ale pouze znovupoužití kódu. Systém zpráv funguje skoro i s chlupama jako v Objective C od Apple.

MVC je architektonický vzor. Není to žádný přesně daný pattern (proto můžete napsat bazilión článků, co přesně je a co není MVC). Nicméně ten princip funguje stejně tehdy i dnes.

Ano, proto vsechno co je architektonicky vzor oznacite za mvc, coz tu je jiz od dob smalltalku -- jen se snazite kalet na lidi co neco zkousej, holt v js ... kazdy nema ten luxus psat ve smalltalku na frontendu. Jinak zkuste Amber nebo Pharo pametniku.

Nějaký argument by nebyl? Napsal jste jen slovní vatu bez jakékoli informace.