gRPC a gyakorlatban

Offtopic

Sziasztok!

Érdekelne használta-e már valaki a gRPC-t, mik vele a tapasztalatok? Tud e valós alternatívát nyújtani ma már a REST-JSON helyett? mellett?
Tekintve hogy elvileg 2015 óta elérhető, de valahogy mégsem nagy körülötte a hírverés, mint "új csodaszer".
Ellenben inpozánsnak tűnik a leírása alapján, nem értem miért nem terjed(t) el.
(vagy csak én nem találkoztam vele még eddig...)

  • 579 megtekintés

( joco01 v | 2019. 08. 23., p – 09:12 )

Sub. Gondolom ilyen technológiákat nem szoktak marketingelni, és kis projekteknél nem jönnek ki annyira az előnyei.

( dotnetlinux | 2019. 08. 23., p – 12:43 )

Tele a világ újdongásokkal, itt az Internet, minden 3mp alatt ide tud érni. De mivel nincs (elég) hype körülötte, így csak most találkoztam vele én is. Pedig a netflix is használja, azt meg nézem. :)

Ez nem látványos, mint a bootstrap, ez egy infratstruktúra komponens, azokat szerintem:
- nem cserélgetik túl gyakran. Megy a SOAP minek cserélni.
- nem tudnak igazán látványos dolgokat felmutatni benne.

De mivel jól dokumentált, a kiszolgálódat írd meg ebben és a kapcsolódó kliensek majd megtanulják ezt ha valóban hasznos. Van hozzá XSD vagy WSDL?

( joco01 v | 2019. 08. 23., p – 16:10 )

"Tud e valós alternatívát nyújtani ma már a REST-JSON helyett? mellett?"

A REST az egy API stílus/gondolkodásmód. gRPC-vel is lehet REST-szerű API-kat gyártani. Sőt, a Google tipikusan az ilyen API-kat szereti, és lehet gRPC szolgáltatásokat HTTP-re megfeleltetni: https://cloud.google.com/endpoints/docs/grpc/transcoding . De gRPC-vel lehet bármilyen más RPC-t is gyártani, vagy akár streaminget is, ami REST-ben nincs.

Nekem a SOAP-pal az a bajom, hogy a legalapvetőbb hello world szintű szolgáltatásoktól bonyolultabb esetekben előfordulnak különböző platformok között inkompatibilitási problémák (sokat szoptam már WCF-fel .NET alatt, aminek Javával és egyebekkel kellett összebeszélnie). A JSON ettől még sokkal rosszabb is lehet, mert önmagában semmiféle sémát nem követel meg. A gRPC evvel szemben az alapoktól kezdve a cross-platform kompatibilitásra van kihegyezve, nagyon jó a típus-rendszere is, soha nem volt vele szopás. Az mellesleg tök jó, hogy nagyon gyors, de szerintem viszonylag ritka az, hogy valakinél ez lenne a szűk keresztmetszet (Google-ön belül meg nyilván rengeteget számít).

Ha egyszer egy tipikus kis X cég azt találná ki, hogy mostantól ők az Y szolgáltatást gRPC-n ajánlják ki, akkor az tuti, hogy a kliensek dobnak tőle egy hátast, hogy hát ők azt se tudják mi az, valami hippi baromság lehet, túl drága az átállás, az ő egységsugarú fejlesztőik nem értenek hozzá, stb. Nem olyan könnyű azt bevezetni. Szerintem leginkább házon belüli rendszerek esetén érdemes használni, ahol a kliensek nem gördítenek akadályt elé.

"Nekem a SOAP-pal az a bajom, hogy a legalapvetőbb hello world szintű szolgáltatásoktól bonyolultabb esetekben előfordulnak különböző platformok között inkompatibilitási problémák"

Azért erre kíváncsi lennék. Csináltunk (nagy) szolgáltatás portfóliókat, ESB-vel meg mindenfélével, SOAP/SOA alapon, és simán ment minden. A WSDL/XSD precízen leírja az üzeneteket. Ahol mégis gond adódott, ott kiderült hogy nem is XML parsert használtak, hanem valami regexet vagy még rosszabbat - de azért egyébként is kövezés jár.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Cégen belül nem annyira szívás a SOAP sem, de külsősökkel együttműködve már gáz. 5+ éve volt már, de pár példa:
* Bonyolultabb XSD konstrukciók esetén kicsit hazárdos, hogy melyik platformon mi fordul belőle. Protobuf esetén nagyon odafigyelnek egy csomó nyelvre, hogy még a corner case-ekben is megbízhatóan működjön (pl. nézd meg, miért nem enged map<> kulcsnak enumot használni, pedig jó lenne).
* Jellemzően egy platformon belül is több SOAP library van, pl. .NET-ben van a WCF előtti XmlSerializert használó megoldás és a WCF a DataContractSerializerrel, Javában volt legalább kettő de inkább fél tucat, és sajnos adja magát a kézzel megírt XML szerializáció is (persze ők magukra vessenek). gRPC esetén van a referencia implementáció ami tud mindent, semmi szükség másra.
* WS-Security az egy rémálom, fekete mágia volt .NET és Java között összehozni, és vannak még egyéb WS-* finomságok is, amikre kevésbé emlékszem.

