Vì sao không nên thiết kế schema phản chiếu đúng cấu trúc bảng database?

Vì client sẽ bị buộc theo cấu trúc lưu trữ: tách bảng, đổi khoá hay chuyển một phần data sang dịch vụ khác đều trở thành breaking change.

Schema nên mô tả nghiệp vụ chứ không mô tả nơi lưu dữ liệu.

# leaks storage — renaming a column breaks every client
type Post { user_id: Int!, created_at: String!, status_code: Int! }

# API-shaped — storage can change underneath
type Post { author: User!, createdAt: DateTime!, status: PostStatus! }

Cách nghĩ đúng là bắt đầu từ nhu cầu client: màn hình cần hiển thị gì, đi từ đó ra kiểu và field. Một kiểu có thể gộp dữ liệu từ ba bảng và một dịch vụ bên ngoài mà client không cần biết.

Biểu hiện thường gặp của việc sao chép bảng: schema đầy các field khoá ngoại dạng số và các bảng nối thay vì quan hệ có nghĩa — client phải tự nối dữ liệu và mất luôn lợi ích chính của GraphQL.

Một cân bằng cần nói rõ: bắt đầu từ nhu cầu client không có nghĩa là tạo một field riêng cho từng màn hình, vì như vậy schema sẽ phình theo số màn hình.