If a large rewrite for 2.0 were to occur, I would ask that the documentation for Helix be included as a deliverable. The current documentation around how the system works, what configuration items mean, and how to utilize core pieces of the system (Tasks, spectators, etc.) with solid examples for most common usecases would greatly help current users of the product.
As someone who uses Helix heavily, all the listed features sound amazing. I actually built a rudimentary version of the gRPC gateway for helix for my company for the exact reason stated. Thanks, Will > On Jun 20, 2024, at 5:13 PM, Junkai Xue <[email protected]> wrote: > > Hi All, > > Apache Helix has been stable for a long time, but there are several areas > where we can make significant improvements. I am proposing a new generation > of Apache Helix with the following major goals: > > 1. Multi-language support > 2. Simpler API and user experience > 3. Improved data model, communication protocol, and system performance > 4. More pluggabilities > > To achieve these goals, I have outlined the following projects: > > - *Multi-language support*: Develop a gateway service that accepts general > state transition calls through gRPC. > > - *API simplification*: Minimize both client and Admin APIs to streamline > the process. > > - *Simplified data model and communication protocol*: Instead of defining a > fine-grained state model, provide users with the final state and allow the > application to progressively update its own partition states. This will > minimize round trips between the Helix controller and participants and > reduce traffic to the storage (Zookeeper). > > - *Components "micro-servicing"*: Abstract some components to offer the > capability to plug user own logic. For example, choose move one partition > at a time as movement strategy instead of using per partition N -> N + 1 by > default. > > Please let us know your suggestions or concerns. Thank you for your > attention and continuously support! > > Best, > > Junkai
