Skip to content
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

[METADATA] Subgraph V1 Endpoints #1951

Merged
merged 11 commits into from
Jun 12, 2024
Merged

[METADATA] Subgraph V1 Endpoints #1951

merged 11 commits into from
Jun 12, 2024

Conversation

mmd-afegbua
Copy link
Collaborator

No description provided.

Copy link

github-actions bot commented Jun 7, 2024

Changelog Reminder

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

  • CHANGELOG.md modified
  • Double check before merge

@kasparkallas
Copy link
Contributor

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
Copy link
Collaborator Author

mmd-afegbua commented Jun 10, 2024

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
Copy link
Collaborator

d10r commented Jun 10, 2024

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.

@mmd-afegbua mmd-afegbua force-pushed the metadata-subgraph-endpoints branch from a562f8c to 1cdf9bc Compare June 12, 2024 10:10
@kasparkallas
Copy link
Contributor

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

@mmd-afegbua mmd-afegbua marked this pull request as ready for review June 12, 2024 11:45
@d10r d10r enabled auto-merge June 12, 2024 11:50
@d10r d10r added this pull request to the merge queue Jun 12, 2024
Merged via the queue into dev with commit 8b4f683 Jun 12, 2024
13 checks passed
@d10r d10r deleted the metadata-subgraph-endpoints branch June 12, 2024 17:08
Copy link

XKCD Comic Relif

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants