Příspěvky

376

Vývoj / Re:Je Swagger utter crap?

« kdy: 07. 04. 2019, 16:51:04 »

Zaprve, kdyz se to WSDL vygeneruje automaticky na zaklade XSD schematu, tak by si s tim snad melo poradit PHP pri generovani clienta.

Mělo. Podmiňovací způsob je na místě.

Co mě ale zaráží víc, je (opakované) tvrzení že WSDL se generuje automaticky na základě XSD schématu. Což je naprostý nesmysl - WSDL obsahuje XSD pro definici typů, ale obsahuje i spoustu dalších informací které v XSD nejsou. Viděl jsi WSDL vůbec někdy?

A to ani nemluvím o WSDL 1.1, které se pokud vím stále ještě leckde vyskytuje.

Zadruhe kdyz si s tim neporadi, tak je to uplne jedno, protoze jako predloha stejne slouzi to XSD schema - to je v podstate primarni human readble API te aplikace - a s tim uz si snad musi poradit PHP nebo programator, aby si na zaklade schematu udelal request. Zatreti, kdyz si ani s timto neporadi, tak at de dozadeke, radeji nekde na salas past ovce.

Ano, tak to také dopadne. A pak si někdo vzpomene, že se použije pro WS-Security pro zabezpečení...

Omg co to zas je za kec, jake tuny sracek, posilas jen XMLko s daty, oproti XSD schematu se to jen validuje. Muzes to poslat i jako JSON.

SOAP přes JSON? Tak to jsem ještě neslyšel. Což se může stát, novinky nesleduji, možná komise vytvořila nové monstrum, nebylo by to poprvé. Na druhou stranu, uvážím-li kvalitu ostatních informací, může to být jen blábol.

Takže: Můžeš sem dát odkaz na specifikaci?

XSD schematem si definuju, jak ma vypadat API, tzn. jake maji mit nazvy metody, a podle nazvu souboru toho xsd si definuju i tridy metod. Potom si z XSD vygeneruju Java classy. Ve Springu muzu nyni pouzit budto dle JAX-RS nebo JAX-WS udelam enpoint tridy, ktere cti jmennou konvenci definovnou tim XSD.

Pokud pouziju JAX-WS, tak na zaklade tech trid mi umi Spring automaticky vygenerovat i WSDL soubory. Pokud ale volam jinou komponentu, tak me jeji WSDL vubec nezajima - k tomu abych si ji zavolal potrebuju znat jen 2 veci: url a XSD schema.

Proto rikam, ze XSD me slouzi jako API komponenty, nepotrebuju na to pitomy Swagger. Mam z XSD vygenerovane Javovoske tridy a na zaklade jejich jmen a popisu vim, co je to za metody, treba hned vim, co bude delat: com.xsdforever.violence.DeleteSwaggerFromGalaxy.java

Pokud ale pouzije JAX-RS pro endpoint a udelam to jako rpc, tak muzu porad pouzit XSD jako predlohu, nacez muzu samozrejme pak posilat i JSON zpravy - na tom nesejde, protoze JSON se da validovat oproti XSD.

377

Vývoj / Re:Je Swagger utter crap?

« kdy: 06. 04. 2019, 23:29:25 »

To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?

Když je něco pod povrchem fuj, tak se to časem projeví. Konkrétně sprasené WSDL nemusí fungovat v háklivějších klientech, např. v PHP. Pak se to narovnávákem na ohejbák nějak rozchodí, ale radost ani dobrá vizitka to není...

Zaprve, kdyz se to WSDL vygeneruje automaticky na zaklade XSD schematu, tak by si s tim snad melo poradit PHP pri generovani clienta. Zadruhe kdyz si s tim neporadi, tak je to uplne jedno, protoze jako predloha stejne slouzi to XSD schema - to je v podstate primarni human readble API te aplikace - a s tim uz si snad musi poradit PHP nebo programator, aby si na zaklade schematu udelal request. Zatreti, kdyz si ani s timto neporadi, tak at de dozadeke, radeji nekde na salas past ovce.

378

Vývoj / Re:Je Swagger utter crap?

« kdy: 06. 04. 2019, 23:23:56 »

Standa Blabol:

Co je spatneho na WSDL co ma include XSD a dalsi a dalsi? To WSDL se prece da vygenerovat na zaklade XSD schematu. Ty ho pak pouzijes pro SOAP UI nebo pro vygenerovani Clienta.

kdyz ti nevadi, ze zbytecne posilas tuny sracek. Treba u mobilnich aplikace to muze vadit.

