feat: relations #303

vertex451 · 2025-08-07T14:51:09Z

Resolves #254

Features

Relations are resolved in GetItem only. For ListItem and both subscriptions it is disabled for now. When user try to query related field, he will receive null.
Relation nesting is limited by 1, but in future we can change it to bigger number. Also, nesting level is hardcoded for now, later we can pass it as a user input.

TBD

Handle relation resolution when the same kind from different groups is referenced.

Testing

Tested 21.08 at b6d83af commit in local-setup by creating an account via portal UI and querying related object(check attachments)

Demo

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

pteich

I left some comments and suggestions.

gateway/resolver/relations.go

gateway/resolver/resolver.go

pteich · 2025-08-15T13:51:36Z

gateway/schema/schema.go

 	}

+	// Initialize the relation enhancer after gateway is created
+	g.relationEnhancer = NewRelationEnhancer(g)


It's the same circular dependency as above. I don't really see a need to separate it in another struct. You don't have an possibility to add a different RelationEnhancer so it makes no sense. I would move the methods to the Gateway. You can however keep it in a separate file.

You are not going to believe - I seen those deps, but decided to go with them since it is in the same package.
But eventually you have the point - no need to move it under a different struct.

listener/pkg/apischema/builder.go

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

aaronschweig · 2025-08-18T07:59:18Z

listener/pkg/apischema/builder.go

