yarpc module is called `modules/rpc` about fx HOT 13 CLOSED

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.

from fx.

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

from fx.

from fx.

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.

from fx.

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.

from fx.

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.

from fx.

@uber-go/service-framework thoughts?

from fx.

Understand. Thanks for the answer!

from fx.

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.

from fx.

@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

from fx.

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

from fx.

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:
    ...

from fx.

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.

from fx.