Am Dienstag, 16. Oktober 2018 00:40:58 UTC+2 schrieb Christopher Warrington
- MSFT:
>
>
> By imposing these restrictions atop the gRPC++ library, we were able to
> simplify implementation of async services [8]:
>
class GreeterServiceImpl final : public Greeter::Service
> {
> public:
> using Greeter::Service::Service;
>
> private:
> void SayHello(bond::ext::grpc::unary_call<HelloRequest,
> HelloReply> call) override
> {
> HelloRequest request = call.request().Deserialize();
>
> HelloReply reply;
> reply.message = "hello " + request.name;
>
> call.Finish(reply);
> }
> };
>
>
Wow, that's pretty neat. It looks almost as tidy as the Sync Service did.
Thanks for posting.
Only thing I would have with it is, the fact that the async approach forced
me to take the route with the one class per call approach was one of the
few things I liked about it. With a service of, say, 50 methods a class
containing all the impls can grow tremendously. Even if each call is very
much separated from the others. Few years back we had some static analysis
run over the code that showed glowing red complexity dots over those files.
Probably due to size, because they weren't this complex. I hope this gets
better with the one-class-per-call way.
Cheers,
Stephan
PS: Amazed Microsoft uses gRPC. And open sources the results. The world we
live in.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/4143c4ac-b0cf-4b8e-acb8-bcfabdddba14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
