gRPC in MicroProfile

362 views
Skip to first unread message

Emily Jiang

unread,
Jun 22, 2021, 7:22:58 AM6/22/21
to MicroProfile

Further to our technical call last week, I would like to open up an offline discussion on gRPC in MicroProfile. As you might be aware, in MicroProfile technical goals 2021, one goal is to evaluate whether to create gRPC spec in MicroProfile. Let's use this thread for our discussion on whether we need to adopt gRPC in MicroProfile. If yes, why. If not, why not. Please share your thoughts here.

Thanks
Emily

Reza Rahman

unread,
Jun 22, 2021, 7:28:26 AM6/22/21
to microp...@googlegroups.com
I think a Java binding specification for gRPC is definitely worth exploring. MicroProfile is the right place to do so.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Jun 22, 2021, at 7:23 AM, 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> wrote:



Further to our technical call last week, I would like to open up an offline discussion on gRPC in MicroProfile. As you might be aware, in MicroProfile technical goals 2021, one goal is to evaluate whether to create gRPC spec in MicroProfile. Let's use this thread for our discussion on whether we need to adopt gRPC in MicroProfile. If yes, why. If not, why not. Please share your thoughts here.

Thanks
Emily

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5b90f28e-fa5d-4253-ac56-149b9f85bc0fn%40googlegroups.com.

John Clingan

unread,
Jun 22, 2021, 10:56:33 AM6/22/21
to MicroProfile
Emily, I think a good place to start is outlining how gRPC in MicroProfile would differ from (or expand on) the Java work being done in the gRPC project.

Jean-Louis Monteiro

unread,
Jun 22, 2021, 11:18:31 AM6/22/21
to MicroProfile
Sounds interesting and a good place to do that


--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/66f5a0d0-8a84-45f8-9c2c-b7f3e1899aafn%40googlegroups.com.

Emily Jiang

unread,
Jun 22, 2021, 11:25:35 AM6/22/21
to MicroProfile
Hi John,
Sounds good. I just initiate this conversation and encourage others to join in for conversation. Any volunteers to drive this?
Thanks
Emily

Reza Rahman

unread,
Jun 22, 2021, 11:39:02 AM6/22/21
to microp...@googlegroups.com
This is a good point indeed. Maybe the right answer is to simply get the gRPC folks to have deeper integration with Jakarta EE including CDI? Regardless, an analysis in this project would be helpful.


Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Jun 22, 2021, at 10:56 AM, John Clingan <jtcl...@gmail.com> wrote:

Emily, I think a good place to start is outlining how gRPC in MicroProfile would differ from (or expand on) the Java work being done in the gRPC project.
--

Mark Little

unread,
Jun 22, 2021, 12:41:38 PM6/22/21
to microp...@googlegroups.com
+1

Sent from my iPad

On 22 Jun 2021, at 15:56, John Clingan <jtcl...@gmail.com> wrote:

Emily, I think a good place to start is outlining how gRPC in MicroProfile would differ from (or expand on) the Java work being done in the gRPC project.
--

Dmitry Kornilov

unread,
Jun 22, 2021, 2:13:28 PM6/22/21
to MicroProfile
First of all, I think that it's a good idea to standardize gRPC and popularize it as a Microprofile spec. I talked with Aleks Seovic and asked him to chime in. Aleks is a Coherence architect, and an author of Helidon gRPC implementation.

вторник, 22 июня 2021 г. в 18:41:38 UTC+2, markc...@gmail.com:

Aleksandar Seovic

unread,
Jun 22, 2021, 3:08:10 PM6/22/21
to MicroProfile
Thanks for the introduction, Dmitry.

I certainly agree with most/all who have responded so far, and believe adding official gRPC support to MP would be beneficial.

The way I see it, and to answer John's earlier question, there are a number of deficiencies in the base `grpc-java` implementation that make it less user friendly than it could be from a consumption perspective:

1. It doesn't play nicely with Java Module System, because it has shared packages across artifacts. I've opened the issue to address this almost 4 years ago (https://github.com/grpc/grpc-java/issues/3522). It is unfortunately still open even though it had quite a bit of activity and caused a lot of frustration to users over the years. 

2. It doesn't play nicely with CDI. Many classes generated by the grpc and protoc are final, or have final methods, which makes them unusable within CDI environment.

3. The overall feel is so 80s ;-) Writing IDLs and generating code from them feels like you are writing C/C++, not Java application.

