Thread overview
good RPC framework for D?
Jun 06, 2017
Timothee Cour
Jun 06, 2017
Neia Neutuladh
Jun 06, 2017
Laeeth Isharc
Aug 09, 2017
jasonsalex
June 05, 2017
Is there a good RPC framework for D?

requirements:
* efficient (no json/xml)
* supports at least sending/receiving raw bytes

I tried msgpack-rpc but it seems abandonned (last commit 2 y ago) and this issue makes it unusable: https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for messages of length >= 4090 bytes.

I would love to have a GRPC work with D but couldn't find a package for it.

Is there at least a reliable solution that sends raw bytes ? than I can for eg wrap protobufs or other serialized formats via serialization/deserialization.

Additional requirements: supports streaming data (either input or
output or both), and timeouts.
June 06, 2017
On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:
> Is there a good RPC framework for D?

Last time I needed one, I used Thrift. D support in Thrift is maintained upstream. Unfortunately, the version available in dub is really old. Also unfortunately, it's std.socket only -- no vibe.d.

https://thrift.apache.org/docs/features
https://github.com/apache/thrift/tree/master/lib/d

> requirements:
> * efficient (no json/xml)

Thrift uses a binary format relatively similar to protocol buffers.

> * supports at least sending/receiving raw bytes

Thrift supports a `binary` data type representing a byte array.

> Additional requirements: supports streaming data (either input or output or both)

I'm not sure what you mean by "streaming data", precisely, but Thrift supports multiple RPCs per  connection. This alone made a huge difference in my testing: a Thrift server on an AWS t2.micro  managed 2400 requests per second across ten clients, while HTTP handlers returning a fixed string only managed 75.

> and timeouts.

Definitely supports timeouts.
June 06, 2017
On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:
> Is there a good RPC framework for D?
>
> requirements:
> * efficient (no json/xml)
> * supports at least sending/receiving raw bytes
>
> I tried msgpack-rpc but it seems abandonned (last commit 2 y ago) and this issue makes it unusable: https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for messages of length >= 4090 bytes.
>
> I would love to have a GRPC work with D but couldn't find a package for it.
>
> Is there at least a reliable solution that sends raw bytes ? than I can for eg wrap protobufs or other serialized formats via serialization/deserialization.
>
> Additional requirements: supports streaming data (either input or
> output or both), and timeouts.

I am working right now on wrapping grpc, but it's a bit of work and I have lots of other things to do and can't be sure when or if I will finish.  The C API is not that bad once you understand what if is doing.  And see dprotobuf.


June 06, 2017
On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:
> Is there at least a reliable solution that sends raw bytes ? than I can for eg wrap protobufs or other serialized formats via serialization/deserialization.
>
> Additional requirements: supports streaming data (either input or
> output or both), and timeouts.

Sounds like you want to use a raw TCP/IP connection...
August 09, 2017
On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:
> Is there a good RPC framework for D?
>
> requirements:
> * efficient (no json/xml)
> * supports at least sending/receiving raw bytes
>
> I tried msgpack-rpc but it seems abandonned (last commit 2 y ago) and this issue makes it unusable: https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for messages of length >= 4090 bytes.
>
> I would love to have a GRPC work with D but couldn't find a package for it.
>
> Is there at least a reliable solution that sends raw bytes ? than I can for eg wrap protobufs or other serialized formats via serialization/deserialization.
>
> Additional requirements: supports streaming data (either input or
> output or both), and timeouts.


KissRPC For Flatbuffer : https://github.com/huntlabs/kiss-rpc

kiss-rpc-flatbuffer features:

Lightweight and easy to use. There are two ways to support IDL and manually write protocols. Analog function call, more in line with the RPC remote call logic, simple, transparent.

Easy to change, easy to use, existing code can be used directly

The data format supports downward compatibility and uses the flatbuffer protocol, with better compatibility and faster speed.

Support multi valued return feature, support timeout mechanism, analog grpc, thrift, Dubbo fast several times or even dozens of times.

Support snappy compression algorithm, compression speed, superior performance.

Support pipeline data compression, dynamic data compression, request data compression, flexible use of a wide range of scenarios.