RPC vs RESTful

[chbfiv googl]

First, this looks amazing. I'm only having trouble with the tight coupling of RPC client and server and was hoping to get some feedback on why an RPC implementation would be a better approach. I'll give a simple example:

Android Slot Game with Tokens and Spin server.

Server provides token balance and spin results.

Does every release of of a new server in this case require a release of a new client? Does protocol buffers give this capability to gRPC? Is there any downsides to these types of issues to gRPC?

I see the added benefit of RPC over a REST api (chat feature?).

Additional question:

Because the model is generated from a schema they can't contain an interface for behaviors? Should I be separating the behaviors from the model anyways?

e.g.,

IMatcher :
    bool Match(...)

IPaylineMatcher : IMatcher
   int getSymbol;
   void setSymbol

PaylineMatcher : IPaylineMatcher
   //imp

IWaysMatcher : IMatcher

   int getSymbol;
   void setSymbol

   //...

WaysMatcher : IWaysMatcher

This example is simple to implement with polymorphic json.

Thanks,
Bourke 

[Nicolas Noble]

First of all, the marshalling protocol isn't enforced in grpc. Most of the examples and usage cases are using protobufs, but you can use grpc to transport anything you want. If you want to go with your own protocol, or simply pure json, you can.

But protobufs are designed to always be backward compatible. It still means you have some planning to do in order to provide proper backward compatibility, such as default values for newly-added fields, but so would a typical json-based protocol. Also, the transport protocol of grpc is very unlikely to change at that point, which should guarantee proper backward compatibility over time. Meaning that you don't have to systematically update your clients and servers at the same time - this is in fact one of the most important feature and benefit of using grpc+protobuf.

--
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+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e231b55a-cf64-4eba-a7ad-3233211db6cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Anderson]

On Sat, Mar 28, 2015 at 3:02 PM, chbfiv googl <chb...@gmail.com> wrote:

Additional question:

Because the model is generated from a schema they can't contain an interface for behaviors? Should I be separating the behaviors from the model anyways?

One key important detail of gRPC is easy cross-language support for your API. That does mean that it is not important to gRPC to include logic, as that logic can't reliably be converted to every language.

Thus, most usages we would expect to be logic-free and you separate the behavior from the model. In the case of "fat client libraries" (those with lots of logic), you may even create a non-protobuf model and convert between that model to the protobuf model used by gRPC. In that case, gRPC is an implementation detail and not likely exposed to the user of the API.

This example is simple to implement with polymorphic json.

When polymorphism is necessary you can use OneOf.