Change Details

**Note: this is almost entirely AI-generated** imo the rapid prototyping and that this is a large final job best checked visually by incremental progress support this approach. My plan is to incrementally add charts. As the charts become more complicated than just regurgitating chronik data, I will add unit tests to confirm we are parsing blocks and txs correctly. Starting point for chronik-charts. There are many things we would like to index and I have struggled to find a small starting point that we can build from. Here, we can start the indexer from an arbitary blockheight, and produce chartable data. So we can easily index, say, a few thousand blocks for dev purposes. I have included three simple charts (txs per day, blocks per day, and avg block size per day). Going forward, will iterate toward the exact schema we want for more charts. When the schema is worked out, then we can do a prod deploy and index everything. Features - Three basic charts - Support for limited indexing and reindexing with `npm run dev:reindex` - Front end to confirm charts

Note: This was built using cursor, so the code itself is almost entirely AI-generated. Features Backend A nodejs app that starts up and indexes a database using an array of chronik servers. The schema is defined in the server. The server will determine chaintip and begin populating the database on startup. If the database is populated through the chaintip, the server will listen for finalized blocks and add them as they come in. The server runs a cron job to fill in any blocks that may have been missed by the websocket. The server is a standalone app and interacts only with a database. It does not expose an API and the charts front end does not interact directly with the server. The charts frontend connects directly to the database (it is a nextjs app, so it runs effectively it's own server that runs an API populated by the same database that is updated by the indexer). Front end NextJS app that visually presents network activity overtime, according to the database schema. User can select different time windows. User can zoom to select different y-axis max values. The BCH and XEC forks are marked with reference lines. We include some novel data that probably would not make sense to index with chronik, like volume over time. Perhaps it would be better to come up with a more extensive chronik plugin, or add more volume data to the existing agora plugin. But we will probably always have some data that really is only interesting for charting purposes. Charts are mobile responsive. Everything in this diff is deployed. The database is being updated by the indexer. The front-end is deployed and connected to the database. We could launch this just by moving the domain -- we could also keep the existing stack and support CI. Would be a bit of an infra change for ABC, but could be the way to go if we are going to have lots of nextjs apps and one-off backends where a dedicated server is arguably overkill. https://charts-e-cash.vercel.app/

**Note: thisThis was built using cursor, so the code itself is almost entirely AI-generated**. imo the rapid prototyping and that this is a large final job best checked visually by incremental progress support this approach. My plan is to incrementally add charts. As the charts become more complicated than just regurgitating chronik data, I will add unit tests to confirm we are parsing blocks and txs correctly.Features Starting point for chronik-chartsBackend A nodejs app that starts up and indexes a database using an array of chronik servers. The schema is defined in the server. The server will determine chaintip and begin populating the database on startup. If the database is populated through the chaintip, the server will listen for finalized blocks and add them as they come in. There are many things we would likeThe server runs a cron job to index and I have struggled to find a small starting point that we can build fromfill in any blocks that may have been missed by the websocket. Here, we can start the indexer from an arbitary blockheight, and produce chartable dataThe server is a standalone app and interacts only with a database. So we can easily index,It does not expose an API and the charts front end does not interact directly with the server. sayThe charts frontend connects directly to the database (it is a nextjs app, a few thousand blocks for dev purposesso it runs effectively it's own server that runs an API populated by the same database that is updated by the indexer). I have included three simple charts (txs per day,Front end NextJS app that visually presents network activity overtime, according to the database schema. User can select different time windows. User can zoom to select different y-axis max values. The BCH and XEC forks are marked with reference lines. We include some novel data that probably would not make sense to index with chronik, like volume over time. Perhaps it would be better to come up with a more extensive chronik plugin, or add more volume data to the existing agora plugin. blocks per day,But we will probably always have some data that really is only interesting for charting purposes. and avg block size per day)Charts are mobile responsive. Going forward,Everything in this diff is deployed. The database is being updated by the indexer. The front-end is deployed and connected to the database. will iterate towardWe could launch this just by moving the exact schema we want for more chartsdomain -- we could also keep the existing stack and support CI. When the schema is worked outWould be a bit of an infra change for ABC, then we can do a prod deploy and index everythingbut could be the way to go if we are going to have lots of nextjs apps and one-off backends where a dedicated server is arguably overkill. Features - Three basic charts - Support for limited indexing and reindexing with `npm run dev:reindex` - Front end to confirm chartshttps://charts-e-cash.vercel.app/