[infinispan-dev] Infinispan client/server architecture based on gRPC

[Bela Ban]

FYI, I've also been looking into gRPC, as a tool to provide a (JGroups) 
version-independent service that all traffic is sent to and received 
from during a rolling cluster upgrade [1].

The focus of this is *version independence*, ie. have 3.6 and 4.x nodes 
talk to each other. A non-requirement is performance or memory 
consumption, as the service is only used during an upgrade (typically a 
couple of seconds).

[1] 
https://github.com/jgroups-extras/RollingUpgrades/blob/master/common/src/main/proto/relay.proto

On 28/05/18 16:47, Adrian Nistor wrote:
> Hi Vittorio,
> thanks for exploring gRPC. It seems like a very elegant solution for 
> exposing services. I'll have a look at your PoC soon.
> 
> I feel there are some remarks that need to be made regarding gRPC. gRPC 
> is just some nice cheesy topping on top of protobuf. Google's 
> implementation of protobuf, to be more precise.
> It does not need handwritten marshallers, but the 'No need for 
> marshaller' does not accurately describe it. Marshallers are needed and 
> are generated under the cover by the library and so are the data objects 
> and you are unfortunately forced to use them. That's both the good news 
> and the bad news:) The whole thing looks very promising and friendly for 
> many uses cases, especially for demos and PoCs :))). Nobody wants to 
> write those marshallers. But it starts to become a nuisance if you want 
> to use your own data objects.
> There is also the ugliness and excessive memory footprint of the 
> generated code, which is the reason Infinispan did not adopt the 
> protobuf-java library although it did adopt protobuf as an encoding format.
> The Protostream library was created as an alternative implementation to 
> solve the aforementioned problems with the generated code. It solves 
> this by letting the user provide their own data objects. And for the 
> marshallers it gives you two options: a) write the marshaller yourself 
> (hated), b) annotated your data objects and the marshaller gets 
> generated (loved). Protostream does not currently support service 
> definitions right now but this is something I started to investigate 
> recently after Galder asked me if I think it's doable. I think I'll only 
> find out after I do it:)
> 
> Adrian
> 
> On 05/28/2018 04:15 PM, Vittorio Rigamonti wrote:
>> Hi Infinispan developers,
>>
>> I'm working on a solution for developers who need to access Infinispan 
>> services  through different programming languages.
>>
>> The focus is not on developing a full featured client, but rather 
>> discover the value and the limits of this approach.
>>
>> - is it possible to automatically generate useful clients in different 
>> languages?
>> - can that clients interoperate on the same cache with the same data 
>> types?
>>
>> I came out with a small prototype that I would like to submit to you 
>> and on which I would like to gather your impressions.
>>
>>  You can found the project here [1]: is a gRPC-based client/server 
>> architecture for Infinispan based on and EmbeddedCache, with very few 
>> features exposed atm.
>>
>> Currently the project is nothing more than a poc with the following 
>> interesting features:
>>
>> - client can be generated in all the grpc supported language: java, 
>> go, c++ examples are provided;
>> - the interface is full typed. No need for marshaller and clients 
>> build in different language can cooperate on the same cache;
>>
>> The second item is my preferred one beacuse it frees the developer 
>> from data marshalling.
>>
>> What do you think about?
>> Sounds interesting?
>> Can you see any flaw?
>>
>> There's also a list of issues for the future [2], basically I would 
>> like to investigate these questions:
>> How far this architecture can go?
>> Topology, events, queries... how many of the Infinispan features can 
>> be fit in a grpc architecture?
>>
>> Thank you
>> Vittorio
>>
>> [1] https://github.com/rigazilla/ispn-grpc 
>> <https://github.com/rigazilla/ispn-grpc>
>> [2] https://github.com/rigazilla/ispn-grpc/issues 
>> <https://github.com/rigazilla/ispn-grpc/issues>
>>
>> -- 
>>
>> Vittorio Rigamonti
>>
>> Senior Software Engineer
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> Milan, Italy
>>
>> vrigamon at redhat.com <mailto:vrigamon at redhat.com>
>>
>> irc: rigazilla
>>
>> <https://red.ht/sig>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

-- 
Bela Ban | http://www.jgroups.org