-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Description
Coming from this thread.
Step 1: Objective Analysis
First, we need a deep and objective assessment of where the current Onyx falls short. What are the specific pain points and performance bottlenecks? Can we optimize the current implementation further, or are we genuinely constrained by its foundational design? This clarity is critical before we can justify any major re-architecture.
Step 2: Define the Vision
Next, we should holistically define what Onyx 2.0 should be, assuming the core philosophy of Onyx 1.0 still makes sense for the kind of app NewDot aspires to be. The app’s scale, usage patterns, and customer demands have evolved significantly since Onyx was first created. We now have a much better understanding of the performance characteristics needed to support our largest customers.
Step 3: Explore the Solution
Once we’ve aligned on (1) clearly defined problems and (2) a shared vision, we can explore the best way forward. That might mean rethinking Onyx’s architecture — or it might validate continuing with incremental improvements. But we’ll be making that choice with solid footing.
Let's take it step by step, acknowledging that we might want to stop after each of these steps:
- Objective Analysis
- Define the Vision
- Explore the Solution
The analysis can very possibly show that the gains are not that large for the App's performance, considering that the large onyx states will not be the norm as more data is paginated for the App. As @kubabutkiewicz noted in his exploration of storage eviction, the size of data is not really a problem on Onyx side as much as the amount of data manipulation that is happening on App side.
As noted in Slack, this is lower priority at the moment than Critical or some other High quality initiatives.
Issue Owner
Current Issue Owner: @fabioh8010Sub-issues
Metadata
Metadata
Labels
Type
Projects
Status