To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?

jen dokud vse funguje.

Omg co to zas je za kec, jake tuny sracek, posilas jen XMLko s daty, oproti XSD schematu se to jen validuje. Muzes to poslat i jako JSON.

379

Vývoj / Re:Je Swagger utter crap?

« kdy: 05. 04. 2019, 07:58:36 »

Standa Blabol:

Co je spatneho na WSDL co ma include XSD a dalsi a dalsi? To WSDL se prece da vygenerovat na zaklade XSD schematu. Ty ho pak pouzijes pro SOAP UI nebo pro vygenerovani Clienta. To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?

380

Vývoj / Re:Je Swagger utter crap?

« kdy: 04. 04. 2019, 20:06:32 »

A ted jak je to v realite.
Prijdu u zakaznika k jeho SOAP service.
Totalni chaos a bordel, veschny atributy vystaveny nako optional String. Beda ale kdyz onen optional string nevyplnim, vrati se mi SOAP exception s payload "Eror-11355 - Bus error".

Dostanu WSDL, pro ktery si mam vygenerovat skeleton. Vsechny datove polozky se jmenujou "data" a pouzivanji WSDL s indcludouvanym XSD, co ma includovany XSD, co ma includovany XSD. Nejlepe nejaky business celofiremni header, co odkazuje na nejake dalsi XSD, nejlepe tak kouzelne provazano, ze cely balik provazanych XSD ma 30 mega, vsechno kolem toho chodi a boji se do toho sahnout.
Pak udelam zakladni jednoduchy Spring client, ktery si vzdy na zacatku vyrobi z WSDL skeleton callu, springovi pak trva priprava na kazdy WS call 4 sekundy na 8jadrovem serveru. Tak si jak u blbejch implementuju pool predpripravenych clientu a reusuju.
Konkretne onen 30MB bulk mej i tu vlastnost, ze jediny, kdo byl schopen pro to vygenerovat skeleton byl priohly SpringWS za pouziti wsimport, JAXB nelepil vubec, ten lehl rovnou pri generovani.

Pak prijde pozadavek za zabezpeceni. Mrknu se na WSsecurity extenze a zjistim, ze tohle narhoval naprosty magor. Ze jakmu jsem si nasel autory navrhu, tri panove ze Microsoftu/Sunu/Ericssonu. Napriklad existuje 7 zpusobu predavabi verejneho klice, koncept je tak brutalne slozity, ze prakticky neexistuje plna implementace vseho.
Finalne po cca mesici prace (nedelam si zadek) se "zabezpecene" pripojim, request ma celkem 7 KB z toho payload je jeden bajt "0" nebo "1".

Vse co popisuju jsem realne zazil a ty systemy stale "funguji".

SOAP je v realnem pouziti prekomplikovany shit a proto taky vsechny softy co znam vystavujou API na REST nebo XML-RPC.

Tak. A je to tu. A tohle je urcite duvod k tomu, proc pouzivat REST. Ze to nekdo zprasil. Ti sami lidi zprasi i ten REST!

381

Vývoj / Re:Je Swagger utter crap?

« kdy: 03. 04. 2019, 23:21:38 »

A co se tyce toho Swaggeru, tak to v podstate stejne ani nepotrebuju. Kdyz si udelam vhodne XSD soubory, ktere udelam 1:1 ve stylu

jmeno souboru : jmeno tridy (interfacu)
jmeno requestu : jmeno metody
jmena atributu requestu : jmena parametru metody

Tak mam timto jasne definovane API. Jediny problem je, ze toto vyzaduje alespon nejakou minimalni disciplinu a domluvu, a te proste NEJSOU PROGRAMATORI schopni.

382

Vývoj / Re:Je Swagger utter crap?

« kdy: 03. 04. 2019, 23:02:47 »

Zaprve je treba si ujasnit, proc chceme dat pryc SOAP. Z meho uhlu pohledu jediny rozumny duvod ktery jsem slysel je, ze se to blbe pouziva treba prave javascriptarum.

Podle me je SOAP v principu genialni a nikdo nevymysli nic lepsiho - tehda moc dobre vymysleli, jak mezi sebou maji backend komponenty komunikovat. SOAP ktery je zalozeny na RPC vlastne vytvari pro programatora ten use case, ze programator jakoby vola metodu v jine komponente a to volani je nezavisle na pouzite platforme.