+			if schema.VendorExtensible.Extensions == nil {
+				schema.VendorExtensible.Extensions = map[string]any{}
+			}
+			schema.VendorExtensible.Extensions[common.ScopeExtensionKey] = apiextensionsv1.NamespaceScoped
 		} else {
-			schema.VendorExtensible.AddExtension(common.ScopeExtensionKey, apiextensionsv1.ClusterScoped)
+			if schema.VendorExtensible.Extensions == nil {
+				schema.VendorExtensible.Extensions = map[string]any{}
+			}
+			schema.VendorExtensible.Extensions[common.ScopeExtensionKey] = apiextensionsv1.ClusterScoped


Why was this changed, was therer a deprecation somewhere? The old code looked cleaner

Overlooked this comment, now I noticed it, returned AddExtension method.

aaronschweig

A few questions:

How does it verify, that none of the "deep" nesting is provided, as we wanted it to be limited to one level deep?
How is prevented for watches, as with the field resolver we have the ability to execute this query on everything.
How would you solve the multiple kinds for different group errors? E.g. imagine a resource that has a ThingRef but Thing is provied via group A and group B - how would you know which would be the right kind to use for the relation?

aaronschweig · 2025-08-18T08:00:10Z

listener/pkg/apischema/builder.go

+	if crd == nil {
 		return b
 	}

-	schema, ok := b.schemas[getOpenAPISchemaKey(*gvk)]
-	if !ok {
+	gkv, err := getCRDGroupVersionKind(crd.Spec)


was it intentional, that the short path with the categories got removed?

I did this change having in mind different versions of CRD.

Before Categories were applied to the "preferred" version of a CRD
After Categories are applied to ALL versions of a CRD

It is not directly related to the relations feature, but it is needed for consistency.

Let me know if it makes sense for you.

aaronschweig · 2025-08-18T08:00:35Z

listener/pkg/apischema/builder.go

+			if resourceSchema.VendorExtensible.Extensions == nil {
+				resourceSchema.VendorExtensible.Extensions = map[string]any{}
 			}
+			resourceSchema.VendorExtensible.Extensions[common.CategoriesExtensionKey] = apiResource.Categories


Same question as above

I touched this code as well for the same reason, but behavior remains the same compared to main branch - the change is in refactoring, less parsing and early returns.

I was asking more about why the easily readale AddExtension was removed with this custom logic

That was not necessary, returned AddExtension methods instead of manual manipulation.

aaronschweig · 2025-08-18T08:02:55Z

listener/pkg/apischema/builder.go

+		key := strings.ToLower(gvk.Kind)
+		b.kindRegistry[key] = append(b.kindRegistry[key], resourceInfo)


What happens if we have the same kind provided by different groups? We have a bug here. In go map keys can be arbitrary, so it would be more benefitial to use the GroupVersionKind struct as an index here, rather than only the kind, the circumvent future name collisions with the kind.

Especially in the platform-mesh usecase this might be very common, that the same kind is provided form x different apiGroups

you are right - we may have silent overrides here, fixing it.
Fixed

aaronschweig · 2025-08-18T08:04:43Z

listener/pkg/apischema/relationships_test.go

+	// Two schemas with same Kind different groups/versions - first should win
+	first := schemaWithGVK("a.example", "v1", "Thing")
+	second := schemaWithGVK("b.example", "v1", "Thing")
+	b.SetSchemas(map[string]*spec.Schema{
+		"a.example.v1.Thing": first,
+		"b.example.v1.Thing": second,
+		"c.other.v1.Other":   schemaWithGVK("c.other", "v1", "Other"),
+	})


This test is basically testing the exact wrong thing that I mentioned in the other comment - this would in my view be a bug, not intended behaviour

I change a logic a bit - now server preferred resources has priority first, if no, we put in the first place resources from core group, then by version stability (v1 > v1beta1 > v1alpha1).
Logic is preserved in findBestResourceForKind.

And I added a test that checks if server preferred resources comes first.

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

…into relations-new

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 · 2025-08-21T12:35:14Z

How does it verify, that none of the "deep" nesting is provided, as we wanted it to be limited to one level deep?

How is prevented for watches, as with the field resolver we have the ability to execute this query on everything.

How would you solve the multiple kinds for different group errors? E.g. imagine a resource that has a ThingRef but Thing is provied via group A and group B - how would you know which would be the right kind to use for the relation?

Deep Nesting Prevention:
The schema builder's expandWithSimpleDepthControl() function only processes *Ref fields at the top level and doesn't recursively add relationship fields to the generated relationship fields themselves, limiting nesting to exactly one level.
Watches Prevention:
The RelationResolver uses detectOperationFromGraphQLInfo() to analyze the GraphQL path and isRelationResolutionAllowedForOperation() to only enable relationships for GET_ITEM and GET_ITEM_AS_YAML operations.
Multiple Groups Resolution(not tested yet):
I used kubectl-style priority resolution (preferred versions → core groups → alphabetical order) at schema build time to automatically select the "winner" group.

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 · 2025-08-21T12:49:00Z

gateway/resolver/resolver.go

@@ -117,16 +130,16 @@ func (r *Service) ListItems(gvk schema.GroupVersionKind, scope v1.ResourceScope)
 			return nil, err
 		}

-		err = validateSortBy(list.Items, sortBy)


not related to this issue, but we should sort only in case of sortBy param only

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

github-actions bot added the feature label Aug 7, 2025

vertex451 force-pushed the relations-new branch from 4928320 to c4e3060 Compare August 14, 2025 11:52

github-actions bot removed the feature label Aug 14, 2025

vertex451 marked this pull request as ready for review August 14, 2025 12:03

vertex451 requested a review from a team as a code owner August 14, 2025 12:03

vertex451 force-pushed the relations-new branch from c4e3060 to ed11c85 Compare August 14, 2025 14:21

github-actions bot added the feature label Aug 14, 2025

feat: relations

ad375ed

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 force-pushed the relations-new branch from 19ea7a5 to ad375ed Compare August 15, 2025 08:32

vertex451 added 3 commits August 15, 2025 13:23

removed hardcoded versions

20546e2

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

simplidied buildKindRegistry

249f80a

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

consistentcy

96a22a2

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 self-assigned this Aug 15, 2025

vertex451 added this to the 2025.Q3 milestone Aug 15, 2025

pteich requested changes Aug 15, 2025

View reviewed changes

vertex451 added 3 commits August 15, 2025 17:32

resolver

de3c7a5

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

removed circular dep from gateway

0787ae7

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

better sorting

44afd8b

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 requested a review from pteich August 15, 2025 15:48

pteich approved these changes Aug 17, 2025

View reviewed changes

aaronschweig reviewed Aug 18, 2025

View reviewed changes

aaronschweig requested changes Aug 18, 2025

View reviewed changes

vertex451 added 8 commits August 18, 2025 11:54

smart sorting with preffered resource first

9f14440

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

use GVK instead of Kind as a kay

5cd1b84

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

add test with preferred resource

a9a360c

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

use map native methods

54b8d92

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

nesting

f286765

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

limit relation resolver by getItem only

c2bca5b

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

fix conflict

e578071

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

reproduced kubeconfig conflict resolution logic

b5d9b0b

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 added 5 commits August 21, 2025 09:09

Merge branch 'main' of github.com:openmfp/kubernetes-graphql-gateway …

80f107b

…into relations-new

fix tests

2ece5fa

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

fix tests 2

e5b5c8f

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

fixed getOperationFromContext bug

ba51492

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

removed unworked code

8897cdf

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 requested a review from aaronschweig August 21, 2025 12:14

reduced diff

ce396e4

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

vertex451 commented Aug 21, 2025

View reviewed changes

vertex451 added 2 commits August 21, 2025 14:58

improved WithCRDCategories

09b357b

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

simplified depth control

b6d83af

On-behalf-of: @SAP a.shcherbatiuk@sap.com Signed-off-by: Artem Shcherbatiuk <vertex451@gmail.com>

aaronschweig approved these changes Aug 21, 2025

View reviewed changes

vertex451 merged commit 4019c9d into main Aug 21, 2025
12 checks passed

vertex451 deleted the relations-new branch August 21, 2025 13:23

		key := strings.ToLower(gvk.Kind)
		b.kindRegistry[key] = append(b.kindRegistry[key], resourceInfo)

feat: relations #303

feat: relations #303

Uh oh!

Conversation

vertex451 commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Features

TBD

Testing

Demo

Uh oh!

pteich left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aaronschweig left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vertex451 Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vertex451 commented Aug 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vertex451 commented Aug 7, 2025 •

edited

Loading

vertex451 Aug 18, 2025 •

edited

Loading