francoischabot/easy_grpc

An easier way to write asynchronous c++ grpc clients/servers.

easy_grpc's Issues

Removed hard protobuf dependency in the easy_grpc library

The current linking against protobuf::libprotobuf is just lazyness. It's only ever needed for the included serialization shortcuts, and can be left to the clients.

Support Channel arguments

Support secure channels

Production build process

The current packaged with easy_grpc is basically only suited for testing.

(as a side-note, if we do switch to a header-only library, then this becomes a non-issue.)

Alternate Completion queue consumption schemes.

Specifically, it should be possible to consume from a queue from an application's main thread.

Bazel support

While the library and protoc plugin are not exactly hard to compile, everything is CMake-based at the moment.

Non-protobuf API is not clean enough

as tests/binary_protocol.cpp illustrates, writing a service around non-autogerated code is not nearly as clean as it could be.

Consider inverting the service/impl relationship

class Service_impl {
  Future<Reply> Method(const Request& req) {
  };
};

...

int main() {
  pkg::Service::Service<Service_impl> impl_;
  ...
}

This is kinda neat because it gets rid of the extra vtable call. It's not like services are mocked at the service level anyways.

gcov/lcov is having trouble with easy_rpc::Future<>

The problem is that the various handler have to instantiate many methods regardless of wether they are invoked or not for each T. So to get full coverage, every type/handler pair used during testing needs to go trough the finish/fullfull/fail paths, which would require a lot of redundant code...

Consider making the library header-only

On one hand, Now that the dust is settling. There's now that much non-templated code in the project.

On the other hand, once the CMakeLists.txt has proper install/subdirectory inclusion support, the barrier to entry should be low enough.

Conveniently, this would also take care of #2.

I'm open to opinions on this.

Automated port selector for unit tests

Since many tests are opening ports and connecting to them, we need to find a way to stop them from stomping on each other so that we can run them with ctest -j $(nproc)