SOAP zprava prenasena v HTTP je vzdycky POST - vsechny dalsi http metody jsou redundantni. V body se prenasi objekt, jehoz jmeno reprezentuje jmeno metody. Pro rozliseni ma zpravidla postfix "Request". Jeho atributy predstavuji 1:1 parametry metody. A to je v principu co se tyce RPC vsechno - nic vic neni potreba. je zde kompletni, osekana, takrka 1:1 vazba mezi SOAP zpravou a volanou metodou. To co je v REST API delanem jako Resource jsou akorat reduntantni nesmysly:
- HTTP metody - nanic
- path variables - nanic
- jenom jeden mozny request body - nanic
- url parametry - nanic

Je to uplne k nicemu, redundatni nesmysly, ktery oceni tak leda programatory typu impresionisticky umelec, ktery se minul povolanim.

Proc volani mezi komponentami je RPC a resource je nanic? Protoze my takrka vsichni programatori delame v proceduralnim paradigmatu - nepotrebujeme mit jedno paradigma pro programovy kod a jine paradigma pro komunikaci se vzdalenymi komponentami. A nevsiml jsem si, ze by mezi programatorama byl takovy prehrsel borcu, co maji vsechno v maliku, a zvladnou mit v pouzitych technologiich gulas, plny redundtnich kravin. Je to prave naopak.

At uz je programator zalozeny vice OOP nebo vice proceduralne, tak komponenty predstavuji objekty, ktere si mezi sebou posilaji zpravy (volanim metod) uplne stejne, jako kdyz volame v ramci kompinenty nejakou service. Neni tam zadny duvod pouzivat Resource API.

Nevim cim nahradit Swagger API, ale SOAP je v principu pekne a jendoduse nahraditelny a uz jsem to videl:

V prve rade se pouzije uplne stejny princip, jaky pouziva SOAP, protoze nikdo nic lepsiho nevymysli. Pouzije se REST, API se modeluje pomoci XSD, uplatni se uplne stejne pravidla jako ma SOAP:
- vsechny HTTP requesty jsou POST
- sere se z vysoka na path variables a jine kraviny, je tam jen body
- body je XMLko nebo JSON, je to jedno, jeho jmeno predstavuje jmeno metody a atributy jsou 1:1 parametry jakoby parametry metody
- jako bonus se uz zezacatku mysli na zpetnou kompatibilitu pro Response, aby se porad nemuselo verzovat API. K tomu slouzi v XSD tag "<xsd:any ... >" do ktereho se pri prekladu Response na Java objekt nastrkaji do Listu ty atributy, pro ktere se nepodarilo najit zadny konkretni element pro namapovani - takze kdyz se do Response nekdy prida dalsi atribut, tak kvuli tomu nezacnou okolni komponenty padat na hubu.

Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.

383

Vývoj / Je Swagger utter crap?

« kdy: 03. 04. 2019, 16:37:42 »

Jsem jediny komu prijde absurdni, ze se i v enterprise informacnich systemech zacina rozmahat pouzivani Swaggeru na modelovani API pro komponenty, ktere potrebuji mit API jako RPC a ne jako Resource?

Tahle technologie, u ktere spolecnost co za ni stoji mela tu drzost ji pojmenovat jako OpenAPI, je utter crap.

Maly skok do historie. REST byl vyvinuty jako soucast HTTP v roce 1990 a je urcen pro modelovani webovych api typu Resource, tzn. webovka ma nejaky svuj backend, ze ktereho si potrebuje tahat data, zapisovat, updatovat atd. Je to neco designem dost spjateho s HTML, ktere se prenasi pres HTTP v RequestBody at uz pri GET, nebo kdyz se odesila nejaky formular, nebo co ja vim.

Dneska se za valecneho pokriku prumernych opic vyvojaru vytlacuje z backendu SOAP, nadavajic na to, jak je neflexibilni, pricemz se to nahrazuje necim tak naprosto nevhodnym, jako je Swagger api a rest. Samotny REST neni az zase tak problem, i SOAP se prenasi pres HTTP kde metoda je vzdy POST, problem je az teprve Swagger.

Backendove komponenty mezi sebou potrebuji delat RPC volani a ne si vzajemne sahat do Resource. Pouzitim Swaggeru, ktery je RPC dost unfriendly a nuti do Resource, vznikaji totoalni narovnavaky na ohybaky, protoze korporatni vyvojari jsou zmateni, nevi co to RPC vlastne vubec znamena a vo co go, a implementace Swaggeru je mystifikuje do tvorby kockopsa mezi RPC a Resource API. Swagger je navede na to, aby delali Resource API (vetsina ani nevi, co to je), jenze to jim v drtive vetsine pripadu nepasuje na to, co potrebuji delat, coz vsak vedome nevi, takze do toho michaji RPC az nakonec vznkne naprostgo zpackane gulas API.