4. It only works with Protobuf. Well, that's not entirely true -- the gRPC itself is completely agnostic to serialization format, and can be used with any supported marshaller. The problem is that the only marshaller supported by the standard tooling is Protobuf, and how to use something else is not even documented in any detail.

When we set out to implement gRPC support in Helidon (well, in Coherence actually, before we realized including it into Helidon made a lot more sense), we wanted it to be more along the lines of JAX-RS on the server, and MP REST Client on the client.

On the server you simply implement a CDI bean with some annotated methods, and provide additional metadata, such as service name and the marshaller to use, via class-level annotations. Here are a few examples of Helidon gRPC services:

https://github.com/helidon-sockshop/shipping/blob/master/shipping-core/src/main/java/io/helidon/examples/sockshop/shipping/ShippingResource.java (single class supports both JAX-RS and gRPC endpoint -- not something I'd recommend, but we wanted to show that it can be done for simple use cases)
https://github.com/coherence-community/todo-list-example/blob/master/java/helidon-server/src/main/java/com/oracle/coherence/examples/todo/server/grpc/ToDoListGrpcApi.java (slightly more complex service implementation, which uses POF for marshaling, and defines message types as nested classes) 

On the client, you simply define an annotated interface and let the framework create and inject proxy for you:


which can then be injected into another CDI bean and used like this:


Of course, everything works with other MP specs as well, such as Config, Metrics, etc.

And before anyone asks, yes, we can still use Protobuf (it's the default unless specified otherwise), and interop with clients and/or servers on other platforms. The goal was never to eliminate that as an option, but only to make development of both servers and clients *in Java* much simpler and integrated with other MP and Jakarta technologies.

In any case, if you like the examples above, I'd be happy to volunteer to lead the effort to standardize the approach as a proper MP spec. I think that would benefit the whole ecosystem way more than having it as a proprietary Helidon feature.

Cheers,
Aleks

Werner Keil

unread,
Jun 22, 2021, 3:49:33 PM6/22/21
to MicroProfile
Dmitry/Aleks,

What exactly should MicroProfile do to "standardize" gRPC if it's already standardized via CNCF?
I guess the only thing MP could do similar to Metrics (binding OpenTelemetry) the JWT project (offering a small layer between the JWT spec and CDI plus a few Jakarta EE specs like Authentication or Security) or OpenAPI would be a bit of glue because there is not much to specify or standardize that isn't already done there.

Obviously https://github.com/grpc/grpc-java has a solid API so there's nothing to define or trying to reinvent that would just be a waste of time.
So what standardizing is it that MP could do as opposed to what Helidon already does?

Are there multiple implementations for the API defined in io. e.g. another class like https://github.com/grpc/grpc-java/blob/master/netty/src/main/java/io/grpc/netty/AbstractHttp2Headers.java implementing  Http2Headers and similar?

But those are implementation specific, so where's the API for MicroProfile?

Or what about  It only works with Protobuf, that is also an implementation detail.

Trying to reinvent the wheel and create a whole new MP API based on the one that's already there, well all I'm saying is that did not seem to have worked that well for MP Metrics which is now pretty much thrown away in favor of Micrometer, so is it worth taking the same risk here?

Werner

Michał Szynkiewicz

unread,
Jun 22, 2021, 3:53:51 PM6/22/21
to MicroProfile
My 2 cents:

In Quarkus we went the other way around. We stayed close to grpc-java. We generate stuff with protoc but on top of the grpc-java stubs, we generate our own classes.
We still allow users to use grpc-java classes, but the most idiomatic way to do gRPC in Quarkus is to use an interface we generate.

E.g. for a proto file like todos.proto we generate an interface like Todos.java.
With it, a user can expose a service by creating an implementation of the interface and annotating it with @GrpcService (e.g. TodoService.java), or consume
a gRPC service by injecting the interface annotated with @GrpcClient, like in this test
It's all based on CDI, the calls have RequestScoped CDI context available.
I'd argue it's quite simple too. At a glance, seems to require less code than the Helidon approach because the user doesn't have to define the interface themself.
It also allowed us to be quite fast

FTR, the Uni and Multi types come from SmallRye Mutiny

Werner Keil

unread,
Jun 22, 2021, 4:14:54 PM6/22/21
to MicroProfile
Here are more interesting examples including use with Spring Boot and also a few Jakarta specs like JPA (still Jakarta EE 8 level I guess ;-)

So similar to what Michael said about Quarkus those examples use it on top of Spring Boot but without introducing any API or even implementation of their own.

The gRPC project not only the Java libraries contains various kinds of TCKs along the lines of https://github.com/grpc/grpc-java-api-checker, but also interoperability checkers to ensure, that you can e.g. write a server in Go or Node and a client in Java or Kotlin on an Android device or vice versa.

I admit and that is probably what Aleks meant with poor JPMS usage, that:
> src/main/java/com/example/App.java:10: error: [GrpcInternal] @Internal should not be used in application code System.out.println(InternalStatus.MESSAGE_KEY);
feels rather clumsy and I see no real need for this annotation because why not hide the internal packages using JPMS? ;-)

