I’m trying to understand the overall architecture of how Tyk works. As of now I’m planning of using Tyk Gateway CE and would like to further my knowledge on how the Data structures of each of the component map to each other. I referred Data structure overview, but seems like its outdated and Relationship between organisation,policy and key(session token), is not making much sense. If you may share the links to the relevant docs or a brief explanation of the same would help!
I would also like some guidance of how Open Banking can be achieved with Tyk Gateway CE. Any success stories, use cases, videos or any docs relevant to this would be of great help.
Hi @James.
I have thoroughly explored the contents in Tyk APIs.
Thanks for sharing the link, but what I’m trying to seek information about is the architecture of how the APIs, Keys and Policies work together. A holistic look on how they relate to each other in terms of Data structures.
Although it may seem basic, this guide can also be helpful, as it moves through the api/key/policy relationship. i.e. it shows how a policy is effectively a template that can apply to/override a key.
In fact, we always recommend following the ‘getting started’ tutorial from start to finish, as it introduces the concepts behind Tyk.
I have extensively read all the docs pertaining to what you’ve shared in the previous posts.
The issue is that I’m not able to picture holistically as to how keys and policies are linked to each other or the relationship between them. Because, in the definition of Policies, there is a key “access_rights” wherein we can mention what all APIs need to be enforced with this Policy. Same is the case with Keys and APIs, but I’m unable to understand the link between Policies and Keys.
Hope you can provide some info on that. It would really help!
A key is either based on a policy or has its own access rights to APIs. Not both.
Policies are the templates that set the defaults for keys that are based on them. You can override the defauls in the key if you choose but the metadata, limits and quotas will be inherited from the policy or policies. The access rights to APIs are determined in the policy or policies attached to the key. This has the advantage of being able to update all the keys attached to a policy by updating the policy itself rather than each key individually.
You can also create keys that do not reference a policy and therefore you have to select the API they have access rights for. Nothing is inherited because there are no policies attached.
