[feature] In-process Transport

[timburks]

The gRPC C core currently supports multiple transports including an in-process transport. According to the gRPC team, this is "quite popular for hermetic testing" and is being added to other gRPC implementations. gRPC-Java currently has it and work is underway to have this in gRPC-Go in another quarter or two.

There have been requests for this in gRPC-Swift. I haven't verified this, but presumably it would be easy to enable this in the cgrpc implementation. Are we interested in adding it to the NIO version?

[vyshane]

I will definitely use this feature in the NIO version. I'm writing a library that integrates Swift gRPC with Apple's Combine framework, and I'm currently going over the network for my end-to-end tests. It would be useful to be able to keep these in-process.

[glbrntt]

I definitely see the value in this.

I'm not sure what this would look like at the moment. We might have to implement another NIO.Channel and target (i.e. in the client/server Configuration) to connect/bind to. That would minimise the differences in setup and use from the user perspective.

[MrMage]

This sounds like using NIO's EmbeddedChannel?

[glbrntt]

It depends on the use case: EmbeddedChannel uses EmbeddedEventLoop which doesn't have a proper eventing mechanism so you have to manually read from the channel (and you need to write some glue to go between the client and server channels) which is fine for unit tests but probably not ideal for end-to-end tests. The same goes for time: the user of the EmbeddedEventLoop has to manually advance time which also doesn't seem appropriate here.

One possibility could be using a PipeChannel (https://apple.github.io/swift-nio/docs/current/NIO/Classes/NIOPipeBootstrap.html) but we'd need to look into this some more!

[MrMage]

That makes sense, I was not aware of the difference. Thank you for the elaboration!

[MrMage]

@glbrntt have we fully resolved this yet by using EmbeddedChannel in tests?

[glbrntt]

Not quite: the EmbeddedChannel client and use on the server is purely internal at this point. It's also quite manual, you have to tell two embedded channels to exchange messages in a loop. We should keep this one open.