[TT-2015] - Clarify how plugins should query API Definition and/or ConfigData

[mcandre]

The limited plugin examples are unclear how one would programmatically query the request's API Definition, ConfigData, etc. in order to parameterize behavior by API Definition.

Should this be done via ctx.GetDefinition?

Which hooks actually populate this method's value? Because many hooks have this returning nil API definition for some reason.

Using exactly Tyk v2.9.4.3, for both the tyk application and for building the plugin.

I tried Go 1.12, 1.13, and 1.14 with no apparent change in behavior.

I replaced the git submodule with a direct cp -r from the $GOPATH/src/... to vendor/..., with no change in behavior.

I tried all the available GO111MODULE values, with largely no effect. Other than flat out breaking compilation when set to on.

Making sure to use the same environment variables, build flags, host OS for both the Tyk binary and the Tyk plugin.

UPDATE

The problem disappears when I stop tracking my Go dependencies with vendor/, and instead place them in $GOPATH/src. Whatever crazy compiler differences are emerging at runtime for plugins on attempting to query Tyk data from requests, are triggered when the Tyk library is managed as a vendored directory.

This problem happens when tracking the Tyk library dependency for a plugin as a git submodule, for example.

Using the exact same commit for both my Tyk binary and my Tyk plugin, 6a4802a, tag v2.9.4.3

[mcandre]

Related: golang/go#41556

[mcandre]

Related: golang/go#27062

[mcandre]

Workaround dependency management script:

$ cat deps.sh
#!/bin/sh
unset IFS
set -euf

go get github.com/TykTechnologies/tyk
sh -c "cd $GOPATH/src/github.com/TykTechnologies/tyk && git checkout v2.9.4.3"

# Re-enable Tyk plugin feature
sh -c "cd $GOPATH/src/github.com/TykTechnologies/tyk && go install -a -tags 'goplugin'"

$ ./deps.sh

[alephnull]

Hey @mcandre, so the problem was that tyk was not built with the goplugin tag?

[mcandre]

That is not the issue. It's an undesirable default build configuration to prevent plugins from being supported. But I am enabling this flag and it does not otherwise play a role here.

This is the problem:

golang/go#41556

In short, Go's plugin system does not work too well. Reflect messes up the resulting types. This breaks Context key lookup and typecasting.

Recommend to phase out enum Context keys in favor of string constants. The typecast still fails, but at least the Context interface{} lookup will resolve.

Go module mode is said to improve these things. Unfortunately, the existing Tyk code does not interavt well with go mod. When I try to pin deoendency to Tyk at v2.9.4.3, then various go mod commands corrupt the version, rewriting the go.mod file to say a different version. Perhaps adopt tighter go mod integration, including proper versioning of import paths. Then there is a possibility of plugins begaving better.

[andyo-tyk]

Closed due to lack of activity; it's a really useful observation so will be considered during ongoing product development.