-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serve Solver List I: Fetch & Store #15
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments regarding the code below.
Regarding this comment:
Pending the existence of view_solverstable for Gnosis Chain (PR - duneanalytics/spellbook#1268) we would like to store an additional field "chainID" in the json file and merge the solver lists from all networks. Alternatively we could store two separate files. Not sure which is preferred (cc @alfetopito)
I don't really mind how the data is stored, but I would rather be able to consume it per network rather than all in the same response with a chainId parameter, to be consistent with every other API method, e.g.:
- Mainnet: api.cow.fi/mainnet/api/v1/...
- Gchain: api.cow.fi/xdai/api/v1/...
Then, to provide this behaviour with the minimum amount of transformation required on the API side, it might be worth to store them as a separated file.
Ben, the dune v2 promised to have a direct API. Is that coming or not? Do you know roughly any timeline? Otherwise, the PR looks good |
Still waiting on this. I will ping them again and ask. But for now I think this is in good shape. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Update - Now that we have the Alpha API key for Dune, we may not need this (since we can query directly through their API). We may want to keep this as a backup - it also offers the ability to refresh (which is not yet available with Dune's supported API). |
Not sure exactly what the status is here. @alfetopito is this something you'd like to see go live as is for your purposes? |
We are closing the solvers page design, and implementation will start soon. What's the earliest that this info can be provided, be it via this or Dune API? |
Well we could merge this and then expose and endpoint in our existing dune bridge api. I haven't exactly worked with the routing and serving part of this project, but I would imagine it could be ready in a staging environment in less than a week from here. |
That would be great! |
Hey, @alfetopito - we chatted about this today in the sync and I think this approach might be soon outdated and maybe a bit of over engineering. I recall you suggested that you could parse the file from dune abstractions. Do you think you could set yourself up for this and in the meantime I can get make the solver list available via the DUNE V2 api Who knows, maybe I can whip something up really quick. Cc @josojo |
Actually, for example (you already have a Dune API key - for beta testing) and this query returns the solvers (by name) based on the abstractions view. I can lift the condition of being active, although I suspect this is what you want... Mainnet: https://dune.com/queries/575593 |
Given that we might soon have a solution coming from Dune API as you mention, I'm fine using a hardcoded file locally in the Explorer until it is exposed from the backend. Those 2 queries are perfect for creating this hardcoded file for now |
@alfetopito - you don't need to hard code the content (you can use the Dune API that we gave you for the volume and num traders to fetch this from their Beta V2 Engine API). |
But if we consume that directly on the frontend, the API key will be exposed, unlike cow.fi where it's not since it's rendered server side. |
Understood, then raw file parsing works for now. Sorry for the misunderstanding. |
As part of an effort to make our solver list universally accessible via our own API service. This is the service that would periodically fetch the most recent solver list and store it as a json file.
As a second step, we would add a route to the API (here in this project) which serves the JSON content.
Pending the existence of
view_solvers
table for Gnosis Chain (PR - here) we would like to store an additional field "chainID" in the json file and merge the solver lists from all networks. Alternatively we could store two separate files. Not sure which is preferred (cc @alfetopito)