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 On Wed, Aug 16, 2023 at 8:19 PM Mark D. Roth <r...@google.com> wrote: > > 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. > > > > 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. > > > > -- > 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/CAFuUJFgdsBN%2BQ%2BMHTtbAJzx8jUmNLXydkoVJCB4oK6k7NRrxeg%40mail.gmail.com.
