Jak dobrze zbudować serwer i klient gRPC?

Cześć, czy ktoś ma doświadczenie z budowaniu aplikacji PHP integrujących się z innymi usługami przez gRPC? Chodzi tutaj o zarówno operacje jako klient, ale również jako serwer - co rozumiem, że jest problemowe. Czy ktoś może wgłębiał się w temat pełnej integracji z innymi systemami poprzez ten protokół i ma jakieś przemyślenia jak to można zrobić żeby się nie sparzyć?

Na początek to w ogóle mieć rzeczywistą potrzebę korzystania z grpc, bo branie tego tak o to solidny overkill.

dotgo napisał(a):

Na początek to w ogóle mieć rzeczywistą potrzebę korzystania z grpc, bo branie tego tak o to solidny overkill.

Jest wymaganie zewnętrzne żeby dostosować do innych serwisów.
Duża ilość logiki która jest już opracowana w tej apce PHP wskazuje na konieczność realizowania tego dalej tam.

Myślałem o przenoszeniu niektórych rzeczy do osobnego serwisu pisanego w Go ale jest tego dużo i nie chcę duplikować działania. Na razie to badam i szukam alternatyw i pomysłów. Dużo się mówi o robieniu proxy właśnie w Go, widziałem że openswoole daje takie możliwości (ale trochę mam przed nim obawy), ale ciężko mi podjąć decyzje i szukam opinii kogoś kto robił coś podobnego.

clonazepam napisał(a):

Myślałem o przenoszeniu niektórych rzeczy do osobnego serwisu pisanego w Go
... Dużo się mówi o robieniu proxy właśnie w Go, widziałem że openswoole daje takie możliwości (ale trochę mam przed nim obawy),

Nie dotykałem, ale ciezko wierzyć że łącznie z pracą bazy danych, transmisją w sieci to Go dało jakieś przekonujące oszczędności w stosunku do dobrze użytego C# czy Javy / Kotlina
Ale rozumiem teraz to modne ?

O ile jestem gorącym zwolennikiem protokołów binarnych jak gRPC czy Thrift w językach kompilowanych (z odcieniem maszynowym, przynajmniej gospodarka typami elementarnych i bajtami) *), to nie umiem gorąco namawiać na PHPy, Pythony. Tam nie nawet spektrum typów integerowych / prawdziwych tablic prawdziwych bajtow, co jest warunkiem aby były z tego jakiekolwiek pożytki.

*) i fabryczną automatyczną generacją kodu interfejsów

clonazepam napisał(a):

Cześć, czy ktoś ma doświadczenie z budowaniu aplikacji PHP integrujących się z innymi usługami przez gRPC?

Tak, ja mam.

clonazepam napisał(a):

Chodzi tutaj o zarówno operacje jako klient, ale również jako serwer - co rozumiem, że jest problemowe.

Bez przesady.

clonazepam napisał(a):

Czy ktoś może wgłębiał się w temat pełnej integracji z innymi systemami poprzez ten protokół

Jak akurat nie mialem takiej potrzeby, ograniczajac sie jedynie do php

clonazepam napisał(a):

... jak to można zrobić żeby się nie sparzyć?

Deprymujace jest to, ze w oficjalnych docs'ach brakuje wzmianki o jednym istotnym elemencie, ktory uniemozliwia zakonczone sukcesem odpalenie prezentowanego tam "Hallo World" 'a.
Kiedy juz sie dowiesz o co chodzi, grpc to jest kosmos.
Na kazdej plaszczyznie.
W skrocie, masz uczucie jakbys przesiadl sie z hulajnogi do ferrari.

@dotgo @AnyKtokolwiek
Nie macie pojecia, to sie nie wypowiadajcie.

AnyKtokolwiek napisał(a):

Nie dotykałem, ale ciezko wierzyć że łącznie z pracą bazy danych, transmisją w sieci to Go dało jakieś przekonujące oszczędności w stosunku do dobrze użytego C# czy Javy / Kotlina
Ale rozumiem teraz to modne ?