Kdyz se k tomu prida zaklinadlo OpenAPI a prihodi se rvouci opico-ovce, tak z toho je dalsi jedna velka vyvojarska tragedie, ktera zase pro jednou vede k horsimu a zpackanejsimu backendu.

Clovek by rekl, ze by se mela metodologie vyvoje hybat dopredu, a ne dozadu a jeste dal.

Prohlasuju, ze kvuli Swaggeru se enteprise dostal z roku 2019 nekde do stavu vyvoje API pred rokem 2000, nez byl vymyslen SOAP. A to jsem jeste nemluvil o nahrazovani XMLek jinymi, "lepsimi" formaty.

Docela by me zajimal nazor mistnich.

384

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 18:46:15 »

Jeste jsem chtel rict, ze hodne lidi vidi budoucnost v tom, ze se do jazyku pridavaji nove featury (treba streamy) a ze to je ten svaty gral, jak se to pohne dopredu a bude lip. Ja s tim zasadne nesouhlasim, myslim si, ze budoucnost je praveze jinde, je v osekavani zbytecnych veci, tak jak to dela Go. Myslim si, ze tento pristup do budoucna vyhraje.

385

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 18:36:04 »

A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.

Co je to za nesmysl? Používáte buď Gradle, nebo Maven, nebo Ant, nebo třeba Ivy. Všechno jsou to systémy pro sestavení aplikace a budete je používat i kdybyste měl závislost jenom na JDK.

Ty nevis, jak to v enterprsise enviromentech chodi? Chodi to tak, ze budes pouzivat vsechny 3. Protoze jeden frajer pouzije Maven, druhy na sousedni komponente si mysli, ze Maven je moc oldschool tak pouzije Gradle, a treti si mysli ze Maven a Gradle na to jdou moc slozite a pouzije Ant nebo Ivy. Vsechny ty 3(4) pripady maji jednoho spolecneho predchudce - bordel v Jave, kde existuje hromada nic moc externich knihoven delajicich plus minus jedno a to same, protoze v zakladnim JDK na to serou a neudelali tam hromadu veci poradne.

V .NETu proste pouzijes vzdycky Nuget a to jeste ne vzdycky, protoze dost casto si vystaics s vecma co uz v .NETu jsou.

Uz jsem tu s tebou diskuzi v tomto stylu vedl v minulosti a neminim to delat znova, protoze to nema smysl, protoze ty mas proste problem pochopit takoveto nuance. Ty jsi technik typu knihomol, co ma hromadu veci nastudovane zpameti, ale davat si to do souvislosti trochu vice do siroka nezvladas. Nehlede na to ze diskuze s tebou na tema Java bude vzdycky stret zajmu, protoze ty jsi skolitel Java technologii a ke vsemu tu vystupujes pod svym vlastnim jmenem - takze asi tezko bys prohlasil na Internetu ze to co je v jave je proste sracka a to ikdyby sis to myslel.


Ad Micronaut - diky za tip, asi se na to nekdy podivam, nicmene prijde mi, ze uz se tu pres sebe v Jave placa pate pres devate, ani na GraalVM uz jsem se nedival, protoze v tom nevidim realne budoucnost. Podle me proste Java je uz zahraba v moc velkem bordelu a ja neverim tomu, ze to rozdycha. A nejak pochybuju, ze to zachrani Kotlin. Takovou vec proste musi mit nejaka spolecnost pod zastitou a valit do toho penize, protoze jinak to bude vypadat jako Java nebo jeste hur jako JS platforma (mysleno na stupnici srackoidity komunitnich vyrobku). Mimochodem at GraalVM tak Micronout tak cokoliv si neumim predstavit, ze by se nasazovalo tam, kde je Java doma - v korporacich. O duvod min pro me proc se o to zajimat.

Go na to jde dobre a od podlahy tim, ze osekava zbytecne veci, z OOP si nechal jen to co je opravdu uzitecne (polymorfismus pres interfacy) programy jsou rychle a malinke, ma komunitu co nebude chtit pridavat do jazyka kdejakou zbytecnou kravinu, atp.

Uz se tesim, az tato nova generace jazyku zacne vytlacovat Javu pryc. (jeste to dlouho potrva)

386

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 15:29:32 »

A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.

