Have separate package for rpc per library/encoding? about fx HOT 8 CLOSED

@breerly

from fx.

We won't need to expose another RPC framework besides YARPC because YARPC will do that for us.

Besides the point: I agree, we need to expose all the functionally YARPC makes possible, and right now that is artificially limited to 1 encoding. A good litmus test would be: if we add a new encoding, like proto for example, there should be no work required in UberFX to expose that, it should just work.

The config project we are working on now (search "config:" in YARPC-go PRs) should resolve this (or put us in the position where it's the next thing to resolve): since the whole rpc: key will be delegated to yarpc, you'll need to be able to use it to work with any encodings.

I feel less strongly about whether the config key is named rpc: or yarpc:, but I sort of prefer the explicitness in the latter.

from fx.

"We" = Uber, I'd love if FX was usable as a general framework for everyone, including those not tied to YARPC, and there are some places where do we close tie-ins, but this is one that's easy to make sure we don't have a tie-in.

from fx.

In other words, I do think:

• the yarpc module should reside in the modules/yarpc package
• the functionality should be exposed in such a way that all encodings can be used
• the rpc: key should probably be renamed to the more explicit yarpc:

from fx.

Note that in #275, I'm removing default names for modules as it is proposed now, so the key will not longer be tied by default to rpc.

from fx.

Oh also, I agree with @breerly's above list

from fx.

I don't want to do this until we get some of the bigger PRs in, otherwise we will be in merge world

from fx.

renaming has been discussed in #267 @yichengq

from fx.