gRPC in D good idea for GSOC 2018?

[Adrian Matoga]

On Monday, 15 January 2018 at 19:28:08 UTC, Ali Çehreli wrote:
> I know a project where D could benefit from gRPC in D, which is 
> not among the supported languages:
>
>   https://grpc.io/docs/
>
> Do you think gRPC support is worth adding to GSOC 2018 ideas?
>
>   https://wiki.dlang.org/GSOC_2018_Ideas
>
> Ali

I can share a fresh experience from mentoring a student in a 
similar (also RPC) project last summer. We built native D-Bus 
bindings in D based on libasync. The student had had no previous 
experience with D or RPC, and within ~2.5 months of focused work 
she implemented the following:

1. (de)serialization of all D-Bus data types, including the use 
of compile-time reflection to recursively marshall structs, 
arrays, and variants. Except Variant, for which we decided to 
make our own D-Bus-specific tagged union type, all other D-Bus 
types are mapped to built-in D types.
2. A class to connect to the bus via libasync sockets, read the 
incoming messages and dispatch them to the registered handlers, 
and send messages to the bus.
3. Proxy (client) and server class templates that generate all 
the code necessary to make the remote calls look almost like 
local ones (the return value/out arguments are passed to a 
delegate that handles the output instead of being returned 
synchronously).

So, more or less an equivalent of vibe.d's REST interface 
generator, only with fewer customization points.

There were still some opportunities for refactorings and 
optimizations, so I wouldn't consider it production ready. Also, 
some planned features weren't implemented, such as a more 
convenient way for handling signals or allowing transports other 
than unix sockets on libasync. On the other hand, what we have is 
almost 100% covered with unit tests. This not only made adding 
successive layers quite pleasant, as little (if any) debugging of 
previously written stuff was ever necessary, but also helps to 
keep the stuff working as we modify it.

Based on my experience, I'd say that implementing gRPC may be of 
a right size for a GSoC project, as long as you split it into 
smaller components/layers, prioritize them, and focus on having 
at least the basic stuff usable and tested, instead of expecting 
it to cover all usage cases and be heavily optimized.