Passing information between IDs and interface resolution

Abierto
  • ¿Algo no está bien?
#1,802 10 comentarios 4 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
graphql, rails, ruby
Área
api, backend

Línea de trabajo

Start by tracing the node field's GID-based record loading and the later Node interface type resolution. Investigate how the resolved type or GID could be retained between those steps; done means Type1 and Type2 can share Foo while node(id: ...) resolves the requested concrete type without requiring a proxy workaround.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Imagine you have a single rails model

class Foo < ActiveRecord::Base
end

and two GraphQL types both implementing Node:

type Type1 implements Node { id ... }
type Type2 implements Node { id ... }

For weird implementation reasons, Foo is the backing model for both GraphQL types. Not in that Foo has some sort of attribute that tells you whether it's Type1 or Type2, but in that every Foo backs a Type1 and a Type2 in the API.

In order to implement Node, we give the two types ID schemes, e.g. gid://shopify/Type1/1 and gid://shopify/Type2/1. Note that from the API perspective these IDs refer to different objects, but at the implementation layer they end up loading the same ActiveRecord object.

As it turns out, it's really difficult to make the following GraphQL query work:

{
  node(id: "gid://shopify/Type1/1") {
    id
  }
}

This is because the concrete type gets resolved twice. First, to load the record, we get the GID, parse out the type, convert that to the appropriate underlying model, and load from the database. The resolver for the node field thus returns an instance of Foo which is correct.

However, we then have to resolve the type again. node is a field of type Node, which means we go through the interface type resolution to determine which concrete GraphQL type (Type1 or Type2) is backing this instance of Node. In this second iteration, all we have are the abstract type (Node) and the implementation object (Foo). This is insufficient information to determine the correct concrete type, since we no longer have access to the GID.

Ideally this second resolution wouldn't even need to happen. We've already resolved the type once to load the object, there's no point in trying to resolve it again. At the very least, this second step needs access to the GID so it can determine the correct concrete type.

(We've worked around this issue by always wrapping Foo in a proxy object at load time so that it can itself hold the type it was loaded to serve, but the code for that is super-gross.)

@rmosolgo @theorygeek

cc @felix-d in case I've missed anything from your case

Lenguaje dominante
Ruby
Estrellas
5.4k
Forks
1.4k
Merge medio
1 d 20 h
PR fusionados (30 d)
83

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rmosolgo/graphql-ruby

Todos los issues de rmosolgo/graphql-ruby

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.