search

uber-go / fx

A dependency injection based application framework for Go.
https://uber-go.github.io/fx/
MIT License
5.83k stars 290 forks source link

yarpc module is called `modules/rpc` #267

Closed yichengq closed 7 years ago

yichengq commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/uber-go/fx/issues/267, or mute the thread https://github.com/notifications/unsubscribe-auth/AAF7P2FNh9ukNemUQJ67RO47zRSozit7ks5rc7axgaJpZM4MCg42 .

yichengq commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@uber-go/service-framework thoughts?

yichengq commented 7 years ago

Understand. Thanks for the answer!

madhuravi commented 7 years ago

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 commented 7 years ago

@sectioneight you can quickly re-close this if it's decided and I can't convince everyone, but my opinion re: https://github.com/uber-go/fx/issues/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 commented 7 years ago

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

HelloGrayson commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

madhuravi commented 7 years ago

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.