Jeden pies. Zalety go to prostota, male kontenery, niskie zuzycie pamieci i niskie pauzy gc przy dobrej wydajnosci. Na pisanie proxy na szybko jak znalazl

AnyKtokolwiek napisał(a):

clonazepam napisał(a):

Myślałem o przenoszeniu niektórych rzeczy do osobnego serwisu pisanego w Go
... Dużo się mówi o robieniu proxy właśnie w Go, widziałem że openswoole daje takie możliwości (ale trochę mam przed nim obawy),

Nie dotykałem, ale ciezko wierzyć że łącznie z pracą bazy danych, transmisją w sieci to Go dało jakieś przekonujące oszczędności w stosunku do dobrze użytego C# czy Javy / Kotlina
Ale rozumiem teraz to modne ?

Tu bardziej chodzi o to, że ja i ludzie z którymi bym to budował akurat ogarniamy Go poza PHP.

proximus-prime napisał(a):

clonazepam napisał(a):

Cześć, czy ktoś ma doświadczenie z budowaniu aplikacji PHP integrujących się z innymi usługami przez gRPC?

Tak, ja mam.

@proximus-prime To jak w takim razie wyglądało u ciebie to w projekcie? Musiałeś wystawić jakąś funkcjonalność dla innych systemów? Jak do tego podszedłeś?

Bo w docs widzę od razu info:

"Note
You can only create gRPC clients in PHP. Use another language to create a gRPC server."

Więc dlatego uznałem, że już moje marzenie o robieniu wszystkiego w PHP się nie spełni.

Jak akurat nie mialem takiej potrzeby, ograniczajac sie jedynie do php

Tego nie rozumiem, chodzi ci o to, że integrowałeś z innymi aplikacjami PHP czy jak?

Deprymujace jest to, ze w oficjalnych docs'ach brakuje wzmianki o jednym istotnym elemencie, ktory uniemozliwia zakonczone sukcesem odpalenie prezentowanego tam "Hallo World" 'a.
Kiedy juz sie dowiesz o co chodzi, grpc to jest kosmos.
Na kazdej plaszczyznie.
W skrocie, masz uczucie jakbys przesiadl sie z hulajnogi do ferrari.

To rozumiem, że działałeś ścieżką z tych docsów czyli pewnie korzystałeś z roszerzenia grpc z PECL?
Jak oceniasz kod boilerplate generowany z plików .proto, korzystałeś z tej funkcji?

AnyKtokolwiek napisał(a):

... akurat ogarniamy Go poza PHP.

Ja tez i co z tego?
Po co mieszac dwa stacki ze soba, jesli masz caly projekt w php i w pewnym momencie po prostu stajesz pod sciana, bo okazuje sie ze rest'y na nginx'ach nie daja rady?
Jesli D w SOLID to dla Ciebie nie jest wylacznie pytanie z rozmow rektrutacyjnych, a juz na pewno jesli PORTS nie kojarza Ci sie wylacznie ze statkami, a Adapters z winylowa plyta, to po kiego deformowac na sile spojny technologicznie stack?
Zwlaszcza w przypadku sporych platform, albo otoczenia, ktore niekoniczecznie musi podzielac Twoj entuzjazm dla go, lub jego brak dla php.

clonazepam napisał(a):

@proximus-prime To jak w takim razie wyglądało u ciebie to w projekcie? Musiałeś wystawić jakąś funkcjonalność dla innych systemów? Jak do tego podszedłeś?

Przede wszystkim musisz zaakceptowac fakt, ze json nie jest jedynym protokolem serializacji danych. Sa jeszcze inne, a w przypadku komunikacji gRPC jest to protobuf .
Reszta juz idzie z gorki. W zaleznosci od potrzeby kazdy serwis ma wpietego klienta, a komunikacja miedzy nimi odbywa sie w zaleznosci od potrzeby przez jeden centralny serwer albo kazdy z nich operuje za pomoca klienta i wlasnego serwera.

clonazepam napisał(a):

Bo w docs widzę od razu info:

"Note
You can only create gRPC clients in PHP.

