yarpc module is called modules/rpc

[yichengq]

IIRC, yarpc is just one type of RPC system which could be supported as modules. Similarly, gRPC may be supported too in the future.

[ascandella]

gRPC support would be through YARPC in UberFx. cc @breerly I think the messaging should be clear here -- if you're doing rpc, Fx has an opinionated way that supports HTTP, TChannel, and eventually gRPC

…

On Wed, Feb 15, 2017 at 6:38 PM Yicheng Qin ***@***.***> wrote: IIRC, yarpc is just one type of RPC system which could be supported as modules. Similarly, gRPC may be supported too in the future. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#267>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAF7P2FNh9ukNemUQJ67RO47zRSozit7ks5rc7axgaJpZM4MCg42> .

[yichengq]

My point is that YARPC uses the general name rpc, which is not straightforward.
There could be xRPC, yRPC, zRPC in the future, and they would all be options/choices for the developer.

[HelloGrayson]

Sure, using yarpc as a key might be the least surprising - in fact, its not a terrible idea.

On the other hand, UberFX shouldn't need to support another messaging platform since YARPC can plug in transports like tchannel, http, gRPC, and Cherami. Customers have expressed interest for Kafka, QUIC, and reactive sockets as well.

I'm flexible here - whether the key is called rpc or yarpc, UberFX shouldn't have to make room for an additional RPC system since that is the exact goal of YARPC.

Perhaps the biggest argument for calling the key "yarpc" is to be explicit, and tell the use exactly what their getting.

@sectioneight your call.

[ascandella]

UberFx will not support any rpc modules other than YARPC. Its primary goal is to make Uber service development simple and sane, while reducing confusion. If we end up needing to use xRPC in the future, then the yarpc ecosystem will need to be extended to support xRPC -- we're not going to ask services owners to choose between yarpc and xRPC.

[ascandella]

@uber-go/service-framework thoughts?

[yichengq]

Understand. Thanks for the answer!

[madhuravi]

I can go either way but there doesn't seem to be a strong reason to change given future implementations will go under the same umbrella.

Everyone seems to be on the same page, resolving.

[bufdev]

@sectioneight you can quickly re-close this if it's decided and I can't convince everyone, but my opinion re: #315

FX's primary purpose is to make Uber service development simpler, but that doesn't mean that FX can't have implications as a general service framework for the rest of the golang community. If it is sufficiently low-cost, I think FX should aim to support use cases that aren't Uber-specific, and I think this is one of them. YARPC may support gRPC soon, but if I was a third-party developer, and I had the choice of using a new rpc library that supported gRPC, or github.com/grpc/grpc-go directly, I would probably want to use the official gRPC golang library right now. I think renaming from rpc to yarpc is a good thing to do for use of FX outside of Uber, and is a low-cost choice.

@breerly

[bufdev]

Also note that the http module is uhttp, not http.

[HelloGrayson]

I think we should rename the module key to yarpc.

Not because I think we should make room for another RPC system (because we shouldn't be introducing additional RPC systems when we can already plug those transparently into YARPC - e.g. YARPC gives us a single way to write handlers and outbound calls).

The reason I think we should rename the key is to make it obvious and explicit what is being configured - in this case, they are configuring YARPC.

I much prefer:

modules:
  yarpc:
    ...

[bufdev]

Note I think this should mean that the package should move to be yarpc as well, re convo with @madhuravi about how default keys should match the package name.

[ascandella]

uhttp is to avoid clashing with the stdlib http. i'm fine with renaming the module to yarpc.

[madhuravi]

Aiden, I think Peter is referring to a conversation we had earlier today. It's similar to Grayson's sentiments above. Our config yaml keys should match the package names so it's intuitive for users.

So in yaml we would now have:

modules:
yarpc:
...
uhttp:
...

So it's clear what the config keys stand for. Our config keys for http don't match the module name, we can change that.