Introducing Hivelytics 2.0 or Replacement for Hive Stats

<img src="https://i.ecency.com/DQmVZNaVE9qFVS5yP6Ua6Q2pTdUtoNR7YUCnGRXD1iGQAYp/image.png" alt="" /> Introduction ------------ This morning I saw a post from @mrtats: [https://ecency.com/@mrtats/introducing-hivelytics-or-an-open-source-alternative-to-hivestats](https://ecency.com/@mrtats/introducing-hivelytics-or-an-open-source-alternative-to-hivestats) I know this post is really old from six months ago, but today was the first time I saw it. And I love what mrtats did with this tool, because it is a cleaner version of my favorite Hive tool Hive Stats. And more importantly it is open source and uses a very simple front end only architecture. This architecture makes it very simple to modify the code using GitHub Copilot. I would love for mrtats to include these changes into his open source repository, however I am not sure if he is comfortable with all the changes I have implemented using various LLM models such as Codex 5.3 and Claude Haiku. From the user-interface standpoint it might not look like much, but the changes are to put it mildly extensive... [Check out the Hivelytics 2.0 here](https://seattlea.z5.web.core.windows.net/hive/?account=acidyo) Why I have created the [2.0 Version](https://seattlea.z5.web.core.windows.net/hive/?account=acidyo)? ---------------------------------------------------------------------------------------------------- Well, while I love the original Hivelytics tool, this tool and Hive Stats miss something that is really important: 1. Optimization for repeated use of RPC servers 2. The "Top Voters on Your Posts" section at the bottom Optimization for RPC Usage -------------------------- <img src="https://i.ecency.com/DQmTwmYLX1H7oi4hSZiDykGiABjTPfmb6A7c6VP31PvAMLp/image.png" alt="" /> When I use Hive Stats or the original Hivelytics I tend to switch between various accounts back and fourth and guess what happens when I load the accounts? It goes on to hammer the RPC servers with a flood of calls. The main culprit is this Pending Curation Rewards table. On a curation account like @acidyo I have to go make a cup of tea and wait for it to brew before it loads on Hive Stats or in original Hivelytics. I implemented browser caching, but that is not enough. I have done some more advanced performance optimization by doing the following: When the user first loads the page in his or her browser the application loads the full seven days of curation data in what I labeled "Mode: Full Build" as you can see from the image above. This first load is the same as in original Hivelytics and takes a while and I am displaying a progress bar with information of what is actually happening. So this data is stored for 23 hours in your browser cache. <img src="https://i.ecency.com/DQmUtcKzwEV4hgEzmd6Rxds2UFQP1ub5qWcSA6kxka4fwY8/image.png" alt="" /> When user loads the same account for a second time I have the application load the data from cache and from live RPC source for only the last 24 hours in what I call "Mode: 24h Incremental". So the RPC server is hit for one day of Pending Curation Rewards data instead of all seven: <img src="https://i.ecency.com/DQmSrLeXwF2rJ5UtHipm4BV73w79Ayi6iyudR6gAbpSkB2e/image.png" alt="" /> Now, that is nice and sweet and I am sure Hive RPC server owners will appreciate a seven fold reduction in RPC calls flooding their servers from repeated calls for the same account data, but the real solution would be to have an API service in the middle to cache data so that cached data can be shared between users accessing the application. That would modify the simple architecture of this app, though it might be worth exploring... Top Voters on Your Posts ------------------------ <img src="https://i.ecency.com/DQmaBaSdW7FzTbYtixvsruwwg8mqafFNgNiRGaSQ1yoAq9E/image.png" alt="" /> The image above is showing data for: @azircon I picked azircon because he only has one post in the last seven days, so it is really simple to do analysis on it. As you can see there are four v […]