As the IDL provides a lot of necessary information for us to standardize access to the given on-chain program, there still remains some research to be done on what code can be further generated with the IDL and which code has to be generated given a user's input.
The basic structure of an indexer looks like this:
dal: Contains configurations for the Data Access Layer. Some of it is simple boilerplate for each project, but some of it requires consideration by the user
Which data objects to be stored
Which indexes to choose, on which to access the stored objects in
domain: Contains domain-specific code
A subclass of SolanaPools<P>, which governs the discovery and aggregation of P = SolanaPool<PI, PS> objects
A subclass of SolanaPool<PI, PS> defined by their PI = PoolInfo = { name, address, programId } and some PS = PoolStats object, governing which statistics are to be stored and saved over the processed events.
(optional) A processor
These require some extensive effort of customization on the user side.
graphql: All code for setting up the GraphQL server
A schema, which specifies the GraphQL API, which can be subdivided into
GraphQL types and
Resolvers, which depend on the implementation of the server and its DB itself
indexer: The binding piece for all the parts of the indexer.
Contains at least one subclass of TransactionFetcher, which will query transactions, which contain certain addresses.
layouts: Structures needed to parse the byte data directly from on-chain
parsers: Classes to parse transactions (with help of layouts)
A class that takes in an InstructionContext and translates it into an internal representation of that instruction (Event)
Boilerplate to initialize a parser, tying together layouts and parsers
A possible route to take with Anchor-based programs, is to generate a GraphQL schema from the IDL, let the user modify the schema, and feed both into a generator for an indexer.
The GraphQL schema allows us to know:
What the user wants to index and what to filter
What kind of resolvers are going to be needed
If the user expects some additional data and will have to resolve it themselves
MHHukiewitz
commented
2 years ago
As the IDL provides a lot of necessary information for us to standardize access to the given on-chain program, there still remains some research to be done on what code can be further generated with the IDL and which code has to be generated given a user's input.
The basic structure of an indexer looks like this:
SolanaPools<P>, which governs the discovery and aggregation ofP=SolanaPool<PI, PS>objectsSolanaPool<PI, PS>defined by theirPI=PoolInfo = { name, address, programId }and somePS=PoolStatsobject, governing which statistics are to be stored and saved over the processed events.TransactionFetcher, which will query transactions, which contain certain addresses.InstructionContextand translates it into an internal representation of that instruction (Event)A possible route to take with Anchor-based programs, is to generate a GraphQL schema from the IDL, let the user modify the schema, and feed both into a generator for an indexer.
The GraphQL schema allows us to know: