Bevezetés a gRPC használatába (van élet a SOAP és a REST után)

HUP

Sági-Kazár Márk (Cisco / Banzai Cloud) előadása a HWSW free! meetup-sorozat 2023. március 22-i gRPC tematikájú állomásán hangzott el. A meetupon a megszokottal ellentétben csak Márk adott elő, így lehetőség volt a témában mélyebben elmerülni - 90 percben. A mai összetett és folyamatosan fejlődő technológiai környezetben a hatékony és megbízható kommunikációs rendszerek kiépítése nagyobb kihívást jelent, mint valaha. Az egyre bonyolultabbá váló, elosztott rendszereket felépítő szolgáltatások és alkalmazások közötti növekvő kommunikáció igény miatt elengedhetetlen egy nagy teljesítményű keretrendszer, amely lépést tud tartani az elvárásokkal. Itt jön be a képbe a nyílt forráskódú gRPC keretrendszer. A gRPC leegyszerűsíti a szolgáltatások és alkalmazások közötti kommunikációt, gyors, hatékony és skálázható megoldást kínálva a modern elosztott rendszerek számára. A több nyelv támogatása, Protocol Buffers használata szerializációra, a kétirányú kommunikációs képességek és még rengeteg más funkció segítségével a gRPC választ ad azokra a kihívásokra, amelyekkel a legtöbb szervezet manapság szembesül.

( joco01 v | 2023. 12. 27., sze – 22:43 )

Protobufról szól az életem, az egész világot fel lehet vele építeni :)

ez egesz addig jo, amig elore meg vannak tervezve a protobuf mezok. aztan ha az evolucio szerint kell meg bele folyamatosan 3-4 uj mezo, 5-8 iteracioban, es meg valami rendet is akarsz tartani a mezoneveknel akkor lesznek az ilyen gnom strukturak:

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
  string foo = 6
  bool bar = 8;
  int32 baz = 7;
  int32 age = 5;
}

es ha nem csak 8 mezo van hanem 20, akkor goodluck az indexeleshez.

 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

tegyukfel hogy az elejen van egy egyszeru struktura:

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
}

ezzel szepen elbeszelteg, A, B, C, D, E progi egymassal.

aztan jon az igeny hogy be kene rakni az evet hogy A azt is elkuldje B-nek, de a D es E nem erintett, de amugy se lehet frissiteni!

ha jol olvastam a protobuf par megkotessel enged ilyet, csak az uj mezonek uj indexe (tag-nek hivja a protobuf) legyen:

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
  int32 age = 5;
}

Aztan jon hogy a C proginak uj mezokre van szuksege, ezert kapott megint uj mezot valahol a kozepebe hogy emberileg is olvashato legyen:

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
  string foo = 6
  bool bar = 8;
  int32 baz = 7;
  int32 age = 5;
}

stbstb.

aztan ezt lasd at hogy most hanyadik indexnel tartunk.

nyilvan jo lenne ha az elejen latnak az osszes mezot, de tudjuk hogy _mindig_ utkozben jonnek az igenyek.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Komolyan ez fáj? Mármint egyrészt ennek az alternatívája json földén kb a

  • /api/vN/, amit rendes kiscserkész módjára upgradelsz minden változásnál
  • leszarás, van benne valami, IJ van a kliensnek, ha nem tetszik

De ha tényleg fáj, akkor már ezer éve elég hosszan ki lehet bírni, ha mondjuk százas távolságra teszed az idket, aztán felezve szúrsz be. Vagy csak hagysz egy kommentet a tetején, hogy # next-id=123.

most csak a protobufrol beszelek (nem a gprc-rol), de csak azt az elonyt latom hogy a parsert nem neked kell megirni hanem pb generalja. jah meg kisebb lesz a message, mert a mezoneveket nemkell atvinni! :D

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

XML-ből láttam már olyat (fontos állami szervtől kaptuk), ahol escape nélkül szerepelt & a cégek nevében. Nyilvánvaló, hogy ők stringként rakták össze, nekünk meg stringként kellett beolvasni, mert a parser eldobta tőle az agyát. XSLT és XSD segítségével tudna egy-két jó dolgot az XML, de nekem nem hiányzik egyik se.

JSON: ez még rosszabb, mint az XML, mert (amennyire én ismerem) sokkal kevésbé támogatja az erősen típusos adatokat és kódgenerátorokat.

Az ilyen formátumú RPC-ktől pedig PTSD-m van, hiába raktunk össze szabványos (-nak tűnő) szolgáltatásokat WCF-fel, mindig voltak kompatibilitási problémák más partnerekkel, főleg ha titkosítás is szóba került.

A protobuffal *semmi* ilyen probléma nincs. Erősen típusos, gyárilag ad kódgenerátort minden nyelvhez, RPC a szabvány szerves része, és bináris formátum, ami nem csak azért jó, mert spórol a sávszélességgel, de idióta emberek meg sem próbálják kézzel írni/olvasni.

Ezek egyike sem szabvány sajnos, az XML annyiból jobb, hogy ha használsz sémát, azt géppel egyértelműen lehet validálni.

JSON esetén már választanod kell hogy egyáltalán követsz e séma rendszert, szerencsére a JSON schema és az OpenAPI összebútoroztak, így ha az utóbbi v3 újabb verzióit használod, már egészen jól validálható és generálható dolgot kapsz. Aztán jön a pofon, hogy ja a fejlesztő kedvenc framework-je még csak a v2-t támogatja, a generált kód nem tetszik neki, ezért eltöri a generálhatóságot, így onnantól az API dokumentáció és működés elválik egymástól, vagy legalábbis az API first átmegy code first-be. 

A protobuf legalább kikényszerít külső séma leírót.

A protobuf meglepő módon az XML időszak kedvenc hibáját teszi szinte magától értetődővé, könnyű kivezetni az API-ra a belső implementációs részleteket, ami ugye antipattern. JSON esetében ez kicsit nehezebb, bár ott sem kell azért küzdeni érte. 

Lényeg, hogy mindhárom jó cucc, de másban erős. XML-t bitagyúak szemmel is tudnak olvasni, de a kötött struktúra miatt géppel biztosan kiderül ha problémás. JSON-t bárki tud olvasni, cserében géppel csak annyira tudod ellenőrizni, amennyire az író megszorította a sémát (lásd egy boolean is valójában string benne), emiatt lassú a serialize/deserialize művelet. Grpc baromi gyors, de azt szemmel tuti nem debug-olod. 

> A protobuf meglepő módon az XML időszak kedvenc hibáját teszi szinte magától értetődővé, könnyű kivezetni az API-ra a belső implementációs részleteket, ami ugye antipattern.

Vannak erre patternek, pl.: https://protobuf.dev/programming-guides/api/#use-different-messages - és hasonló módon különböző API rétegekben különböző sémákat érdemes használni. A legkülső rétegben egy proto<->JSON konverzió is elfér.

> Grpc baromi gyors, de azt szemmel tuti nem debug-olod.

Nagy ritkán, ha biteket akarsz nézegetni, a CyberChef segít neked a kódolásban. Egyébként a protobuf olyan API-t ad, hogy rossz sémával vagy séma nélkül is tudod dekódolni, és nézegetni a kedvenc debuggeredben, hogy mi jött át. De mivel olyan kötött a sémája, még erre is ritkán van szükség. Szóval szerintem ilyen szempontból ez nem hátrány a szöveg alapú formátumokkal ellentétben. (Ja, amúgy protobufot is lehet szövegként szerializálni. Mi pl. szoktunk így konfig fájlokat írni.)