Open raykyri opened 2 months ago
rjwebb
commented
2 months ago Do we want to display any information about peering? e.g. what nodes the network explorer is connected to. I wonder if there is some sort of distinction we can make here between tools that are inspecting the network's state at the libp2p/network level, versus focusing on things at the Canvas level (i.e. messages, sessions, actions).
rjwebb
commented
2 months ago Part of me wonders if this needs to be a separate site with a web server etc, because this displays information that any client will have already synced. This is different to something like the blockchain, where having some external service is a necessity because most users don't run their own nodes (but use wallets that access a node through the RPC) so they don't have the entire "state" of the chain loaded onto their computers. Maybe it makes more sense if the network explorer is eventually going to display information across many Canvas topics though.
If we just want to view the state of particular topics, then a button that developers could embed in the page of an existing Canvas app that could then display a modal or a separate view that would show all of this information, almost like letting the user look "inside" the application.
rjwebb
commented
2 months ago Another question: to what extent do we want this to be "live" data? Should we have JSON API endpoints for the various data and then access it from the frontend using something like useSWR? Or do server side rendering (which would require us to refresh the whole page)?
rjwebb
commented
2 months ago I've added a checklist to the end of this issue description (may just add this to the PR)
raykyri
commented
2 months ago Part of me wonders if this needs to be a separate site with a web server etc, because this displays information that any client will have already synced. This is different to something like the blockchain, where having some external service is a necessity because most users don't run their own nodes (but use wallets that access a node through the RPC) so they don't have the entire "state" of the chain loaded onto their computers. Maybe it makes more sense if the network explorer is eventually going to display information across many Canvas topics though.
If we just want to view the state of particular topics, then a button that developers could embed in the page of an existing Canvas app that could then display a modal or a separate view that would show all of this information, almost like letting the user look "inside" the application.
Yea, displaying information across many topics is important and there will be a bunch of cases where data is harder to access on the frontend because of the change to server-to-server sync. I'll go through more on Friday.
Live data is actually not essential, and it's possible that trying to push all data from the backend to frontend causes issues (I notice this a lot on newer block explorers). Between SSR and data fetching, that's more of an implementation detail, but both seem like compelling options in their own regard. There are just a lot of JS edge cases to handle when building an SPA which SSR would solve
raykyri
commented
2 months ago Do we want to display any information about peering? e.g. what nodes the network explorer is connected to. I wonder if there is some sort of distinction we can make here between tools that are inspecting the network's state at the libp2p/network level, versus focusing on things at the Canvas level (i.e. messages, sessions, actions).
Peering info isn't critical, but some indication of which peers are connection would be good to have at some point just to verify the explorer is online. Since it's not a blockchain, devs will want to check if they have a healthy connection to the explorer down the line
The network explorer tracks the latest actions across applications, and displays them in an Etherscan- or block explorer-like format. The design is inspired by zksync's block explorer.
To set up the network explorer, we can reuse the setup from /packages/replication-server. Instead of using pm2-runtime to start the server (which is used to autorestart replication server instances), we'll just use
node lib/index.js.Inside
index.js, the network explorer should start Canvas applications on a hardcoded list of topics and contracts. It should create a sqlite database for each topic and contract pair, start the application, and join the p2p network for the application.As actions come in, those actions should be indexed to the local sqlite databases. Additionally, the explorer should maintain network stats (total number of actions, total number of sessions, total number of unique addresses).
These network stats might require additional indexes to be stored in a network-explorer-wide database - for example, a table of
(application topics, unique addresses). These could also be stored in SQLite.It's possible that as the explorer evolves, we'll need to add new indexes. We will probably address this by wiping the network explorer databases and re-syncing with all apps, since the amount of data on the network isn't prohibitive enough yet to hold us back. This means we won't need to write migrations until far later down the line.
Designs
Homepage, with application listing module, and showing recent actions across all applications:
(Fetch and display the version of Canvas from package.json, so we know what version the node is running.)
App page, displaying actions for each application (paginated):
App listing page, displaying a list of applications (paginated):
Checklist