Context
Anatomy of a GraphQL ID states the following:
GraphQL ID generation is implementation dependent, and doesn’t follow any convention other than being a URI. There is no guarantee that GraphQL IDs will follow the structure
gid://shopify/{resource}/{rest_id}
as in the previous example, so you shouldn’t generate IDs programmatically. Always treat theadmin_graphql_api_id
string as an opaque ID.
I just migrated my organization’s app from the REST API to the GraphQL API. I was not entirely certain that all of the code would support GIDs, so to expedite the process, I requested legacyResourceId
, where available, and, against the advice of the aforementioned document, constructed GIDs for certain types (largely just Customer, Order) when using them in a query. So far, I have not observed any adverse consequences to doing so.
I have noticed that there is documentation on GIDs that describes their structure in more detail than I would expect for an identifier that should be considered opaque.
Searching this forum, I also discovered that in at least one instance, parsing GIDs to get the underlying legacy/numeric/REST ID was the official recommendation to address a problem.
Question
Is it legitimate to parse the numeric ID out of a GID? Conversely, is it likely to be a problem if we continue to construct GIDs? The only entity type that is relevant to our app which appears questionable to me is Address, which includes additional parameters in the ID. Fortunately, we do not query for addresses, so we do not construct GIDs for that type.
I suppose I’m really just trying to understand the level of risk we are assuming by continuing to employ this strategy, and I would be grateful if somebody could speak to that.
Thank you!