Talán pont a kicsinysége miatt, de a SOAP esetén a dátumokkal szívtunk, annak időzóna tartalmával (asszem). Java vs. Delphi volt, úgy 8 éve. Simán lehet hogy a Delphi nem a szabvány WSDL-t használta, de a lényeg, hogy volt valami elcsúszás.
8 év alatt biztos tanultak már belőle azon a helyen, ahol volt.

Ja, ez a SOAP és JSON esetén is gáz lehet. A protobuf, mint nyelv ezt meg sem próbálja megoldani, viszont léteznek hivatalos proto fájlok a jól ismert összetettebb típusokra, mint pl. https://github.com/protocolbuffers/protobuf/blob/master/src/google/prot… , és akkor ezekre lehet írni minden nyelvben konvertáló könyvtárakat.

Igazából arra gondoltam, csak így ötletszerüen, hogy egy nodejsben írt json rest api, és a hozzá társuló Angular kliens közötti kommunikációt, csak a játék kedvéért áttenném gRPC-re, hátha. Egy kevés utánnaolvasás után nekem is SOAP feelingem volt a dologgal kapcsolatosan, bár hál istennek én a SOAP-ot megúsztam, egyszer sem kellett írnom, felhasználnom sem szerver, sem kliens oldalon. Aztán ha nem túl sok a macera vele, lehet productionben is megpróbálkoznék vele. Azzal nyilván számolok, hogy más kliens adott esetben csak pislog majd, de azért az bíztató, hogy nagy cégek, illetve népszerű szoftverek alkalmazzák már a grpct.

JS-ben akkor jó dolgozni szerintem, ha valami típusrendszerrel rendelkező fordítót használsz, az Angular miatt arra tippelek, hogy ez adott, és a gRPC szintén tudja remélhetőleg. Nem tudom, hogy JSON-hoz van-e ilyen sémából adatosztályt fordító izé. Másrészt gRPC-vel gyorsabb lesz, mint JSON-nel, de kis mennyiségű RPC esetén nem lesz észrevehető. Tanulásnak biztos jó.

+1

Igen, itt inkább tanuláson van most hangsúly. A héten meg is futom ezt a kört, beszámolok majd a végeredményről szívesen ha van akit szintén érdekel.
A proto-hoz találtam libet typescriptnek. úgyhogy elvi akadálya nem kellene legyen a dolgoknak. Nah majd meglátjuk mi sül ki.

( Crayon | 2019. 08. 26., h – 10:17 )

IMHO ez a cucc egy meglévő "piacra" próbál betörni. Ahogy felettem is írták vannak azért már bejáratott megoldások erre a problémakörre és akiknek az működik azok puszta kalandvágyból nem fogják átrakni a cuccukat erre, mert annyi hozzáadott értéke nincs a meglévő megoldásokhoz képest. Valószínűleg ezek miatt is nincs körülötte akkora hype. Új projekthez viszont lehet, hogy szívesen kipróbálnám majd én is egy 38. REST API meggyártása helyett.

( sunmao v | 2019. 08. 26., h – 10:39 )

Szerintem a ket megoldas nem teljesen ugyanazt a feladatot latja el, illetve lehet a gRPC-t REST helyett hasznalni, forditva szerintem mar nem mindig mukodne a dolog.

Ugye a REST-el resourceokat hozol letre/valtoztatsz/torolsz es kerdezel le.
Az gRPC egy RPC implementacio, itt tulajdonkeppen az tortenik hogy valamilyen service class-nak a metodusat hivod meg, csak ez a szervice class eppenseggel nem nalad van lokalisan leimplementalva, hanem valahol mashol.

Ha nem vilagos, hogy miert mas feladatot lat el a ketto akkor itt egy pelda:

gRPC-vel ez egy teljesen valid call:

calcSqrtAndMultiplyByFive(num: BigDecimal)

Ez REST-el/ben eleg furcsan nezne ki.