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

Right. Here we are talking about a gRPC representation of the client server interactions. Not the data schema stored in ISPN. In that model, the API is compiled by us and handed over as a package. On 29 May 2018, at 15:51, Sanne Grinovero <sanne(a)infinispan.org <mailto:sanne@infinispan.org>> wrote: > > > On 29 May 2018 at 13:45, Vittorio Rigamonti <vrigamon(a)redhat.com > <mailto:vrigamon@redhat.com>> wrote: > > Thanks Adrian, > > of course there's a marshalling work under the cover and that is > reflected into the generated code (specially the accessor methods > generated from the oneof clause). > > My opinion is that on the client side this could be accepted, as > long as the API are well defined and documented: application > developer can build an adhoc decorator on the top if needed. The > alternative to this is to develop a protostream equivalent for > each supported language and it doesn't seem really feasible to me. > > > ​This might indeed be reasonable for some developers, some languages. > > Just please make sure it's not the only option, as many other > developers will not expect to need a compiler at hand in various > stages of the application lifecycle. > > For example when deploying a JPA model into an appserver, or just > booting Hibernate in JavaSE as well, there is a strong expectation > that we'll be able - at runtime - to inspect the listed Java POJOs > via reflection and automatically generate whatever Infinispan will need. > > Perhaps a key differentiator is between invoking Infinispan APIs > (RPC) vs defining the object models and related CODECs for keys, > values, streams and query results? It might get a bit more fuzzy to > differentiate them for custom functions but I guess we can draw a > line somewhere. > > Thanks, > Sanne > > > On the server side (java only) the situation is different: > protobuf is optimized for streaming not for storing so probably a > Protostream layer is needed. > > On Mon, May 28, 2018 at 4:47 PM, Adrian Nistor > <anistor(a)redhat.com <mailto:anistor@redhat.com>> 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(a)redhat.com <mailto:vrigamon@redhat.com> >> >> irc: rigazilla >> >> <https://red.ht/sig> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> <mailto:infinispan-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> <https://lists.jboss.org/mailman/listinfo/infinispan-dev> > > > > > > -- > > Vittorio Rigamonti > > Senior Software Engineer > > Red Hat > > <https://www.redhat.com> > > Milan, Italy > > vrigamon(a)redhat.com <mailto:vrigamon@redhat.com> > > irc: rigazilla > > <https://red.ht/sig> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev