Rust - std::ANY alebo lepší návrh?

[Idris]

Jako dobrý, ale pořád mi přijde jednodušší sestavit SOAP klienta v těžce zastaralých systémech, než tam průkopnicky sestavovat gRPC klienta.

Pak je ale vůbec nesmysl “průkopnicky” nasazovat Rust

[Reklama]

[Rike]

Pak je ale vůbec nesmysl “průkopnicky” nasazovat Rust

No jo, chtěl jsem se sobecky naučit něco nového a nakonec jsem spadl do vlastní díry 

[Ink]

Pak je ale vůbec nesmysl “průkopnicky” nasazovat Rust

No jo, chtěl jsem se sobecky naučit něco nového a nakonec jsem spadl do vlastní díry 

Sobče, vzdělávat ses chtěl!

[Idris]

Pak je ale vůbec nesmysl “průkopnicky” nasazovat Rust

No jo, chtěl jsem se sobecky naučit něco nového a nakonec jsem spadl do vlastní díry 

Tak zrovna Rust má smysl se učit, i když ho nakonec člověk nepoužije. Ale nedá se čekat podpora obskurních obstarožních technologií. Já zrovna kdysi Rust na Windows použil, ale rozhraní bylo v C++/CLI (byla to komponenta pro .NET, ne COM). Rust umí vytvářet statické knihovny a dobře si rozumí s MSVC. Ale napsat to celé v Rustu, to není úplně schůdné.

[Idris]

Pak je ale vůbec nesmysl “průkopnicky” nasazovat Rust

No jo, chtěl jsem se sobecky naučit něco nového a nakonec jsem spadl do vlastní díry 

Sobče, vzdělávat ses chtěl!

Hehe, furt lepší než různí javamani, co místo sebevzdělávání nadávají všem vzdělaným a úspěšným

[Reklama]

[BoneFlute]

SOAP je peklo a patří na smetiště IT dějin.

Proč?

To je vážně míněná otázka? Odpovědí jsou všechny důvody, proč vzniklo například gRPC.

Jo, je to vážně míněná otázka.

