Closed outSH closed 6 months ago
@petermetz @jagpreetsinghsasan Please review and share your comments and opinion :)
I have several points regarding this.
Ethereum Ledger
and Ledger Data Storage
. I dont think we should create the Ledger Data storage
, because from the description of it, this itself seems like a Cactified variant of a group of ledgers
, some sort of cached DB. Instead of this, we can develop read-only ledger functions
within the original plugin and use them.I would like to propose something like this for the cactus-gui
Grafana dashboard which dynamically loads all the connector plugins hosted over the gui-server.
Benefits :
I might be completely wrong in understanding this, so please review and suggest @outSH @petermetz
@jagpreetsinghsasan
1. How is this different from [feat(scorpion): ledger explorer graphical user interface #1979](https://github.com/hyperledger/cactus/issues/1979) (specifically point 5 of it)?
This is mostly in-line with peter task description, but aligned to our internal requirements.
2. Can we not use reactjs instead of solidjs (if there is no significant usage of solidjs, which reactjs doesnt provide)? This is just to reduce the learning overhead for easier external contribution.
As I've mentioned previously, SolidJS builds upon ReactJS, uses the same concepts and fairly similar syntax, so learning curve shouldn't be an issue. We can replace it with react if we need more mature libraries (possibly in a next step).
3. Is it better to have a general GUI plugin (just like we have cactus-api-server, we can have cactus-gui-server) and the existing plugins to have functions to provide data to this GUI plugin? In this way we can leverage the existing prometheus exporter and build around those real-time metrics.
I'm not sure if I understand you correctly, but I think this is similar to replacing supabase with a separate service that I've also described above as an option. But, as mentioned above, I'd like to stick with supabase for now because this gives us a lot of functionality and flexibility for free.
4. In the very first screenshot, there are 2 storages `Ethereum Ledger` and `Ledger Data Storage`. I dont think we should create the `Ledger Data storage`, because from the description of it, this itself seems like a `Cactified variant of a group of ledgers`, some sort of cached DB. Instead of this, we can develop `read-only ledger functions` within the original plugin and use them.
It's not really a cached DB, but an actual persistent DB (hence the name of the components that feeds data into it - persistence plugins
). The backend storage layer is our internal core requirement for the GUI component. The whole concept is based on storing the parsed ledger data in the DB, and being able to make simple or complex cross-ledger queries and analytics on it (and display it when necessary).
Another key reason for storing the data in DB is performance. Even a simple operation like rendering the list of latest 100 blocks would cause 100 separate requests on ledgers that don't support a bulk read, if we were to use connector function calls ad hoc. Showing history of account token balance would be nearly impossible.
In general we don't want the GUI for the cacti itself (as the prometheus & grafana solution would suggest), but efficient way to visualize cross-ledger data.
@outSH Is this being worked upon?
@aruns05 Yes, we will be pushing PR with GUI components next week :)
@outSH can we speak about it . I tried to reachout to you in discord
Hyperledger Cacti GUI
We (Fujitsu) are currently implementing a universal GUI for Hyperledger Cacti project. I would like to present and describe our proposal, justify some decisions and start the discussion about the future improvements and development. Our goal is to create a common GUI that would allow exploring multiple ledgers states in single place and simplify visualization of custom solutions (BLPs) based on Hyperledger Cacti.
At the moment, we are working on delivering GUI for Ethereum ledgers only, but the overall architecture is extensible and applicable for additional ledgers. We plan to submit the PR with Ethereum GUI by the end of this year (2022) and continue working on this feature next year.
Summary
cactus-plugin-persistence-X
)Tasks
supabase-all-in-one
image to be used for tests -> #2253@hyperledger/cactus-plugin-persistence-ethereum
-> #2258Cacti Components
Ethereum Persistence Plugin
Ledger Data Storage
Supabase API
GUI Server
cmd-api-server
.GUI application
Ethereum Connector Plugin
connector-go-ethereum
for communicating with the Ethereum ledger.Deployment
cmd-api-server
.go-ethereum-connector
is not openapi compatible), so we assume following deployment:Glossary
cmd-api-server
), and SocketIO ones (that are stand-alone services).