Vittorio, a few remarks regarding your statement "...The alternative to
this is to develop a protostream equivalent for each supported language
and it doesn't seem really feasible to me."
No way! That's a big misunderstanding. We do not need to re-implement
the protostream library in C/C++/C# or any new supported language.
Protostream is just for Java and it is compatible with Google's protobuf
lib we already use in the other clients. We can continue using Google's
protobuf lib for these clients, with or without gRPC.
Protostream does not handle protobuf services as gRPC does, but we can
add support for that with little effort.
The real problem here is if we want to replace our hot rod invocation
protocol with gRPC to save on the effort of implementing and maintaining
hot rod in all those clients. I wonder why the obvious question is being
avoided in this thread.
Adrian
On 05/29/2018 03:45 PM, Vittorio Rigamonti 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.
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 <anis...@redhat.com
<mailto:anis...@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
vriga...@redhat.com <mailto:vriga...@redhat.com>
irc: rigazilla
<https://red.ht/sig>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@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
vriga...@redhat.com <mailto:vriga...@redhat.com>
irc: rigazilla
<https://red.ht/sig>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