Se SOAP jsem dělal (Java, C#, PHP). Netvrdím, že je to nějaká slává, prostě jsem to vzal v potaz a používal (když to klienti chtěli...).

RPC jsem používal dřív, různé implementace v Pythonu (patnáct let zpět). A mám za to, že je to krapet něco jiného než SOAP, ale nechám se poučit.

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

gRPC neznám, díky za tip.

Ptal jsem se proto, že občas slyším někoho nadávat na SOAP, ale většinou to jsou jen tak obecné nářky. A mě známé nevýhody, že je to ukecané a že je to v XML mi přijde trochu málo na takové zhodnocení. Hoď sem něco z patra prosím.

[Idris]

SOAP je peklo a patří na smetiště IT dějin.

Proč?

To je vážně míněná otázka? Odpovědí jsou všechny důvody, proč vzniklo například gRPC.

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

gRPC neznám, díky za tip.

Je to celé o efektivitě, REST je poměrně pomalý a parsovat XML je taky zbytečně zdlouhavé. Proto vymysleli Protobuf, což je extrémně úsporný protokol, a gRPC nad ním jede přes HTTP/2, takže bez zbytečných latencí. Žádná věda v tom není, ostatně pokud člověk neřeší miliony RPC volání za hodinu, tak ho asi použití JSONu nebo XML pálit nebude. Jen prostě parsování sežere dost CPU cyklů a paměti.

[Ink]

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

OAS nestačí? https://en.wikipedia.org/wiki/OpenAPI_Specification

[Idris]

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

OAS nestačí? https://en.wikipedia.org/wiki/OpenAPI_Specification

OpenAPI (aka Swagger) je jeden z mála standardů, co se v poslední povedl.

@BoneFlute Jestli to neznáš, doporučuju aspoň mrknout.

[BoneFlute]

SOAP je peklo a patří na smetiště IT dějin.

Proč?

To je vážně míněná otázka? Odpovědí jsou všechny důvody, proč vzniklo například gRPC.

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

gRPC neznám, díky za tip.

Je to celé o efektivitě, REST je poměrně pomalý a parsovat XML je taky zbytečně zdlouhavé. Proto vymysleli Protobuf, což je extrémně úsporný protokol, a gRPC nad ním jede přes HTTP/2, takže bez zbytečných latencí. Žádná věda v tom není, ostatně pokud člověk neřeší miliony RPC volání za hodinu, tak ho asi použití JSONu nebo XML pálit nebude. Jen prostě parsování sežere dost CPU cyklů a paměti.

Takže to

je peklo a patří na smetiště IT dějin

je čistě proto, že SOAP je neefektivní? Nebo je mu vyčítáno i něco jiného?

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

OAS nestačí? https://en.wikipedia.org/wiki/OpenAPI_Specification

OpenAPI (aka Swagger) je jeden z mála standardů, co se v poslední povedl.

Už jsem o něj zavadil, ale ještě jsem si na něj neudělal závěr. Takže díky za referenci.

[Google CTCCTCGGCGGGCACGTAG]

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

co je OpenAPI?

[Ink]

Takže to

je peklo a patří na smetiště IT dějin

je čistě proto, že SOAP je neefektivní? Nebo je mu vyčítáno i něco jiného?

Je to řešení ze světa Javy a velkých korporací. Design by committee, překomplikovaný, se spoustou rozšíření a ukrutně náročný, když to chceš znovu naimplementovat, ať už v jiném programovacím jazyce (jak jsme si tu koneckonců demonstrovali) nebo protože Ti stávající řešení třetích stran z nějakého důvodu nevyhovuje. Chceš poslat zprávu o tom, že Pepa Novák si kupuje ponožky za 10 dolarů a vychrstne to 5 KB XML s třemi namespacy a čtyřmi vrstvami obálek. Přitom Ty chceš jenom napsat jméno, příjmení, pár údajů o kartě a částku a nazpátek by Ti stačil číselný kód, který říká, jak to dopadlo a jeden řetězec s případným lidským popisem situace.

Krátce a výstižně, simplicity and utility trump large corporate backing: http://keithba.net/simplicity-and-utility-or-why-soap-lost

[Idris]

Takže to

je peklo a patří na smetiště IT dějin

je čistě proto, že SOAP je neefektivní? Nebo je mu vyčítáno i něco jiného?

překomplikovaný, se spoustou rozšíření a ukrutně náročný, když to chceš znovu naimplementovat

Přesně. Už jen samo použití XML nedává v dnešní době smysl a ty "obálky" kolem, to už je úplná magořina (z dnešního pohledu tvorby API a RPC).

[BoneFlute]

Aniž bych ostatní text ignoroval, tak:

Chceš poslat zprávu o tom, že Pepa Novák si kupuje ponožky za 10 dolarů

Mě na SOAP oslovilo právě a hlavně to WSDL. Nalinkuju jedno url, a hned mám kompletní knihovnu včetně dokumentace (fandím), typů, etc. A s žádným XML se vůbec nemusím dostat do styku (já vím, v reálu to tak nefungovalo) a nemusí mě zajímat.

To mě třeba na tom RESTu přišlo blbé. Že to sice je štíhlejší, a můžeš si to naimplementovat pár řádky kódu, ale problém je v tom, že vlastně musíš. Nejsou (nebyli) nástroje, které by udělali automaticky knihovnu a mohl jsi ty endpointy volat transparentně.

(Argument s OpenAPI prosím nechte. Pochopil jsem. Nastuduji si.)

[Idris]

Aniž bych ostatní text ignoroval, tak:

Chceš poslat zprávu o tom, že Pepa Novák si kupuje ponožky za 10 dolarů

Mě na SOAP oslovilo právě a hlavně to WSDL. Nalinkuju jedno url, a hned mám kompletní knihovnu včetně dokumentace (fandím), typů, etc. A s žádným XML se vůbec nemusím dostat do styku (já vím, v reálu to tak nefungovalo) a nemusí mě zajímat.

To mě třeba na tom RESTu přišlo blbé. Že to sice je štíhlejší, a můžeš si to naimplementovat pár řádky kódu, ale problém je v tom, že vlastně musíš. Nejsou (nebyli) nástroje, které by udělali automaticky knihovnu a mohl jsi ty endpointy volat transparentně.

(Argument s OpenAPI prosím nechte. Pochopil jsem. Nastuduji si.)

Teď už se generuje okolo API všechno, SOAP, Protobuf, OpenAPI... (člověk tak získá nezávislost na konkrétním jazyce, to je plus).