Passing information between IDs and interface resolution

Đang mở
  • Có gì không ổn?
#1,802 10 bình luận 4 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
graphql, rails, ruby
Lĩnh vực
api, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Ruby
Star
5.4k
Fork
1.4k
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
74

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rmosolgo/graphql-ruby

Tất cả issue của rmosolgo/graphql-ruby

Issue tương tự

Thêm issue về Ruby

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.