Feature Discussion Relative to Other Options

[ChristopherDavenport]

Hey all wanted to make a space to discuss what features we need/want. What already exists, what we want to prioritize etc.

So lets talk gRPC features!

[ChristopherDavenport]

So primary features that I see and know.

1. Compression: we currently only support identity, but should be able to easily support gzip
2. Stream Retries: (on Goaway we should be able to retry, but honestly I think this belong in Ember Client rather than here)
3. Helper Methods for Binary/Ascii Headers (ascii is easy, binary a bit trickier)
4. Grpc-Message-type encoding into Headers(percent encoding is a little weird) in requests
5. Communicating the deadline in some way to clients so they can forward the elapsed time and communicate how much time is left on other client calls, etc.
6. Response Metadata - This one is easily doable with Headers, but then makes the signature ugly. Currently I like our signatures so we'll need to think on this one.
7. gRPC Status - We need client cancellation, other error types to create different grpc-message
8. grpc-web functionality - This is a different set of functionality with a different encoding. Its similar but different enough that it likely needs something to do this, this functionality could be independent of ember as it runs over http/1.1 and should be able to have a js browser implementation as well.

[ahjohannessen]

Some sort of equivalent for manged channel with sub channels seems to be something that I would need if I were to replace fs2-grpc with this. Not saying one to one copy from grpc-java as it is a complexity jungle. However, when using grpc to communicate with a cluster of nodes, e.g. eventstore db, this is very useful as a managed channel can shield a client from handling leader/follower role changes and so on.

fs2-grpc has the concept of parameterized metadata for context, e.g. T => F[Headers/Metadata] and Headers/Metadata => F[T]. The code generator generates methods that give methods with T, sometimes that is just identity, i.e. T is Headers.

Error handling / adapters, Status runtime exceptions related to point 7.

grpc-java is battle-tested with respect to protocol behavior. Probably a good idea to see how other grpc implementations do test harness in order to verify implementation.

[ChristopherDavenport]

Per the channel - That one I'm not sure what that would look like. Its basically abstracting over the concept of the client, which should be doable but we'd need to know how we're having that communicated. Which I dont see inside the grpc specification. Can you point me to any documentation on what that management looks like at a protocol level?

Per parameterization, its easy to generate. I opted for this because it creates a much simpler interface that's in my opinion is easier to understand. Essentially its the concept of ContextRequest vs Request in Http4s, and I think both have a place depending on what you want to operate with. We can consider how we can support both in code-generation.

Definitely agree with you on figuring out a harness to confirm behavior. I've tested that it works on both client/server with fs2-grpc. But that is very minimal compared to the suite I'm sure grpc-java has done.

[ahjohannessen]

Per the channel - That one I'm not sure what that would look like. Its basically abstracting over the concept of the client, which should be doable but we'd need to know how we're having that communicated. Which I dont see inside the grpc specification. Can you point me to any documentation on what that management looks like at a protocol level?

Not much to find about channel specification. The only thing I see is this and then the code itself. It seems that grpc-java managed channel is over-engineered in true java enterprise style. However, despite that, it is a very useful construct that moves the burden some recurring crosscutting concerns from the user to the library.

Per parameterization, its easy to generate. I opted for this because it creates a much simpler interface that's in my opinion is easier to understand. Essentially its the concept of ContextRequest vs Request in Http4s, and I think both have a place depending on what you want to operate with. We can consider how we can support both in code-generation.

I agree that it is simpler, but not sure it is much simpler. I suppose you are thinking that you can create extension methods on Headers that essentially do what I wrote earlier. Not critical if parameterization is not there from the start.

Definitely agree with you on figuring out a harness to confirm behavior. I've tested that it works on both client/server with fs2-grpc. But that is very minimal compared to the suite I'm sure grpc-java has done.

This could be useful to look more into.

[lacarvalho91]

Server and client middlewares would be great, am I right in thinking we'll just be able to plug in http4s middlewares?

[armanbilge]

am I right in thinking we'll just be able to plug in http4s middlewares?

Yes, that's right :)

[Jasper-M]

Compression: we currently only support identity, but should be able to easily support gzip

Couldn't a user just apply the GZip client or server middleware?

[armanbilge]

Not sure, I think the gRPC spec has its own requirements.

https://github.com/grpc/grpc/blob/master/doc/compression.md

[hamnis]

Client cancellation or something else is needed to make google-bigquery-storage to work.

I have a mostly working of a pure http4s version of bigquery client now, but I cant stop a stream once it has started, that can only be done on the server side it seems.