Skip to main content

Explorer: overview

hlf-explorer is a Hyperledger Fabric block explorer built on hlf-core. If hlf-core itself answers the question "how do I write chaincode and clients", the explorer answers another, no less important question: "what is actually happening in the ledger right now". It reads blocks, unpacks them into a database and serves them outward: both over REST and in real time over a socket.

How the data flow is arranged​

The simplest way to keep it in mind is as a single line: ledger → backend → database → API → interface.

Ledger (Fabric)source of blocksBackendreads blocks via qscc, parses themPostgreSQLblocks, events, transactionsAPIREST + socketUIreal-time updates@hlf-explorer/monitorparses business eventsof application-level apps
Data flow: the backend fills the database, monitor is an API-consuming layer on top.

Everything starts with the backend. It connects to the network directly — this is exactly where @hlf-core/transport, @hlf-core/api and @hlf-core/transport-common are used. On a timer the backend compares the ledger height with what is already stored, computes the unread blocks and schedules a parse task for each of them. Parsing reads the raw block through qscc, runs it through TransportFabricBlockParser and unpacks it into entities — the block itself, its raw representation, events and transactions — after which it stores all of this in PostgreSQL.

From there the data branches in two directions. The frontend fetches it over REST — blocks, events, transactions, search — and on new blocks the backend also sends a notification over the socket, so the interface updates itself, without a reload. The contracts of all these requests and responses are extracted into a shared package, so that the backend and the client cannot diverge in their understanding of the same data.

What it is built from​

The server is a NestJS backend with TypeORM and PostgreSQL. The shared models, DTOs and the API client are extracted into @hlf-explorer/common — a published package, a single contract for all parts. Separately there is @hlf-explorer/monitor — also a published library, but no longer about the explorer itself, rather about how application code consumes its data. The next section is devoted to it.

We are currently rewriting the web interface from scratch, so we deliberately do not fix its architecture here — it will be described once the new frontend is in place.