feat: added support for degraphql_routes

[Prashansa-K]

Changes added:
degraphql_routes can be created via deck on Kong GW or Konnect.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 17 lines in your changes missing coverage. Please review.

Project coverage is 29.28%. Comparing base (05091c1) to head (8d99be8).

Files with missing lines	Patch %	Lines
tests/integration/test_utils.go	0.00%	15 Missing ⚠️
cmd/root.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1505      +/-   ##
==========================================
- Coverage   29.29%   29.28%   -0.02%     
==========================================
  Files          62       62              
  Lines        6637     6653      +16     
==========================================
+ Hits         1944     1948       +4     
- Misses       4554     4567      +13     
+ Partials      139      138       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[GGabriele]

@Prashansa-K a few comments:

• decK uses dictionaries to reference other entities. This PR is going to support the following:

custom_entities:
  - type: degraphql_routes
    fields:
      uri: "/foo"
      query: "query{ foo { bar } }"
      service: svc1

While in decK the following is supported instead (notice service: svc1 vs service: {name: svc1}:

services:
- host: mockbin.org
  name: svc1
routes:
- name: foo
  paths:
  - /foo
  service:
    name: svc1

• the above way of referencing entities is actually not recommended, and instead decK encourages to use the following format instead (no explicit reference of service:

services:
- host: mockbin.org
  name: svc1
  routes:
  - name: foo
    paths:
    - /foo

I see that something like this is not supported with custom_entities:

services:
- host: mockbin.org
  name: svc1
  custom_entities:
    - type: degraphql_routes
      fields:
        uri: "/foo"
        query: "query{ foo { bar } }"

Error: 1 errors occurred:
	reading file tests/integration/testdata/sync/036-degraphql-routes/kong.yaml: validating file content: 1 errors occurred:
	validation error: object=[{"fields":{"query":"query{ foo { bar } }","uri":"/foo"},"type":"degraphql_routes"}], err=services.0: Additional property custom_entities is not allowed

• decK heavily relies on entity IDs, not names. So even if the reference is made by name, decK resolves it and uses only the ID. For example, if I sync the following file..

services:
- host: mockbin.org
  name: svc1
routes:
- name: foo
  paths:
  - /foo
  service:
    name: svc1

..I can see that decK makes a request with the following payload (notice "service":{"id":"970e5a5f-3655-4f05-b974-5b3d04ee124c"}, no reference of name):

{"response_buffering":true,"https_redirect_status_code":426,"destinations":null,"created_at":1738073502,"methods":null,"name":"foo","preserve_host":false,"id":"d8eec475-7538-4611-9590-1a83577d5ab7","headers":null,"updated_at":1738073502,"service":{"id":"970e5a5f-3655-4f05-b974-5b3d04ee124c"},"tags":null,"hosts":null,"strip_path":true,"path_handling":"v0","regex_priority":0,"protocols":["http","https"],"paths":["/foo"],"snis":null,"sources":null,"request_buffering":true}

Instead, in this PR, I see that both ID and name are sent in the payload (this will break Konnect, other than being a change to the usual pattern):

POST /services/svc1/degraphql/routes HTTP/1.1
Host: localhost:8001
User-Agent: Go-http-client/1.1
Content-Length: 177
Content-Type: application/json
Accept-Encoding: gzip

{"id":"f7617fea-b37c-474e-b58e-096ae7ba9494","service":{"id":"970e5a5f-3655-4f05-b974-5b3d04ee124c","name":"svc1"},"methods":["GET"],"uri":"/foo","query":"query{ foo { bar } }"}

[Prashansa-K]

the above way of referencing entities is actually not recommended, and instead decK encourages to use the following format instead (no explicit reference of service

@GGabriele I understand but at the time of designing, we opted out of nesting for beginning. The yaml format we decided was done in this way so that other custom-entities, when added, can adhere to the same format. We may think about adding the nesting support in the future. At the moment, the usage predicted for this is unclear. IIRC we only have verbal ask from one customer. So, it doesn't make sense to me to spend more time on adding nesting support.

While in decK the following is supported instead (notice service: svc1 vs service: {name: svc1}:

We can still make this change. I will check them out on local. I will submit a separate PR in GDR for this then.
As I understand, going forward this should apply to all parent entities, as in plugin: {id: pId}.

Instead, in this PR, I see that both ID and name are sent in the payload (this will break Konnect, other than being a change to the usual pattern):

Yes, Konnect is breaking at the moment. I will see if I can strip down the name reference internally.

[Prashansa-K]

For routes, we are stripping the service name reference, if it is present so as to make it compatible with Konnect APIs.
Will do the same for degraphql_routes. https://github.com/Kong/go-database-reconciler/blob/main/pkg/types/route.go#L19

[Prashansa-K]

@GGabriele

1. The service-name stripping is done here and merged: fix: strip service name from dql_routes for konnect apis go-database-reconciler#186
   Creation via Konnect API works fine now even if a deck file passes service name.
2. The dict usage for service ref part is in progress here: fix: changed dql routes format to show dict for service go-database-reconciler#187
   It works fine and tests are updated. I am yet to add some validation to avoid panics. So, it is a draft PR for now.

[Prashansa-K]

@harshadixit12 You can review the PR now. Support for Konnect is added as well, along with all necessary tests. Gabriele's comment about using a dictionary is incorporated too via the GDR update. The same is covered in tests too.

[harshadixit12]

@Prashansa-K few comments/questions I had -

1. Degraphql support was implemented it some past PRs - correct? In this PR, we are making changes to use dict for service?
2. Using dict for service - wont it break for some users if they had already started using?
3. service.routes is missing in the testdata files added - I was able to create degraphql routes on local gateway after adding this
4. service.plugins key not needed? (the examples here suggest configuring the plugin, which doesn't seem to happen in the files added)
5. Service ID present in dump for custom entity, is this expected? (if I create a dump, reset gateway and try to sync using the same dump file, it throws an error Error: service "4dc1d405-8fd2-42a0-af06-61fcfa998085" not found)

[Prashansa-K]

@Prashansa-K few comments/questions I had -

1. Degraphql support was implemented it some past PRs - correct? In this PR, we are making changes to use dict for service?

We are enabling deck to allow customers to create degraphql_routes here. This is the final PR in order to add support to deck.

2. Using dict for service - wont it break for some users if they had already started using?

This is NA, as this feature is new and not released yet.

3. service.routes is missing in the testdata files added - I was able to create degraphql routes on local gateway after adding this
4. service.plugins key not needed? (the examples here suggest configuring the plugin, which doesn't seem to happen in the files added)

I didn't understand these two questions.

5. Service ID present in dump for custom entity, is this expected? (if I create a dump, reset gateway and try to sync using the same dump file, it throws an error Error: service "4dc1d405-8fd2-42a0-af06-61fcfa998085" not found)

Good find. Could you file a bug on GDR? I will pick it up from there in the next round. It's a small fix.

[harshadixit12]

@Prashansa-K for 3, 4, if I follow the instructions in https://docs.konghq.com/hub/kong-inc/degraphql, and then create a dump - this is what it looks like.

custom_entities:
- fields:
    methods:
    - GET
    query: query { viewer { login } }
    service:
      id: 4dc1d405-8fd2-42a0-af06-61fcfa998085
      name: github
    uri: /me
  id: c28f696e-55eb-4d33-918e-c1dcdce7f9c4
  type: degraphql_routes
services:
- connect_timeout: 60000
  enabled: true
  host: api.github.com
  name: github
  plugins:
  - config:
      graphql_server_path: /graphql
    enabled: true
    name: degraphql
    protocols:
    - grpc
    - grpcs
    - http
    - https
  port: 443
  protocol: https
  read_timeout: 60000
  retries: 5
  routes:
  - https_redirect_status_code: 426
    id: 5280f4db-13bf-45a7-a928-28aba9ff1cd5
    path_handling: v0
    paths:
    - /graphql
    preserve_host: false
    protocols:
    - http
    - https
    regex_priority: 0
    request_buffering: true
    response_buffering: true
    strip_path: true
  write_timeout: 60000

If I compare that with tests/integration/testdata/sync/036-degraphql-routes/kong.yaml - I'm seeing some keys missing in kong.yaml - services.plugins and services.routes - should we add these two as well?

If I make GET request to localhost:8001/services/svc1/plugins after syncing tests/integration/testdata/sync/036-degraphql-routes/kong.yaml, I'm getting an empty array - but the response is different when I follow steps in https://docs.konghq.com/hub/kong-inc/degraphql/

[Prashansa-K]

If I compare that with tests/integration/testdata/sync/036-degraphql-routes/kong.yaml - I'm seeing some keys missing in kong.yaml - services.plugins and services.routes - should we add these two as well?

If I make GET request to localhost:8001/services/svc1/plugins after syncing tests/integration/testdata/sync/036-degraphql-routes/kong.yaml, I'm getting an empty array - but the response is different when I follow steps in https://docs.konghq.com/hub/kong-inc/degraphql/

In the test-file, we are creating a global plugin. The steps you took from the doc is creating a service-scoped plugin. That's why, you don't see the services.plugins field and get an empty array. If you directly fetch localhost:8001/plugins, you will see the global plugins.
I am also not creating any service routes in the test file. This is to keep things to a minimal and just focus on syncing the degraphql-routes, via the proposed format (custom-entity).