search

superfluid-finance / protocol-monorepo

Superfluid Protocol Monorepo: the specification, implementations, peripherals and development kits.
https://www.superfluid.finance
Other
875 stars 240 forks source link

[METADATA] Subgraph V1 Endpoints #1951

Closed mmd-afegbua closed 5 months ago

github-actions[bot] commented 5 months ago

Changelog Reminder

Reminder to update the CHANGELOG.md for any of the modified packages in this PR.

kasparkallas commented 5 months ago

I'm fine with this in general. It's a breaking change though for the metadata; and a patch for sdk-core.

Let's quickly take the opportunity to consider whether the whole structure of that object in the metadata makes sense. For example, are the name and cliName still relevant? I would think the answer is yes. @d10r @mmd-afegbua

mmd-afegbua commented 5 months ago

name and cliName imo are relevant. The endpoints however can be done way with. Both for subgraphv1 and automation subgraphs. We'll have to determine the services that are dependent on the current configs tho

d10r commented 5 months ago

I'm against adding canonical endpoints to metadata. They are not supposed to be public, but for internal use, while metadata is a public dataset. For public use (also in frontends), there is the "subgraph-endpoints.superfluid.dev" endpoints. The "subgraph.x.superfluid.dev" canonical endpoints should imo be handled just like the canonical rpc endpoints: the url pattern is known internally, based on canonical network names. No need to enumerate in metadata.

Imo we have a choice to make in this PR: a) just remove the deprecated endpoints, without adding new ones b) adjust the schema to make more sense

If b, I suggest to drop subgraphV1 altogether. name was specific for the hosted endpoint, doesn't make sense anymore. cliName isn't specific to the protocol subgraph, thus the schema shouldn't suggest it is. It could be a standalone key similar to coingeckoId, or we could change the schema such to have an object subgraph where we also nest application subgraphs. If going there, I suggest we have a sync call (@kasparkallas ) for decision making.

I'm also ok going with a) and deferring schema changes, just don't want us to keep having schema changes in uncoordinated way, creating smell. Lets discuss this tomorrow morning, I created a calendar event.

kasparkallas commented 5 months ago

Let's use hostedEndpoint in this PR without a breaking change and switch it to the new public endpoint

github-actions[bot] commented 5 months ago

XKCD Comic Relif

Link: https://xkcd.com/1951 https://xkcd.com/1951