feat: added support for degraphql_routes

[Prashansa-K]

Summary

Adding support for degraphql_routes so that
they can be managed with decK.

Tests added in separate PR: #155
Working on integration tests in the same PR.

YAML representation:

plugin_entities:
  - type: degraphql_routes
    fields:
      uri: "/contacts"
      query: "query{ contacts { name } }"
      service: my-test-service

The above representation is chosen so that other custom-entities can be added in the same way, without changes to parsing/dumping logic. In the code, FPluginEntity is used as a superset type that can hold different custom entities.

Issues resolved

For Kong/deck#1346

Documentation

• Link to the website documentation PR

Testing

• Unit tests
• E2E tests
• Manual testing on Universal
• Manual testing on Kubernetes

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 8.86700% with 555 lines in your changes missing coverage. Please review.

Project coverage is 27.27%. Comparing base (353fe98) to head (dedb146).

Files with missing lines	Patch %	Lines
pkg/types/degraphql_route.go	0.00%	102 Missing ⚠️
pkg/file/types.go	0.00%	100 Missing ⚠️
pkg/state/custom_entities.go	17.24%	96 Missing ⚠️
pkg/state/builder.go	0.00%	78 Missing ⚠️
pkg/file/builder.go	12.00%	63 Missing and 3 partials ⚠️
pkg/state/degraphql_route.go	24.61%	49 Missing ⚠️
pkg/file/writer.go	16.00%	17 Missing and 4 partials ⚠️
pkg/state/types.go	0.00%	17 Missing ⚠️
pkg/types/core.go	0.00%	15 Missing ⚠️
pkg/types/postProcess.go	0.00%	6 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #154      +/-   ##
==========================================
- Coverage   27.95%   27.27%   -0.69%     
==========================================
  Files         106      109       +3     
  Lines       16358    16967     +609     
==========================================
+ Hits         4573     4627      +54     
- Misses      11303    11851     +548     
- Partials      482      489       +7     

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

[GGabriele]

From a code perspective, this looks good to me, except for a few nits.

I have a few comments from a product perspective though. I see we are following what the KIC team is doing, but:

• we are calling this plugin_entities, but there is nothing related to plugins inside each entity. I understand the reasons because I know what's behind the scenes, but I think users may be confused by the naming
• still on the naming, we usually identify as an entity as a single row of a given type. Now saying I have 10 plugin entities sounds a bit ambiguous: do you have 10 plugins or do you have 10 plugin_entities?
• plugin_entities is not DB-less compatible. I know decK is not fully db-less compatible because some differences exist on consumer_groups, but these differences have been source of friction for our users. Do we intend to further expand on this friction?

[GGabriele]

In this function, please handle cases in which the type assertions fail. We never know what users can include in their files and failing with a graceful error is always desirable

[Prashansa-K]

plugin_entities is not DB-less compatible. I know decK is not fully db-less compatible because some differences exist on consumer_groups, but these differences have been source of friction for our users. Do we intend to further expand on this friction?

So, from kong config db_export I get this output for degraphql_routes:

degraphql_routes:
- id: 73eb90bd-eda7-4c80-aa28-b0d657ea1aa4
  service: 1300b3a5-73c6-4721-a531-4a04ab4cbf13
  updated_at: 1734694480
  created_at: 1734694480
  query: query{ contacts { name } }
  methods:
  - GET
  uri: /contacts

DB-less mode identifies degraphql_routes but not plugin_entities.
We add the former in the KongState, hence the output. This may cause discrepancy while working in db-less mode.

cc: @mheap

[mheap]

I hadn't considered db-less compatibility. This is a very good callout.

How much work would it be to change the format to match DB-less?

[Prashansa-K]

I hadn't considered db-less compatibility. This is a very good callout.

How much work would it be to change the format to match DB-less?

@mheap As of now, I had considered a common yaml format for all plugin entities and the code was doing the parsing, processing and everything else accordingly. Only the API calls were made to degraphql_routes.

DB-less identifies "degraphql_routes" as a separate entity. So, I would have to rewrite a bunch of things to match it to DB-less. This would also defeat the purpose of using a common way and yaml format to handle all plugin entities.

[mheap]

@hbagdi What are your thoughts here? I'd rather not increase the gap between DB-less and Deck formats, but I think this is an instance where we can provide a nicer UX + minimise maintenance cost

[mheap]

Let's proceed with the current design rather than mirroring the DB-less format

[Prashansa-K]

@GGabriele I have added the suggestions you mentioned as a part of the first review.
As we are moving on with the current design, is there anything else that would be required now?
I am adding tests in a separate branch.