Provide Requests Output For Scripts and Transactions
Closed this issue · 10 comments
Issue To Be Solved
Access Nodes have rate limits. For the nodes hosted by Dapper Labs, the limits can be found here:
https://developers.flow.com/nodes/access-api-rate-limits
The rate limits are broken down according to the type of request.
Understanding rate limits are critical to designing and implementing scalable designs/architectures on Flow.
It would be really powerful if developers could switch on the outputting of requests that were made during each transaction or script execution.
This would provide a greater understanding of the requests that are being made to access nodes, allowing developers to make informed decisions when designing their platforms. It would also be a huge help in preventing platforms from hitting rate limits, and provide extra transparency into the inner workings of interactions.
hey @ph0ph0 ,
What kind of output do you have in mind?
This is a bit complicated topic, as user agents depends on your setup. To give a quick example, if dapp is using transaction and scripts with fcl on user side ( user-agent being the account owner ) then those IP limits are directly assigned to the user IP address, but if you make calls from backend, those are assigned to your backend IP. I think this distinction is important ( so putting them into single bucket as requests would not be so helpful )
Hey @bluesign, yes i was aware of this and it's the reason that I would like to be able to see the type of and number of different requests that are executed when an interactions is run.
I think it is important for scalability because most developers will be using some distribution of scripts and transactions across the frontend (FE) and the backend (BE). For example, on the BE, they may require admin transactions, and also scripts to populate user objects to pass back to the FE, among other things. As you mentioned, the limits are directly assigned to the IP address from which the requests originate. I think that being able to see how many requests and the type of request (as some have different limits) that a tx or script creates is important in understanding how to better structure dapps and manage loads during periods of high traffic. The absence of this information could result in developers making uninformed decisions that lead to BEs that run a lot of txs/scripts per user that is active on the site, leading to rate limits quickly being hit.
On the Alchemy dashboard, they were able to show the requests (screenshot below), but not from which interaction they originated, which made this information not very useful imo.
What I would like to suggest is a flag on the emulator, something like --show-requests maybe, that outputs the number of requests by type that an interaction generates. The user could set this to true and would be able to run scripts/txs on an individual basis to assess the requests made by the interaction.
The output could be a table, or a sequence (to preserve the order), or a combination of both.
eg: output is combination of both sequence and table, shown below:
Sequence
- GetLatestBlock
- GetEventsForHeightRange
- GetLatestBlock
- GetLatestBlock
- GetLatestBlock
- GetLatestBlock
- GetLatestBlock
- GetLatestBlock
- GetLatestBlock
Table
| Request | Count |
|---|---|
| GetLatestBlock | 8 |
| GetEventsForHeightRange | 1 |
I'm sure there will be a better way of representing this in the output of the emulator, but hopefully this illustrates my point.
Interested to hear what you think!
This is actually a very nice idea, we already have emulator metrics for GRPC (at http://localhost:8080/metrics ) but I don't think we have them for REST. ( should be easy to implement )
But actually, this can be shown better similar to how alchemy does.
onflow/flow-go#3691 partially closes this ( just merged to master), but I think rest of the stat analysis can be better done on metrics end point. So maybe we can close this.
@ph0ph0 yeah when we will be managed to use, I will test and document, lets keep this open till then
Nice, looking forward to it!
@bluesign any updates on this one?
Actually rest metrics pr is merged in flow-go ( we are using also ) but somehow I don't see them in metrics endpoint. I need to debug a bit.
fixed via onflow/flow-go#4288, I will check again when it is merged