Closed muttmuure closed 7 months ago
conversation is ongoing, with some recent highlights being:
@quinthar:
So there are kind of three different optimizations being discussed, and they are entirely independent (ie, we can do any of them by themselves), but we are talking about them as fi they are somehow the same:
- Query speed: Use on-disk imaging to improve disk read times
- Worker offload: Add APIs to postprocess (ie, sort/filter) results on the worker thread to improve main thread responsiveness
- Worker overhead: Reduce the amount of data going over postMessage to improve overall command performance
Of all those, I think the most important goal should be offload both querying and postprocessing to the worker thread to keep the main thread continuously responsive. Improving the query speed is nice, but kind of marginal.
@adhorodyski:
On the 3 extracted topics, worker offload, worker overhead, query speed (thanks for this clarification!): I gave it another spin and and as crazy as it gets, I think I've managed to solve all of them at once with the current key-value data structure for SQLite (amazes my every day how powerful it is :stuck_out_tongue:). You can think of it as an API for heavy processing on the other thread with very little adjustments to what we have right now :slightly_smiling_face: I'll do my best to share a POC shortly with you but need to run some more tests. Without moving anything around I'm able to query the KV structure using SQL and get the UI reactivity based on the database updates. So far it looks like it can be both performant and require little to changes, just adding the new queries on top and syncing with database hooks
excited to hear more about @adhorodyski's proposal.
I’ve been deeply invested in ongoing discussions about performance and have observed that our primary challenge doesn't seem to stem from the storage database itself but rather from extensive processing times on the main thread. This challenge manifests in two main areas:
It’s clear these issues are significant and not directly related to the choice of storage provider. I’m curious about the native side - do we face similar challenges there, or is the conversation about moving storage handling off the main thread mainly focused on web implementations?
Given my history with Onyx, I have immense respect for what we've built and its evolution from a simple pub-sub model to a sophisticated key/value storage solution. As we navigate these performance challenges, I believe it's beneficial to revisit the foundational goals of Onyx:
I once hesitated to use Redux, favoring more familiar patterns like MVC with MobX. Yet, the potential for integrating existing solutions through middleware, possibly enhancing Onyx or even adopting new approaches, is worth considering. This doesn’t diminish Onyx’s value but opens a dialogue on leveraging collective wisdom and advancements from the wider community.
As we ponder the future of Onyx, I see an opportunity for evolution rather than abandonment. Could we envision a redesign or integration that honors Onyx's original principles while addressing our current challenges? I’m eager to contribute to a path forward that builds on our collective achievements and addresses the needs of our evolving technology landscape.
I have deeply appreciated all your work on Onyx over the years! Your expertise and opinions are super gracious and encouraging. I'll respond to a few points here and give some general opinions of mine.
What needs did Onyx initially aim to fulfill?
Onyx.connect()
I think we did a pretty good job of delivering those things.
Before Onyx, had we explored using existing solutions like Redux?
Yes, I explored that heavily. I have used Redux in other projects, so I was pretty familiar with it. I found that the excessive boilerplate was just too much to deal with in a huge project. I also explored alt in a desire to see if a flux pattern with less boilerplate would help. I built the K2 extension with alt
originally. I still didn't like it there and the patterns and boilerplates were still more than we desired.
It’s clear these issues are significant and not directly related to the choice of storage provider. I’m curious about the native side - do we face similar challenges there, or is the conversation about moving storage handling off the main thread mainly focused on web implementations?
The off-thread conversation has been focused on web implementations. That's not to say that the native side is perfect, but it seems like the web side is where most people have focused on performance. I don't know if there is a correlation there or if it's just natural tendencies.
Could we envision a redesign or integration that honors Onyx's original principles while addressing our current challenges?
Yeah, I am totally down for this. I think of the useOnyx
hook as almost like version 1.5 of Onyx, and I think it's entirely possible to build a 2.0 version that is a complete rewrite and rethinking of the library, building off of everything good that was going on in 1.0. I'd much rather explore this than to try to grab an off-shelf solution that we have little control over and try to get it to work (only to find out that we are in a much worse spot than we were with Onyx 1.0).
An interesting library we could consider (or pull from for inspiration) is @legendapp/state. Reviewing the design goals for Onyx written by @tgolen, and adding this one:
legend-state seems to check all the boxes. I believe it's quite similar to Onyx in its design, with even less boilerplate. I also think it would be feasible to leverage it to simplify Onyx internals while keeping the existing interface for Onyx largely unchanged, avoiding the need for a major app-wide refactoring effort.
I've also met the maintainer in person a few times at React Native conferences, and I believe he'd be open to working with us. A direct line to support could alleviate concerns with lack of control over the library.
@roryabraham I'm going to need some more time to prepare a draft of how I think this could look like, but to give you all more context I genuinely think nearly all we need is the right design and composition of some primitives, not much of the new tools - this might be the 10% but mostly due to the ergonomics of not rewriting community libraries.
I basically work with SQL queries & JS Promises, binding them to the UI.
I'll do my best to share a WIP proposal of this design next week.
It seems like conversation has stalled for the last few weeks, and the initial investigations we did have prettymuch concluded. It sounds like @adhorodyski has an idea he'd like to propose for which SQLite on the web would be a prerequisite, so I'm going to assign this issue to him. I'm also going to unassign @hannojg and @kirillzyusko because their explorations are complete.
@roryabraham still working on it - correct with the web support being a prerequisite, but after a few discussions with @jbroma together we decided to slightly pivot as IndexedDB is for now the only option which fully supports this platform. I'm aiming for a design where once web catches up, we can easily migrate just this very piece with a very little effort. Will update within days!
Hey @adhorodyski, we discussed this internally, and since we're not working from a clear problem statement here and the ROI of any changes is still very much up-in-the-air, we've agreed that we're going to close this issue for now.
We advise that you shift your focus into other areas of the performance audit for the time being. We love SQLite and may want to pick this discussion back up someday, but for now we're going to cap it here for #focus. Thanks everyone for all your participation so far!
@roryabraham I agree this was fine to be closed - I'll post my research on Slack just so we don't loose it later on (I learned a lot on the integrations for SQLite/IndexedDB), I think this is still valuable and holds/maybe we'll continue the discussion from there/kill it with fire for now :D
cc @roryabraham posted internally under this thread, please let me know if there's a better place for this :)
thanks, I think that's an appropriate place for that
Placeholder tracking issue for adding SQLite support to Chrome, Safari, Edge and FireFox (Not IE)
Also for adding a fallback mechanism to retrieve data from IndexedDB when SQLite fails or has a problem
cc @roryabraham