Enriching Kong objects with custom meta-data

Questions
1

Hello!

We need to store additional information (mainly some external IDs (extid=“123-654”)) in each Kong Object we create (Service, Route, Plugin, Consumer, etc…) in order to link them back to our model in another system.
I haven’t seen any way of extending core objects or any free text field (description, comments…) that we could use of this purpose.
Is there currently a way to do this?

Thanks!

/Jean-Baptiste

1 Like
2

Hi,

There two main questions that need to be answered in order to do what you are suggesting:

First question to ask is where to store your data. There are two options:

  • A) One option is putting your meta-data in separate tables (i.e. you would have a ServiceMetas table to store information about each Service) . This could be done on a custom plugin, using custom entities
  • B) The other option is modifying the Service table itself. This would involve updating the schemas and migrations of the tables that you wanted to modify and then running kong migrations upgrade.

Second question is where to put the additional code to deal with these extra fields. I see two options again:

  • C) You could put this code on an external plugin.
  • D) You could modify Kong’s source code to include those fields.

Each combination has its own benefits and problems.

The A-C combination is the most “conservative” one. Everything you do wold be done in a separate plugin. This can mean a bit more of hassle on daily usage - for example, every time you create a new Service you would have to remember to also create a ServiceMeta object - or provide a custom endpoint for doing so. If you want to list Services with their metadata, you will have to create your own endpoint which mixes both tables. But at the same time this combination is the most “upgradeable” - since your tables and your code will be independent from Kong’s.

The B-D combination is the most “ease of daily use”. Not having to deal with two tables means that your metadata is easily available - just query /services. But dealing with upgrades in Kong is going to be really troublesome this way. Your migrations will have conflicts with new migrations in Kong. The source code of your changes will have to be manually adapted to whatever new changes come to Kong.

The intermediate solutions (B-C and A-D) live in between the other two extremes - somewhat easier to use than A-C, but with more difficult upgrades.

The way to chose between depends on your current situation. In general I would recommend going for A-C.

3 Likes
3

Hi @kikito!

Thanks a lot for your detailed reply!
As you suggested, the A-C option is also the one I would prefer as I really don’t consider forking Kong.

Nevetheless, as my customers will not be willing to accept to deploy additional plugins only for my company purpose so I am going to investigate how to manage this purely on our side. The simplest, not intrusive solution would really have been to store some additional info on each kong entity (potentially leveraging a tagging mechanism?).

Thanks again for your swift reply!

Cheers,

1 Like
4

We are working on a “native” tagging mechanism for Kong, in which any Kong entity can be assigned arbitrary tags. I don’t have any estimate of timing or any feature details to share, but stay tuned, we hear your needs, and we hope to fulfill them!

1 Like
5

Sounds great! Thanks for listening to the community :slight_smile: