gRPC as dynamic library interface (no network stack or IPC)

[Pablo Odorico]

Hello,

Imagine you are tasked with writing a C++ library to be used both as a DLL for an application your company ships and also as the core of a backend cloud service.

The library API relies on many structs and the overhead of using protobuffers is deemed justifiable to obtain easily serializable traces and APIs that remain stable as structs change.

Using gRPC on the cloud backend service is a brainer, but could it also be used to define the library API for the application to use? I'm talking about generating dummy client/server stubs which don't do any networking, IPC (client and server are on the same process) or even make syscalls. From what I understand the DLL would only be exporting read/write calls.

The main benefit would be maintaining a single API IDL schema. In this case it's also desirable to obfuscate the API of the DLL being shipped to the end user (by not exporting any library APIs).

Maybe a different tool like FIDL (by the Fuchsia project) could be a better fit to handle the DLL use case, but I will need the gRPC API for the cloud service anyway so it would be great gRPC could cover both use cases.

Any ideas?

Thanks,
Pablo

[Mark D. Roth]

The closest thing we currently have to this is the in-process transport, which uses the normal gRPC API but speaks to another process on the same machine instead of using the networking stack.  This still uses IPC, but it avoids all of the overhead of TCP, HTTP/2, and gRPC framing on the wire.  Unfortunately, the way this is currently implemented, the protobufs will still be serialized and deserialized, which ideally shouldn't be necessary; we do plan to fix that at some point, but there's no ETA for that.

If you want to play with this, you can use it by creating a server and then calling Server::InProcessChannel() to create an in-process channel.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5cef2619-d835-4b7e-b295-52b88c1fc28bn%40googlegroups.com.

--

Mark D. Roth <ro...@google.com>
Software Engineer
Google, Inc.

[Pablo Odorico]

Hello Mark,

Thank you for your response, I'll take a look at the in-process transport.
I didn't think about avoiding (de-)serializing the protobufs, but now
that you mention it it would make a lot of sense.

Regards,
Pablo