Tak asi takto, než byl obyčejný Rest, tak byly Webservicy. Webservicy, byly většinou SOAP, tedy XML a spousta definic (WSDL, XSLT). Webservicy byly dokonalé - dalo se v nich popsat snad všechno, ale stejně pro obecné použití umřely a přežívají jen někde v "korporátech".
Proč?
Protože byly složité a byla tu alternativa!
Proč se neujme GraphQL?
Protože je složité a je tu alternativa!
Samozřejmě, jako u všeho, nějakou dobu to budou koumáci (třebas páně Zlámal) tlačit na běžné programátory, ale po čase to vzdají.
Mezi tím přijde někdo s něčím jednoduchým (třeba nějaká odnož gRPC), co lidé pochopí během hodinky, co staví na tom, co už znají a problém je vyřešen a jde se dál.
GraphQL je hlavne vymsel od brucha, ignoruje zabehnute standardy a vyslelo si vlastny dopytovaci jazyk (ktory vzdialene pripomina JSON), tiez jeho implementacie nie su moc bezpecne.
Keby nebol taky hype okolo Facebooku a Reactu, tak by po tom nik nestekol.
Ale nebojte, za rok za dva uvidime cupser clanky "GraphQL je mrtve nech zije XY".
Hlavne ked sa nedokazal ujat ani JSON RPC.
Je vidět, že naprosto netušíš, o čem mluvíš a proč se GraphQL tak rychle rozšířilo. GraphQL se žádných "zavedených standardů" držet nemohlo, neboť žádný podobně mocný nástroj prostě neexistoval (*).
Síla GraphQL není v nějakém hype, ale v jeho možnostech pro formulaci toho, jak chceš jako klient vrátit odpověď. Doteď když jsi potřeboval zobrazit objekty z nějaké závislostní struktury (třeba seznam položek, z nich každá odkazuje na pět hodnot dynamického číselníku), tak jsi musel jedním voláním stáhnout ten seznam, pak ručně zjistit, které položky kterých číselníků potřebuješ a následně hezky postahovat ty položky vždy z každého číselníku zvlášť. Nebo na straně serveru předjímat, co bude klient potřebovat, vracet všechny položky číselníku už resolvované. Což ale byl v mnoha případech zase overkill. Natož když těch úrovní objektů je víc. Asi dvě aplikace jsem takhle psal a u složitějších struktur to byla hrozná pruda.
U GraphQL to zvládneš v pohodě jedním dotazem kde si klient sám řekne, co chce resolvovat (a co ne) a na straně serveru máš pro tenhle resolving podporu => naprogramovat je to docela easy.
*) Tedy krom deklarace typů ve schematu, tady mě dost štve, že nepřevzali třeba Typescript notaci (s malým rozšířením), ale vymysleli si vlastní syntaxi - je to dost matoucí, když se člověk musí přepínat.
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?
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->getWhatFieldsClientWants() 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í.
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.
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.
https://octoverse.github.com/projects
"Fastest growing languages
We’re seeing trends toward more statically typed languages focused on thread safety and interoperability: Kotlin, TypeScript, and Rust are growing fast this year.
In addition, the number of contributors writing HCL, a human readable language for DevOps, has more than doubled since 2017. Popular in machine learning projects, Python is at #8. And there are 1.5x more contributors writing Go this year than last year."
Meziroční růst na 1.7 násobek. Fakt umírá, věštče.
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.
A v roce 2009 jsi napsal, ze nVidia do 3 let zkrachuje. Takze asi tolik k predvidani budoucnosti...
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/alternativou 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.
No zrovna Cecko by nahradu sneslo, v dobe kdy vzniklo, se neresil problem, jak rozumne vyuzit 8 jader po dvou BigLittle bankach ruznych typu.
Neco podobne lehkeho, aby se v tom prajednoduse psaly paralelni programy (nebo aspon pipeline programy, kdy dilci pozadavek je postupne zpracovavan predavanim mezi paralelne bezicimi workery, aby se vyuzila jatra CPU paralelne)
Aby ty ty vlakna byly lehoucke a nemusela se pro vyssi throughput nasazovat ohavna Javascriptova async/await/callback onanie a mit k dispozici vzdy rozumny kontextovy stacktrace.
Aby to melo rozumny typovy system, klidne ducktyping nad polozkama structu, kde polozkou je i metoda.
Aspon nejakou ochranu public/private
Aby to melo rozumnou spravu pameti, staci jednoduchy garbage collector, nebo nedejboze pocitani referenci.
Aby to melo slusnou stdlib s rozumnyma collections.
Aby to umelo vyjimky.
Hodne nadeji jsem daval do GO (channely a gorutiny jsou luxus), ale tam stoji typy za vulizprdel, stdlib ma diry jaxvina, vyjimky neumime.
No snad se tvurci GO chytnou za rypak, byla by skoda to pohrbit, naslapnuto to ma pekne.
@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.
@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 ...
Klidně můžeš mít pravdu, ale byla by to velká škoda. Protože podle mého má Rust tyto killer featury (a ano, jsem si vědom že to trochu koliduje s tím, co píšeš).
1. Je to lowlevel jazyk. Je rychlý, úsporný, určený jako náhrada C.
2. Proti C má vymazlenou správu paměti bez GC.
3. Na rozdíl od C používá typy.
4. Nepoužívá objekty.
5. Nepoužívá výjimky.
6. Traity
7. Makra.
8. Je kompilovaný do binárky.
Ze všech jazyků, se kterými jsem se v poslední době setkal je to jazyk, kterému mám jen málo co vytknout. A pevně doufám, že nebudeš mět pravdu a udrží se.
Na GraphQL není naprosto vůbec nic složitého, je to primitivní.
Nicméně že by GraphQL bylo vymyšlené dobře se říci také nedá. Spíše bych řekl, že je to v kontextu celé prudce nedomyšlené, a hlavně včetně návazností.
Nedomyšlenost GraphQL a hlavně kontextu návazností a použití se poměrně brzy objeví. Pak GraphQL vyjde z módy, a přijde do módy zase jiný javascriptový nepodařený zmetek.