Feature Request: Please allow a tyk-sync dump to produce a "minimal" output

Product Feature Requests & Feedback
1

Tyk sync’s outputs could be more human readable if they only exported the settings which were not default.

As an example, at present I have a tyk gateway configured with 5 test endpoints. Running tyk-sync dump against this instance creates 5 json files with 457 lines each. The challenge here is that aside from ~3 settings that aren’t default.

From a developer experience and long term scalability perspective if the objects that are output by tyk sync were optionally “slimline” developers would likely have a much easier time of understanding what’s going on AND potentially get to a point where simpler endpoints could be built outside of the GUI interface.

2

some examples of things I feel are probably extraneous. If use_basic_auth is false, then the entire basic auth object doesn’t have to be included… and SINCE that use_basic_auth key is false by default, that doesn’t have to be included either.

    "use_basic_auth": false,
    "basic_auth": {
      "disable_caching": false,
      "cache_ttl": 0,
      "extract_from_body": false,
      "body_user_regexp": "",
      "body_password_regexp": ""
    },

slimming down the auth_configs would save about a hundred lines and so on.

If we could get APIs down to the minimal needed I think it would reduce cognitive load on developers and teams.

3

Alexander - definitely agreed.

Tyk Sync is designed for dump and migrate use cases - where it can fit in CICD pipelines nicely and the verbosity is a strength, not a weakness.

To make working with it easier, we have a VSCode extension to help write API definitions

Also - more exciting and should be right up your alley, you can write your API Definitions as OAS, again, write from your IDE with Intellisense.

Outside the scope of your question, however for k8s use cases, we also wrote Tyk Operator to manage API definitions as CRDs and its designed to be minimalistic as you described.

4

Interesting! These are great leads thanks. I’m happy to take away the idea that verbosity in CI/CD land becomes an advantage … though … is there any argument or reasoning behind that? What cases make that an advantage long term?

I’d love to be able to explain that in clear terms to anyone who questions me on it.

5

With pleasure!

Verbosity means there are no assumptions or implicit defaults. Everything is defined explicitly. The cost of this of course is a field overload. As your post suggests, users would rather have sensible defaults hidden instead of defined.

The current format is not dev friendly. The new OAS API definition and the Tyk Operator will fix this!

6

Yeah - I’m finding the tyk operator documentation is still pretty arcane and difficult to parse into something usable locally.

I’d love to get any additional insights you can provide with devising a working end-to-end CICD plan for use in a multi-repo environment. I’ve tried detailing my hopse/plans here: Still a little stuck on implementing an end-to-end CICD story

Any and all expert guidance around that flow would be really welcome. I’ve managed to test out the first half locally (dev workflow) but the CICD half is … not as strong :smile:

2 Likes