As a user of the current thrift api, I really like the idea of simplification by having three separate apis. The majority of developers will only ever need to use the client(controller) api.
In order to solve the one shard problem, I think having the shard able to respond to the controller api is a great idea. On Sep 14, 2012 9:56 AM, "Aaron McCurry" <[email protected]> wrote: > In recent weeks I have had several discussions with developers over the > complexity of the RPC and how we need to make it easier to use. I agree, > but I have struggling to come up with a way to make things easier to use > while still having all the components necessary to allow all the different > functions to operate. > > To date the Blur shard server and the Blur controller server have shared > the same Thrift service API, perhaps that should change. A lot of the > extra pieces to the API have come from this fact. Basically the > controllers needs to be able to pass different information to shard servers > than the clients need to pass to the Blur controllers. > > The change that I am proposing, split the API into the 3 services. > > - User / Client API (for the controller) > - Shard Server API > - Admin API > > One pro to this design is that changes to the internal API (Shard Server) > could be changed and have less of an impact to the clients if any. > > The only drawback to this approach is that the controller has to be > deployed, even for testing. Currently you can just deploy a single shard > server and have the same features as a whole cluster. We could get around > this by allowing the controller API (and the admin API) to be run in the > same process as the shard server so that the same small scale testing could > occur. This then begs the question, do we need separate controller > processes? Should we allow for all 3 API types to always be in every > process? or should we keep things the way they are? or should we just > allow users to configure things they way they want? > > Aaron >