On the other hand the whole notion of "experimental" is a lot like what the JDK does with preview features but something e.g. most MicroProfile Specs and also Jakarta EE (particularly some of the new specs like MVC, NoSQL, etc.) could use a lot and have not even thought about so far, while these guys took care of those API stability and maturity aspects, therefore I would very much argue against trying to fork their API just for the sake of defining something new in MP.

Werner

Roberto Cortez

unread,
Jun 22, 2021, 7:13:49 PM6/22/21
to microp...@googlegroups.com
Hi,

My proposal is to push any work related with gRPC and MP into the sandbox and take it from there. This is how we agreed to do it for OpenTelemetry, and I believe gRPC is in the same situation.

Cheers,
Roberto

Aleksandar Seovic

unread,
Jun 22, 2021, 9:24:30 PM6/22/21
to MicroProfile
Just to be clear, as there seems to be a misunderstanding: Helidon gRPC doesn't *replace* grpc-java, or defines a "new" gRPC standard at the transport level, which is the only thing gRPC itself (via CNCF) standardizes. It uses grpc-java under the hood, and allows you to implement both the services and the clients in a way that is more along the lines of JAX-RS and MP REST Client, which we feel is cleaner and easier to grok by the average Java developer, and more consistent with the existing technologies in the MicroProfile stack.

Ultimately, gRPC in general, and grpc-java as one of its implementations, boil down to 4 supported method types: unary, server streaming, client streaming and bidirectional. Helidon gRPC allows you to define any of those by annotating Java method on a POJO with @Unary, @ServerStreaming, @ClientStreaming or @BiDirectional, just like JAX-RS allows you to define handlers for various HTTP methods via @Get, @Post, @Put, @Delete, etc.

Then there is also syntactic sugar we added to make the implementation simpler. Instead of always having to deal with gRPC StreamObserver, which tends to be cumbersome to use for by far the most common use case of unary methods, you can simply return the value and we'll complete the StreamObserver for you.

In other words, while you could define a method such as:

@Unary
public void hello(String name, StreamObserver<String> observer) {
    observer.onNext("Hello, " + name);
    observer.onCompleted();
}

it is simpler to write

@Unary
public String hello(String name) {
    return "Hello, " + name;
}

Similarly, for server streaming methods you can simply annotate it with @ServerStreaming, and return Stream or Iterable, and we'll do the right thing under the hood. I really don't see the point of types such as Uni or Multi that Quarkus provides, when Java already has a perfectly good way to represent both.

Of course, if you really want you can always use StreamObserver directly as well, just like you can use Response class in JAX-RS to have full control over the response.

Finally, by wrapping return type for any method with a CompletionStage, you turn the service implementation into an async one:

@Unary
public CompletionStage<String> hello(String name) {
    return CompletableFuture.completedFuture("Hello, " + name);  
    // pointless, but you get the idea -- it works very well with async and reactive backends
}

As for which requires less code, I'd rather write Java code than proto IDL, especially because the later *forces* you to use Protobuf as a marshaller. Not to mention that it requires that you configure protoc and gRPC compiler in your POM or Gradle file, generates a ton of mostly unreadable code, etc. 

We support all of that, but don't require it. For example, the code above won't work with Protobuf, because String is not a Protobuf Message, but it will work perfectly fine with many other serialization formats, such as Java serialization, JSONB and POF, that don't require special classes to be used as messages.

In the end, that's really all we are proposing when it comes to MP gRPC spec -- a set of developer-friendly annotations that allow you to implement gRPC services and clients in a way that is similar to what we are all used to from REST and JAX-RS, and a way to control marshaling so serialization formats other than Protobuf can be used (which is something gRPC itself supports, but the existing tooling doesn't).

- Aleks

Aleksandar Seovic

unread,
Jun 22, 2021, 9:31:43 PM6/22/21
to MicroProfile
Not quite -- what I meant is that grpc-java as-is is completely unusable in JPMS environment, because grpc-core and grpc-context modules both contain and export io.grpc package, and JPMS does not allow split packages across modules.