Ja se ptam, kdyz nekomu prijde Spring moc velky overhead pro jeho aplikaci, tak v cem jinem to ma potom fidlat? (Doufam ze tu nejaky debil nenapise ze mam zkusit Play Framework a Scalu) O cehokoliv jineho nez Springu si uz budu klast otazku, jestli si ten backend nemam rovnou udelat v Node.js - protoze frontend uz asi dneska tezko budu fidlat na backendu a tak proste rovnou udelam i ten backend javascriptovy. A u veci slozitejsich uz se zase dobre hodi ten Spring, protoze ten overhead se ztrati.

Za me, Java se proste bohuzel nehodi na mensi veci, nez na ktere uz je vhodny Spring. Si myslim. Schvalne uvedte nejaky jiny priklad z praxe.

Jo a mluvim o vyvoji inf. systemu, stejne se dneska skoro nic jineho nedela.

Uvediem dva aktualne prilady z mojej praxe:
1) vyvoj nativnych rychlych command line toolov s minimom zavislosti na dynamickych knizniciach tretich stran v systeme
2) vyvoj nativnych mockovanych REST serverov s okamzitym startom a sub milisekundovym response time

Jak to udelas v Jave nativne?

387

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 10:10:55 »

A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.

Ja se ptam, kdyz nekomu prijde Spring moc velky overhead pro jeho aplikaci, tak v cem jinem to ma potom fidlat? (Doufam ze tu nejaky debil nenapise ze mam zkusit Play Framework a Scalu) O cehokoliv jineho nez Springu si uz budu klast otazku, jestli si ten backend nemam rovnou udelat v Node.js - protoze frontend uz asi dneska tezko budu fidlat na backendu a tak proste rovnou udelam i ten backend javascriptovy. A u veci slozitejsich uz se zase dobre hodi ten Spring, protoze ten overhead se ztrati.

Za me, Java se proste bohuzel nehodi na mensi veci, nez na ktere uz je vhodny Spring. Si myslim. Schvalne uvedte nejaky jiny priklad z praxe.

Jo a mluvim o vyvoji inf. systemu, stejne se dneska skoro nic jineho nedela.

388

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 09:30:48 »

.NET je uz daleko pred JAVOU. Nakolko sa rozbieha v plnej krase .NET Core, je dost mozne, ze JAVA bude pomalicky vytlacana aj z miest, kde prevlada JAVA.

.NET je pred Javou, ale .NETisti ne, chlapce. A o tom jestli .NET stihne Javu prevalcovat bych se hadal, protoze Windows a MS veci jsou utter crap a dokud nebude .NET plne nezavisly na Win, coz se podle me nikdy nestane, tak ma utrum.

389

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 09:16:45 »

Tak a je to tu, pan Jirsak zde dal opet erudovanou odpoved, ale pointu diskuze uz moc nepochopil, jak sam nekolikrat zminuje. Jak tradicni u pana Jirsaka. Ja jsem to treba pochopil a myslim si, ze mnozi dalsi taky, pane Jirsaku.

Tazatele stve overhead frameworku a importovani hromady externich knihoven, klade si spravnou otazku, proc se neda vystacit se zakladnimi vecmi, ktere poskytuje Java. Normalni jeste zdravy clovek si totiz kladu otazku, proc se neco dela slozite, kdyz to jde jednoduse.

No v Jave to bohuzel moc dobre nejde a to kvuli tomu, ze zakladni knihovna nedisponuje dostatecne kvalitne udelanymi vecmi. Pokud nekdo nevi jak to myslim, tak at se podiva jak to maji vsechno pekne vyresene v .NETu. Tak by to melo vypadat, kdyz se majitel platformy o ni stara.

Ja treba pridam jeste naprosto vtipny Unzip v JDK, ktery nejenom ze je pomaly jako snek, ale jeste navic v podstate zcela znemozni odzipovavat vnorene zipy kompletne v pameti - mezirozbalovacky se musi vzdycky ukladat na hdd.

390

Vývoj / Re:Ako komplikovane programujete?

« kdy: 25. 03. 2019, 08:16:35 »

Protoze se snazi prodat co nejvice lidi zakaznikovi jednak, a taky mit nejakou redundanci lidi. Jestli delas v korporatu a vadi ti tohleto, tak je pritlac ke zdi at te daji na jiny projekt kde toto neni - kazdy korporat ma dobre a i horsi projekty. Jestli ti nekde dali zbytecne 10 lidi tak si tipnu, ze to aroven bude solidni zumpa, kdyz i zakaznik je tak blby ze si tohle necha libit.