We are going to run our solution in a separate Docker container.
1 Like
I think my comments in this post are still unanswered.
I sense some over-engineering and reinventing the wheel here.
There are two pieces of information that are missing right now.
- flag of voucher execution, so you can filter queries based on this flags
- voucher destination ABI so you can decode its payload.
If you have these two things you can build a GraphQL API that will enable most of the use cases, without introducing new concepts (like a meta-report).
Solving 1 is easy. I already expressed that I think this is easy enough that the node itself should take care of that. It’s not essential for the node, but it’s very useful. Not doing it brings the need for yet another component to do it, which IMO is over-engineering.
Regarding 2 if you have some way to configure a mapping between contract address and ABI, like a resolver, which is a classic problem in blockchain, with several different solutions, then you can decode the voucher payload into its components: the “functionName”, and the “args”, with name and type for each arg. Then you can create a GraphQL resolver that is capable of resolving queries for those fields (if the ABI is resolved). Like the following:
Give me non-executed vouchers which contract address is this, function name is “transfer”, arg zero is that.
1 Like
To keep track of voucher executions, we use a listener similar to the one for event inputs. We manage disconnections and other issues. As execution events are received, we update the database to ensure faster responses.
We address the voucher destination problem by decoding the payload as we synchronize with Graphile. It’s more efficient for us to save the decoded data in an indexed database field, as this allows us to serve read requests faster through our HL GraphQL.