Generate optional service interfaces with JProtoc

[rmichela]

grpc-java won't generate interfaces for services because it isn't API safe. This make sense in the global sense, but isn't as much of an issue when you own all the code yourself.

Investigate the feasibility of generating client and server interfaces for gRPC stubs with JProtoc.

[kjarrio]

I have this. Both for clients and servers, but it still needs some work and testing though but eventually I'll get it cleaned up and pushed, might be a week or so.

[rmichela]

Fantastic! What do the generated interfaces look like?

[kjarrio]

Here's an example of the current state of the server/client interfaces. I'm still playing around with this but any input would be appreciated.

ServerAndClient.zip

[rmichela]

Thanks. I'll take a look.

[kjarrio]

Although this might be off topic for this issue....

I'd suggest moving away from mustache as a template engine, as it's extremely limited.

I'm currently using it to generate clients, servers, models and more for Java, Python and TypeScript+NodeJS. It's especially painful to use it for python because of the way Python handles white space and the templates tend to get very ugly to produce correct output. There might be a way to get it formatted in like I've already done with google-java-format but I haven't checked if there is a similar solution for Python, but I'm guessing it would be much harder to do that automatically though while maintaining the templates looking good.

Before migrating to jProtoc, I did try out the google api compiler, which uses a custom built engine seen here but I think it does too much - because it's almost a complete programming language built as a template engine. It's very interesting but again, too much for a template engine, in my opinion.

I've also had a look at protoc-gen-star from Lyft and it's very complete and efficient, but it's written in Go, and too complex for small or even medium sized projects/organizations.

The options that are worth considering are: Apache Velocity, Apache FreeMarker, or Handlebars.java (which just extends Mustache with the use of helpers)

Each of those has it's pros/cons:

• Velocity is heavily used within the Java Community, but it would break backwards compatibility with existing projects using jprotoc and mustache.

• FreeMarker, very powerful and similar to Velocity, but again, it would break compatibility.

• Handlebars, powerful and extendable, used heavily both within the Java Community and outside, and it's a superset of mustache, which means that it can replace mustache without breaking any existing projects using jprotoc and mustache.