We had to repackage grpc-java and turn it into a proper JPMS module in order for it to work in Java 11 properly.

- Aleks

Reza Rahman

unread,
Jun 22, 2021, 10:24:19 PM6/22/21
to microp...@googlegroups.com
Barring some other significant insight, honestly this seems like a pretty sensible MicroProfile specification most Jakarta EE ecosystem developers should find pretty intuitive. I definitely like the symmetry with JAX-RS/CDI.


Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Jun 22, 2021, at 9:24 PM, Aleksandar Seovic <aleks....@gmail.com> wrote:

Just to be clear, as there seems to be a misunderstanding: Helidon gRPC doesn't *replace* grpc-java, or defines a "new" gRPC standard at the transport level, which is the only thing gRPC itself (via CNCF) standardizes. It uses grpc-java under the hood, and allows you to implement both the services and the clients in a way that is more along the lines of JAX-RS and MP REST Client, which we feel is cleaner and easier to grok by the average Java developer, and more consistent with the existing technologies in the MicroProfile stack.

Dmitry Kornilov

unread,
Jun 23, 2021, 4:44:30 AM6/23/21
to MicroProfile
Is there any official process for proposing a new MicroProfile specification similar to what we do in Jakarta? I mean project proposal, public review, etc.

-- Dmitry
среда, 23 июня 2021 г. в 01:13:49 UTC+2, radc...@yahoo.com:

Emily Jiang

unread,
Jun 23, 2021, 11:16:09 AM6/23/21
to MicroProfile
Great question Dimtry! I think we should use the standard plan review process similar to what Jakarta does and then go through the ballot. When we started the release process for MP 4.0, we did the release template first and thought to add the rest templates later. Now, it is time to put the other part of the formal process in place. I think it is much better to formalise this so that we can move forward.

Thanks
Emily


You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/OQQUiN0RUso/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/98c10a4e-2a93-46e4-81f1-00971c805been%40googlegroups.com.


--
Thanks
Emily

Amelia Eiras

unread,
Jun 23, 2021, 12:40:48 PM6/23/21
to MPCommunity
I am +1 to Roberto's suggestion to follow the MP usage of the sandbox on new potential API's iterations instead of baking them into the MP API and process. Light creates and welcomes more innovation and lowers the bar to entry.  1 - lower bar to entry is one of the 7 core goals of MP. 

My proposal is to push any work related with gRPC and MP into the sandbox and take it from there. This is how we agreed to do it for OpenTelemetry, and I believe gRPC is in the same situation.- RC



To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A-wbF0fT7%2B1B_qxtpK81BHWfztiZFHdWOfQgL%3D5WkkG9A%40mail.gmail.com.

Dmitry Kornilov

unread,
Jun 23, 2021, 12:55:40 PM6/23/21
to MicroProfile
It could be a stupid question, but what 'pushing to sandbox' exactly means? Is it a way to propose a new spec? There must be a written process ratified by the WG. This process must be open, vendor neutral and consistent.

-- Dmitry

среда, 23 июня 2021 г. в 18:40:48 UTC+2, Amelia Eiras:

Reza Rahman

unread,
Jun 23, 2021, 1:02:07 PM6/23/21
to microp...@googlegroups.com
To be completely honest I have found this confusing too. It definitely does not feel much like specification or standards development.

It would be good to get this sorted properly.


Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Jun 23, 2021, at 12:55 PM, Dmitry Kornilov <maid...@gmail.com> wrote:

It could be a stupid question, but what 'pushing to sandbox' exactly means? Is it a way to propose a new spec? There must be a written process ratified by the WG. This process must be open, vendor neutral and consistent.

Roberto Cortez

unread,
Jun 23, 2021, 1:10:31 PM6/23/21
to microp...@googlegroups.com
Hi, 

So usually this is how we operated in the past to propose new ideas and work on something. This allows us to experiment and try out stuff without any pressure to make a spec out of it. Maybe with the new WG governance we need to ratify this in a better way, but right now here is the documented process:



Cheers,
Roberto

Mark Little

unread,
Jun 23, 2021, 1:25:11 PM6/23/21
to microp...@googlegroups.com
Agreed. No need for a new spec effort unless there's a spec that needs to be created and so far I don't think there's enough information to make a clear determination. MicroProfile should not create specs for the sake of it and especially if there are already specs elsewhere.

Sent from my iPhone

