Zmiana technologii z WCF na gRPC<\/strong><\/h2>\n\n\n\nTaka sytuacja spotka\u0142a mnie bardzo kr\u00f3tko po do\u0142\u0105czeniu do projektu. Nie chc\u0105c komplikowa\u0107 ju\u017c i tak sporego kawa\u0142ka kodu, w kt\u00f3rym rozszerzenie mia\u0142o by\u0107 wykorzystywane, przygotowa\u0142em najpierw propozycj\u0119 zmian, ale w taki spos\u00f3b, \u017ceby jego implementacja znajdowa\u0142a si\u0119 poza aktualnym projektem. Dodatkowo, przygotowa\u0142em dla klienta propozycj\u0119 wykorzystywania technologii innej ni\u017c WCF, kt\u00f3ra by\u0142a u\u017cywana do tamtej chwili.<\/p>\n\n\n\n
Istotnym argumentem za zmian\u0105 technologii by\u0142 koniec wsparcia dla WCF ze strony Microsoftu. Wyb\u00f3r pad\u0142 na gRPC ze wzgl\u0119du na podobie\u0144stwo do WCF. Taka argumentacja u\u015bwiadomi\u0142a klientowi, \u017ce trzeba rozpocz\u0105\u0107 przepisywanie systemu na nowsz\u0105 technologi\u0119<\/strong>. Zwr\u00f3ci\u0142em uwag\u0119 klienta r\u00f3wnie\u017c na to, \u017ce warto zacz\u0105\u0107 to robi\u0107 stopniowo, z mo\u017cliwo\u015bci\u0105 r\u00f3wnoleg\u0142ej pracy starego systemu opartego na WCF oraz systemu, kt\u00f3ry b\u0119dzie zawiera\u0142 te same funkcjonalno\u015bci lub nowe, jednak wykorzystuj\u0105ce ju\u017c technologi\u0119 gRPC.<\/p>\n\n\n\n![\"Schemat](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/12\/gRpc.png\")
<\/a>Ryc. 1 Schemat wymiany danych w protokole gRPC<\/figcaption><\/figure>\n\n\n\nCzym jest gRPC i dlaczego warto z niego korzysta\u0107?<\/strong><\/h2>\n\n\n\ngRPC jest to system zdalnego wywo\u0142ania procedur<\/strong> (Remote Procedure Call), pierwotnie opracowany przez Google. Gdy system ten sta\u0142 si\u0119 ju\u017c dojrza\u0142y, zosta\u0142 udost\u0119pniony w ramach projektu typu open-source. Taki krok pozwoli\u0142 protoko\u0142owi zyska\u0107 popularno\u015b\u0107 oraz wsparcie ze strony spo\u0142eczno\u015bci, a to przyci\u0105gn\u0119\u0142o do niego jeszcze wi\u0119ksz\u0105 rzesz\u0119 zwolennik\u00f3w.<\/p>\n\n\n\ngRPC jest wykorzystywane m.in. przez Netflix i Cisco, co potwierdza potencja\u0142 tej technologii. Du\u017cym plusem dla programist\u00f3w WCF jest r\u00f3wnie\u017c podobie\u0144stwo w definiowaniu kontraktu wymiany informacji pomi\u0119dzy dostawc\u0105 i odbiorc\u0105<\/strong>. W przypadku gRPC kontrakt jest zdefiniowany z u\u017cyciem specjalnego j\u0119zyka \u201eProto\u201d oraz przetrzymywany w pliku o rozszerzeniu *.proto. Istnieje jednak mo\u017cliwo\u015b\u0107 implementacji kontraktu w niemal identyczny spos\u00f3b jak odbywa si\u0119 to w WCF, jednak trzeba zachowa\u0107 kilka regu\u0142. Wi\u0119cej informacji mo\u017cna znale\u017a\u0107 w materia\u0142ach<\/a>.<\/p>\n\n\n\nZastosowanie gRPC w dzia\u0142aj\u0105cym systemie<\/strong><\/h2>\n\n\n\nAby umo\u017cliwi\u0107 wykorzystanie gRPC w aktualnie dzia\u0142aj\u0105cym systemie, zastosowa\u0142em wzorzec projektowy Po\u015brednik (Proxy). Zak\u0142ada on wykorzystanie obiektu po\u015brednicz\u0105cego pomi\u0119dzy klientem, kt\u00f3ry wywo\u0142uje operacj\u0119 a rzeczywistym obiektem, kt\u00f3ry zapewnia wymagan\u0105 funkcjonalno\u015b\u0107. Taka architektura przydaje si\u0119, gdy nie chcemy wi\u0105za\u0107 si\u0119 z konkretnym obiektem po stronie klienta lub gdy rzeczywisty obiekt znajduje si\u0119 na zdalnym systemie.<\/p>\n\n\n\n![\"Diagram](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/12\/ProxyDiagram.png\")
<\/a>Ryc. 2 Diagram klas dla wzorca po\u015brednik<\/figcaption><\/figure>\n\n\n\nDo istniej\u0105cej ju\u017c solucji doda\u0142em projekt biblioteki typu .NET Standard 2.1. Taka wersja frameworku pozwoli\u0142a na u\u017cycie technologii gRPC w oparciu o ASP.NET oraz jego referencj\u0119 w g\u0142\u00f3wnym projekcie (monolicie), kt\u00f3ry wykorzystuje .NET Framework 4.7.<\/p>\n\n\n\n
W nowym projekcie zaimplementowany zosta\u0142 obiekt Proxy, kt\u00f3ry jednocze\u015bnie jest klientem gRPC. Jego implementacja sk\u0142ada si\u0119 z kilku metod, kt\u00f3re wykorzystuj\u0105 klienta gRPC. W starym projekcie, wykorzystuj\u0105cym WCF, tworzona jest instancja obiektu Proxy, kt\u00f3ra, po wywo\u0142aniu odpowiedniej metody, po\u015bredniczy w wys\u0142aniu pro\u015bby o wykonanie zdalnej procedury do serwera gRPC, a nast\u0119pnie konsumuje otrzymane informacje w celu przygotowania odpowiedzi.<\/p>\n\n\n\n
Poniewa\u017c w technologii gRPC komunikacja pomi\u0119dzy klientem, a serwerem odbywa si\u0119 poprzez protok\u00f3\u0142 HTTP, serwer gRPC mo\u017ce by\u0107 umieszczony w dowolnym miejscu, a technologia u\u017cyta do jego implementacji nie jest ograniczona przez technologi\u0119 u\u017cyt\u0105 do implementacji klienta.<\/p>\n\n\n\n![\"Diagram](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/12\/BackendProxyMicroserviceSequence.png\")
<\/a>Ryc. 3 Diagram sekwencji z uwzgl\u0119dnieniem po\u015brednika i mikroserwis\u00f3w<\/figcaption><\/figure>\n\n\n\nUniezale\u017cnienie od wcze\u015bniejszych decyzji projektowych<\/strong><\/h2>\n\n\n\nNowa funkcjonalno\u015b\u0107, kt\u00f3rej dodania wymaga\u0142 od nas klient, zosta\u0142a zaimplementowana w ramach serwera gRPC. W naszym przypadku serwer pocz\u0105tkowo dzia\u0142a\u0142 jako lokalny serwis Windowsa, wykorzystuj\u0105cy technologi\u0119 ASP.NET 5 i hostowany by\u0142 za pomoc\u0105 wbudowanego serwera Kestrel. Ograniczy\u0142o to instalowanie dodatkowych serwer\u00f3w WWW oraz ich administracj\u0119. Aby jeszcze bardziej uniezale\u017cni\u0107 si\u0119 od narzuconych wcze\u015bniej decyzji projektowych, aktualnie serwer gRPC dzia\u0142a w kontenerze Docker. Zalet\u0105 takiego rozwi\u0105zania jest mo\u017cliwo\u015b\u0107 hostowania serwisu, kt\u00f3ry jest cz\u0119\u015bci\u0105 naszego systemu na innych maszynach ni\u017c lokalny serwer, jak r\u00f3wnie\u017c w chmurze.<\/p>\n\n\n\n
gRPC \u2013 co dalej?<\/strong><\/h2>\n\n\n\nNa ten moment system posiada ju\u017c 3 osobne mikroserwisy, kt\u00f3re przez ca\u0142y czas s\u0105 rozwijane i usprawniane. Opisana tutaj architektura pozwala na rozw\u00f3j funkcjonalno\u015bci istniej\u0105cego ju\u017c systemu oraz na mo\u017cliwo\u015b\u0107 przeprowadzenia r\u00f3wnoleg\u0142ych prac nad przepisaniem systemu z dzia\u0142aj\u0105cego w technologii WCF do gRPC.<\/p>\n\n\n\n
Docelowo, ca\u0142y system b\u0119dzie hostowany w chmurze, jednak jego migracja nast\u0119puje stopniowo. Krokiem po\u015brednim b\u0119dzie hostowanie mikroserwis\u00f3w w kontenerach w infrastrukturze chmury, a cz\u0119\u015b\u0107 systemu nadal b\u0119dzie hostowana w lokalnej infrastrukturze.<\/p>\n\n\n\n
Mo\u017cliwo\u015b\u0107 korzystania z najnowszych technologii zach\u0119ci dodatkowe osoby do pracy w naszym projekcie, poniewa\u017c WCF ju\u017c od jakiego\u015b czasu nie jest wykorzystywany w nowych projektach. R\u00f3wnie\u017c brak ogranicze\u0144 architektonicznych przez u\u017cycie technologii gRPC zwi\u0119ksza swobod\u0119 w rozbudowie zespo\u0142u o osoby nie maj\u0105ce wcze\u015bniej do czynienia z technologi\u0105 Microsoft WCF, a nawet z .NET Framework.<\/p>\n\n\n
<\/a>Czym jest gRPC i dlaczego warto z niego korzysta\u0107?<\/strong><\/h2>\n\n\n\ngRPC jest to system zdalnego wywo\u0142ania procedur<\/strong> (Remote Procedure Call), pierwotnie opracowany przez Google. Gdy system ten sta\u0142 si\u0119 ju\u017c dojrza\u0142y, zosta\u0142 udost\u0119pniony w ramach projektu typu open-source. Taki krok pozwoli\u0142 protoko\u0142owi zyska\u0107 popularno\u015b\u0107 oraz wsparcie ze strony spo\u0142eczno\u015bci, a to przyci\u0105gn\u0119\u0142o do niego jeszcze wi\u0119ksz\u0105 rzesz\u0119 zwolennik\u00f3w.<\/p>\n\n\n\ngRPC jest wykorzystywane m.in. przez Netflix i Cisco, co potwierdza potencja\u0142 tej technologii. Du\u017cym plusem dla programist\u00f3w WCF jest r\u00f3wnie\u017c podobie\u0144stwo w definiowaniu kontraktu wymiany informacji pomi\u0119dzy dostawc\u0105 i odbiorc\u0105<\/strong>. W przypadku gRPC kontrakt jest zdefiniowany z u\u017cyciem specjalnego j\u0119zyka \u201eProto\u201d oraz przetrzymywany w pliku o rozszerzeniu *.proto. Istnieje jednak mo\u017cliwo\u015b\u0107 implementacji kontraktu w niemal identyczny spos\u00f3b jak odbywa si\u0119 to w WCF, jednak trzeba zachowa\u0107 kilka regu\u0142. Wi\u0119cej informacji mo\u017cna znale\u017a\u0107 w materia\u0142ach<\/a>.<\/p>\n\n\n\nZastosowanie gRPC w dzia\u0142aj\u0105cym systemie<\/strong><\/h2>\n\n\n\nAby umo\u017cliwi\u0107 wykorzystanie gRPC w aktualnie dzia\u0142aj\u0105cym systemie, zastosowa\u0142em wzorzec projektowy Po\u015brednik (Proxy). Zak\u0142ada on wykorzystanie obiektu po\u015brednicz\u0105cego pomi\u0119dzy klientem, kt\u00f3ry wywo\u0142uje operacj\u0119 a rzeczywistym obiektem, kt\u00f3ry zapewnia wymagan\u0105 funkcjonalno\u015b\u0107. Taka architektura przydaje si\u0119, gdy nie chcemy wi\u0105za\u0107 si\u0119 z konkretnym obiektem po stronie klienta lub gdy rzeczywisty obiekt znajduje si\u0119 na zdalnym systemie.<\/p>\n\n\n\n<\/a>Ryc. 2 Diagram klas dla wzorca po\u015brednik<\/figcaption><\/figure>\n\n\n\nDo istniej\u0105cej ju\u017c solucji doda\u0142em projekt biblioteki typu .NET Standard 2.1. Taka wersja frameworku pozwoli\u0142a na u\u017cycie technologii gRPC w oparciu o ASP.NET oraz jego referencj\u0119 w g\u0142\u00f3wnym projekcie (monolicie), kt\u00f3ry wykorzystuje .NET Framework 4.7.<\/p>\n\n\n\n
W nowym projekcie zaimplementowany zosta\u0142 obiekt Proxy, kt\u00f3ry jednocze\u015bnie jest klientem gRPC. Jego implementacja sk\u0142ada si\u0119 z kilku metod, kt\u00f3re wykorzystuj\u0105 klienta gRPC. W starym projekcie, wykorzystuj\u0105cym WCF, tworzona jest instancja obiektu Proxy, kt\u00f3ra, po wywo\u0142aniu odpowiedniej metody, po\u015bredniczy w wys\u0142aniu pro\u015bby o wykonanie zdalnej procedury do serwera gRPC, a nast\u0119pnie konsumuje otrzymane informacje w celu przygotowania odpowiedzi.<\/p>\n\n\n\n
Poniewa\u017c w technologii gRPC komunikacja pomi\u0119dzy klientem, a serwerem odbywa si\u0119 poprzez protok\u00f3\u0142 HTTP, serwer gRPC mo\u017ce by\u0107 umieszczony w dowolnym miejscu, a technologia u\u017cyta do jego implementacji nie jest ograniczona przez technologi\u0119 u\u017cyt\u0105 do implementacji klienta.<\/p>\n\n\n\n<\/a>Ryc. 3 Diagram sekwencji z uwzgl\u0119dnieniem po\u015brednika i mikroserwis\u00f3w<\/figcaption><\/figure>\n\n\n\nUniezale\u017cnienie od wcze\u015bniejszych decyzji projektowych<\/strong><\/h2>\n\n\n\nNowa funkcjonalno\u015b\u0107, kt\u00f3rej dodania wymaga\u0142 od nas klient, zosta\u0142a zaimplementowana w ramach serwera gRPC. W naszym przypadku serwer pocz\u0105tkowo dzia\u0142a\u0142 jako lokalny serwis Windowsa, wykorzystuj\u0105cy technologi\u0119 ASP.NET 5 i hostowany by\u0142 za pomoc\u0105 wbudowanego serwera Kestrel. Ograniczy\u0142o to instalowanie dodatkowych serwer\u00f3w WWW oraz ich administracj\u0119. Aby jeszcze bardziej uniezale\u017cni\u0107 si\u0119 od narzuconych wcze\u015bniej decyzji projektowych, aktualnie serwer gRPC dzia\u0142a w kontenerze Docker. Zalet\u0105 takiego rozwi\u0105zania jest mo\u017cliwo\u015b\u0107 hostowania serwisu, kt\u00f3ry jest cz\u0119\u015bci\u0105 naszego systemu na innych maszynach ni\u017c lokalny serwer, jak r\u00f3wnie\u017c w chmurze.<\/p>\n\n\n\n
gRPC \u2013 co dalej?<\/strong><\/h2>\n\n\n\nNa ten moment system posiada ju\u017c 3 osobne mikroserwisy, kt\u00f3re przez ca\u0142y czas s\u0105 rozwijane i usprawniane. Opisana tutaj architektura pozwala na rozw\u00f3j funkcjonalno\u015bci istniej\u0105cego ju\u017c systemu oraz na mo\u017cliwo\u015b\u0107 przeprowadzenia r\u00f3wnoleg\u0142ych prac nad przepisaniem systemu z dzia\u0142aj\u0105cego w technologii WCF do gRPC.<\/p>\n\n\n\n
Docelowo, ca\u0142y system b\u0119dzie hostowany w chmurze, jednak jego migracja nast\u0119puje stopniowo. Krokiem po\u015brednim b\u0119dzie hostowanie mikroserwis\u00f3w w kontenerach w infrastrukturze chmury, a cz\u0119\u015b\u0107 systemu nadal b\u0119dzie hostowana w lokalnej infrastrukturze.<\/p>\n\n\n\n
Mo\u017cliwo\u015b\u0107 korzystania z najnowszych technologii zach\u0119ci dodatkowe osoby do pracy w naszym projekcie, poniewa\u017c WCF ju\u017c od jakiego\u015b czasu nie jest wykorzystywany w nowych projektach. R\u00f3wnie\u017c brak ogranicze\u0144 architektonicznych przez u\u017cycie technologii gRPC zwi\u0119ksza swobod\u0119 w rozbudowie zespo\u0142u o osoby nie maj\u0105ce wcze\u015bniej do czynienia z technologi\u0105 Microsoft WCF, a nawet z .NET Framework.<\/p>\n\n\n
gRPC jest wykorzystywane m.in. przez Netflix i Cisco, co potwierdza potencja\u0142 tej technologii. Du\u017cym plusem dla programist\u00f3w WCF jest r\u00f3wnie\u017c podobie\u0144stwo w definiowaniu kontraktu wymiany informacji pomi\u0119dzy dostawc\u0105 i odbiorc\u0105<\/strong>. W przypadku gRPC kontrakt jest zdefiniowany z u\u017cyciem specjalnego j\u0119zyka \u201eProto\u201d oraz przetrzymywany w pliku o rozszerzeniu *.proto. Istnieje jednak mo\u017cliwo\u015b\u0107 implementacji kontraktu w niemal identyczny spos\u00f3b jak odbywa si\u0119 to w WCF, jednak trzeba zachowa\u0107 kilka regu\u0142. Wi\u0119cej informacji mo\u017cna znale\u017a\u0107 w materia\u0142ach<\/a>.<\/p>\n\n\n\n Aby umo\u017cliwi\u0107 wykorzystanie gRPC w aktualnie dzia\u0142aj\u0105cym systemie, zastosowa\u0142em wzorzec projektowy Po\u015brednik (Proxy). Zak\u0142ada on wykorzystanie obiektu po\u015brednicz\u0105cego pomi\u0119dzy klientem, kt\u00f3ry wywo\u0142uje operacj\u0119 a rzeczywistym obiektem, kt\u00f3ry zapewnia wymagan\u0105 funkcjonalno\u015b\u0107. Taka architektura przydaje si\u0119, gdy nie chcemy wi\u0105za\u0107 si\u0119 z konkretnym obiektem po stronie klienta lub gdy rzeczywisty obiekt znajduje si\u0119 na zdalnym systemie.<\/p>\n\n\n\n Do istniej\u0105cej ju\u017c solucji doda\u0142em projekt biblioteki typu .NET Standard 2.1. Taka wersja frameworku pozwoli\u0142a na u\u017cycie technologii gRPC w oparciu o ASP.NET oraz jego referencj\u0119 w g\u0142\u00f3wnym projekcie (monolicie), kt\u00f3ry wykorzystuje .NET Framework 4.7.<\/p>\n\n\n\n W nowym projekcie zaimplementowany zosta\u0142 obiekt Proxy, kt\u00f3ry jednocze\u015bnie jest klientem gRPC. Jego implementacja sk\u0142ada si\u0119 z kilku metod, kt\u00f3re wykorzystuj\u0105 klienta gRPC. W starym projekcie, wykorzystuj\u0105cym WCF, tworzona jest instancja obiektu Proxy, kt\u00f3ra, po wywo\u0142aniu odpowiedniej metody, po\u015bredniczy w wys\u0142aniu pro\u015bby o wykonanie zdalnej procedury do serwera gRPC, a nast\u0119pnie konsumuje otrzymane informacje w celu przygotowania odpowiedzi.<\/p>\n\n\n\n Poniewa\u017c w technologii gRPC komunikacja pomi\u0119dzy klientem, a serwerem odbywa si\u0119 poprzez protok\u00f3\u0142 HTTP, serwer gRPC mo\u017ce by\u0107 umieszczony w dowolnym miejscu, a technologia u\u017cyta do jego implementacji nie jest ograniczona przez technologi\u0119 u\u017cyt\u0105 do implementacji klienta.<\/p>\n\n\n\n Nowa funkcjonalno\u015b\u0107, kt\u00f3rej dodania wymaga\u0142 od nas klient, zosta\u0142a zaimplementowana w ramach serwera gRPC. W naszym przypadku serwer pocz\u0105tkowo dzia\u0142a\u0142 jako lokalny serwis Windowsa, wykorzystuj\u0105cy technologi\u0119 ASP.NET 5 i hostowany by\u0142 za pomoc\u0105 wbudowanego serwera Kestrel. Ograniczy\u0142o to instalowanie dodatkowych serwer\u00f3w WWW oraz ich administracj\u0119. Aby jeszcze bardziej uniezale\u017cni\u0107 si\u0119 od narzuconych wcze\u015bniej decyzji projektowych, aktualnie serwer gRPC dzia\u0142a w kontenerze Docker. Zalet\u0105 takiego rozwi\u0105zania jest mo\u017cliwo\u015b\u0107 hostowania serwisu, kt\u00f3ry jest cz\u0119\u015bci\u0105 naszego systemu na innych maszynach ni\u017c lokalny serwer, jak r\u00f3wnie\u017c w chmurze.<\/p>\n\n\n\n Na ten moment system posiada ju\u017c 3 osobne mikroserwisy, kt\u00f3re przez ca\u0142y czas s\u0105 rozwijane i usprawniane. Opisana tutaj architektura pozwala na rozw\u00f3j funkcjonalno\u015bci istniej\u0105cego ju\u017c systemu oraz na mo\u017cliwo\u015b\u0107 przeprowadzenia r\u00f3wnoleg\u0142ych prac nad przepisaniem systemu z dzia\u0142aj\u0105cego w technologii WCF do gRPC.<\/p>\n\n\n\n Docelowo, ca\u0142y system b\u0119dzie hostowany w chmurze, jednak jego migracja nast\u0119puje stopniowo. Krokiem po\u015brednim b\u0119dzie hostowanie mikroserwis\u00f3w w kontenerach w infrastrukturze chmury, a cz\u0119\u015b\u0107 systemu nadal b\u0119dzie hostowana w lokalnej infrastrukturze.<\/p>\n\n\n\n Mo\u017cliwo\u015b\u0107 korzystania z najnowszych technologii zach\u0119ci dodatkowe osoby do pracy w naszym projekcie, poniewa\u017c WCF ju\u017c od jakiego\u015b czasu nie jest wykorzystywany w nowych projektach. R\u00f3wnie\u017c brak ogranicze\u0144 architektonicznych przez u\u017cycie technologii gRPC zwi\u0119ksza swobod\u0119 w rozbudowie zespo\u0142u o osoby nie maj\u0105ce wcze\u015bniej do czynienia z technologi\u0105 Microsoft WCF, a nawet z .NET Framework.<\/p>\n\n\nZastosowanie gRPC w dzia\u0142aj\u0105cym systemie<\/strong><\/h2>\n\n\n\n
<\/a><\/a>Uniezale\u017cnienie od wcze\u015bniejszych decyzji projektowych<\/strong><\/h2>\n\n\n\n
gRPC \u2013 co dalej?<\/strong><\/h2>\n\n\n\n