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