On 23 Jun 2021, at 18:10, 'Roberto Cortez' via MicroProfile <microp...@googlegroups.com> wrote:

Hi, 

Dmitry Kornilov

unread,
Jun 23, 2021, 1:45:17 PM6/23/21
to microp...@googlegroups.com
Discussion, review and answering question why the spec needed must be a part of the process for proposing a new spec which is currently not defined. Let’s define it first.

Ср, 23 июня 2021 г. в 19:25, Mark Little <markc...@gmail.com>:

John Clingan

unread,
Jun 23, 2021, 1:56:21 PM6/23/21
to MicroProfile
I ditto Amelia and Reza. Sandbox first.

Mark Little

unread,
Jun 23, 2021, 2:16:23 PM6/23/21
to 'Emily Jiang' via MicroProfile
Sandbox first.

Ed Bratt

unread,
Jun 23, 2021, 2:24:55 PM6/23/21
to microp...@googlegroups.com
There are multiple vendor implementations that provide different approaches to solving the same problem. This seems like the perfect premise for trying to establish a standard -- that will present a consistent and familiar framework for MicroProfile developers.

CNCF isn't burdened by any need to try to be similar to MicroProfile, Jakarta REST, or CDI. That's where this effort sure appears poised to build upon and add value for the MicroProfile community.

If this makes any sense, simply summarizing the technical points (where they align and where they are in dissonance) is probably all that would be needed to kick off a Spec. proposal. The implementations and reconciliations needed to bring alignment for our community is what the Spec. development process ought to be about (in my opinion).

Sure seems like we already have what sandbox would provide, but if that's the formalism, so be it.

How to introduce new specifications probably ought to be included in the general on-boarding materials, including what is expected in order to "graduate"  -- perhaps it already is. Is this described in a document someplace?

-- Ed

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/45289CFC-5F44-4BE0-AD26-21DE8301F49A%40gmail.com.

Dmitry Kornilov

unread,
Jun 23, 2021, 2:39:57 PM6/23/21
to microp...@googlegroups.com
Fine. What’s after sandbox?

Ср, 23 июня 2021 г. в 19:56, John Clingan <jtcl...@gmail.com>:

Reza Rahman

unread,
Jun 23, 2021, 2:47:59 PM6/23/21
to microp...@googlegroups.com
gRPC is clearly an emerging but promising area. It would be great to have a more vendor neutral answer for the Jakarta EE ecosystem.

That said, if the sandbox concept is the consistent and fair cultural norm for MicroProfile, I don’t see any harm in trying that first. It sounds like it doesn’t really preclude the possibility of submitting a more concrete specification proposal once there is more alignment, especially amongst who would ultimately vote in a working group consensus and provide implementations.


Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Jun 23, 2021, at 2:24 PM, Ed Bratt <edwar...@gmail.com> wrote:



Werner Keil

unread,
Jun 23, 2021, 5:11:15 PM6/23/21
to MicroProfile
I also see no problem with the sandbox. I have not observed OpenTelemetry as much as the earlier MP Metrics API and project, but looking at how that went, I wish that had also been in the Sandbox first avoiding a lot of confusion and need to change and break things for consumers...

Where in https://github.com/eclipse/microprofile-sandbox is the OpenTelemetry sandbox or does that not exist yet?

Werner

Emily Jiang

unread,
Jun 23, 2021, 6:30:39 PM6/23/21
to MicroProfile
It's fine to put the proposal on the sandbox. It does need to have a next step. In the past, the community discussed the idea and then decided whether to create a spec from the sandbox proposal. Since MicroProfile has its own working group, I suggest we should do something more formal. After some conversations with the sandbox ideas, a ballot should be called for a plan creation review. In this way, we would be able to discuss the spec idea and then conclude it formally.
Thanks,
Emily



To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALgpM5QU7%3DG43%2BVm5bC2H7etovcE%3DanzryzFBw3Ef8PawiENdQ%40mail.gmail.com.


--
Thanks
Emily

Werner Keil

unread,
Jun 24, 2021, 3:22:58 PM6/24/21
to MicroProfile
And what about Telemetry, or is that still subject to a creation vote in the sandbox?

Werner

Roberto Cortez

unread,
Jun 25, 2021, 6:02:11 AM6/25/21
to microp...@googlegroups.com
Hi Werner,

In one of our last technical calls we agreed to push any OpenTelemetry work to the sandbox, so feel free to start something if nothing is there yet.

Cheers,
Roberto

Reply all
Reply to author
Forward
0 new messages