To sie zgadza.

Use another language to create a gRPC server."

To info jest juz outdated. Istnieje juz serwer pieknie wspolpracujacy z PHP, malo tego, jego tworcy stworzyli nawet php'owy framework i jesli masz bezkrytyczny stosunek do Symfony, to na pewno Ci sie spodoba. Dla mnie Symfony (poza niektorymi komponentami) to najgorsza rzecz jaka sie mogla przytrafic PHP dlatego nie uzywam tego g...na, a wracajac do meritum, od jakiegos czasu, nawet w serwisach poza scope'em grpc uzywam tego serwera praktycznie wszedzie, bo jego integracja jest banalna, a spiecie xdbug'a nawet opisalem na ichnim forum.

clonazepam napisał(a):

Więc dlatego uznałem, że już moje marzenie o robieniu wszystkiego w PHP się nie spełni.

W php, da sie wszystko, w krancowych przypadkach po prostu piszesz swoje wlasne rozszerzenia w C lub C++

clonazepam napisał(a):

Tego nie rozumiem, chodzi ci o to, że integrowałeś z innymi aplikacjami PHP czy jak?

W skrocie, zawsze kiedy robilo sie ciasno (w odniesieniu do ilosci danych lub szybkosci transferu) wypiepszalem Guzzle i wpinalem customowego clienta grpc

clonazepam napisał(a):

To rozumiem, że działałeś ścieżką z tych docsów czyli pewnie korzystałeś z roszerzenia grpc z PECL?

Tak, zaczynalem dokladnie z tego samego miejsca co Ty: https://grpc.io/docs/languages/php/quickstart/

clonazepam napisał(a):

Jak oceniasz kod boilerplate generowany z plików .proto, korzystałeś z tej funkcji?

Powiem tylko tyle, ze w relatywnie krotkim czasie, znaczaco rozwinely sie moje kompetencje w wyrazaniu negatywnych emocji, za pomoca slownictwa powszechnie uznawanego za niewlasciwe.

proximus-prime napisał(a):

AnyKtokolwiek napisał(a):

... akurat ogarniamy Go poza PHP.

Ja tez i co z tego?
Po co mieszac dwa stacki ze soba, jesli masz caly projekt w php i w pewnym momencie po prostu stajesz pod sciana, bo okazuje sie ze rest'y na nginx'ach nie daja rady?

tu się zgadzam

Jesli D w SOLID to dla Ciebie nie jest wylacznie pytanie z rozmow rektrutacyjnych, a juz na pewno jesli PORTS nie kojarza Ci sie wylacznie ze statkami, a Adapters z winylowa plyta, to po kiego deformowac na sile spojny technologicznie stack?

co ma do tego D ?

clonazepam napisał(a):

Bo w docs widzę od razu info:

"Note
You can only create gRPC clients in PHP.

jak to niby sprawdza serwer ? ;)

W php, da sie wszystko, w krancowych przypadkach po prostu piszesz swoje wlasne rozszerzenia w C lub C++

i właśnei to samo chciałam zaproponować

clonazepam napisał(a):

Tego nie rozumiem, chodzi ci o to, że integrowałeś z innymi aplikacjami PHP czy jak?

W skrocie, zawsze kiedy robilo sie ciasno (w odniesieniu do ilosci danych lub szybkosci transferu) wypiepszalem Guzzle i wpinalem customowego clienta grpc

clonazepam napisał(a):

To rozumiem, że działałeś ścieżką z tych docsów czyli pewnie korzystałeś z roszerzenia grpc z PECL?

Tak, zaczynalem dokladnie z tego samego miejsca co Ty: https://grpc.io/docs/languages/php/quickstart/

clonazepam napisał(a):

Jak oceniasz kod boilerplate generowany z plików .proto, korzystałeś z tej funkcji?

Powiem tylko tyle, ze w relatywnie krotkim czasie, znaczaco rozwinely sie moje kompetencje w wyrazaniu negatywnych emocji, za pomoca slownictwa powszechnie uznawanego za niewlasciwe.