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() <https://grpc.github.io/grpc/cpp/classgrpc_1_1_server.html#ad48818dac08e28a2ea3694d1f5462c6b> to create an in-process channel. On Tue, Jul 18, 2023 at 8:12 AM Pablo Odorico <pablo.odor...@gmail.com> wrote: > 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 > > -- > 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+unsubscr...@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 > <https://groups.google.com/d/msgid/grpc-io/5cef2619-d835-4b7e-b295-52b88c1fc28bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Mark D. Roth <r...@google.com> Software Engineer Google, Inc. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAJgPXp7YyuzD28224uNavRzgcyu8rXuT4aZagsuViFUOEyGz%2BQ%40mail.gmail.com.
