Feature Proposal: Configurable Cursor Type for Federated Graph Compatibility #1218
Closed
anthonycastiglia-toast
started this conversation in
Ideas
Replies: 1 comment
|
There's already an open issue for this: #1028. Let's discuss further there. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Problem
ElasticGraph uses a
Cursorscalar type for pagination fields (more expressive thanString), but this creates incompatibility when composing federated supergraphs. Most GraphQL tooling follows the Relay spec literally, usingStringfor cursor fields. Federation composition fails with:Attempting to override the cursor type with
type_name_overrides: { Cursor: "String" }causes a collision with the built-inStringscalar:Proposed Solution
Add an optional
cursor_typeconfiguration option to control the GraphQL type used for all cursor fields:Options:
cursor_type: "Cursor"(default): Uses theCursorscalar typecursor_type: "String": Uses built-inStringscalar, enabling federation compatibilityThis applies to:
PageInfo.startCursor/endCursor,Edge.cursor, andbefore/afterpagination arguments.Compatibility notes:
cursor_typeoption preserves the current behavior, using theCursorscalar type, so this change is backwards-compatible for existing projects.Cursoris semantically identical toString(base64-encoded opaque string). This only affects the GraphQL schema type.Implementation Overview
Code Changes
Thread
cursor_typeparameter through the schema definition pipeline:RakeTasks→API→State→BuiltInTypes,Factory, andField"Cursor"strings with the configurable value inPageInfo,Edge, and pagination argumentsCursorscalar registration whencursor_type == "String"cursor_typeis either"Cursor"or"String"Tests
cursor_typemodes generate correct schema artifactsDocumentation
elasticgraph-apollo/README.mdcursor_typeparameter in schema customization guideRakeTasksReferences
StringAll reactions