Getting started with tyk

Hi Team,
Have few queries regarding on-boarding -

  1. How can we upgrade tyk in k8s
  2. What is complexity of on-boarding & maintaining api’s in tyk
  3. Can we publish api’s using swagger documentation into tyk or we have to do it through dashboard only by publishing each api in tyk ? If we can do it through swagger what is the process to publishing it ?
  4. What does it mean by cloud & self managed ? Can we deploy to our own cloud in our own vpc ?

Hi,

Your timing is perfect for your third question. We have just released Tyk 4.1 which brings a new level of ‘early access’ OAS 3.0.x support for Tyk. You can import an existing API defined in OAS 3.0.x via an API call and Tyk will automatically add in the specific fields to make it a live API running inside Tyk. You can see a little video of this in action here:

A tutorial for the ‘import’ can be found here:

and if you are using VS Code, this might be helpful:

To get going more generally with OAS, you can find the documentation here:

This talks through the high level concepts, then walks through a series of tutorials.

If you have any feedback, please don’t hesitate to add a post and tag it with the ‘OAS’ category.

1 Like

I would try to answer questions 1, 2 and 4.

  1. How can we upgrade tyk in k8s

If you deploy Tyk to K8s then a standard rolling update is all that is needed. If helm charts was used, then just update the versions of the components, and Tyk will upgrade

  1. What is complexity of on-boarding & maintaining api’s in tyk

You can managed your APIs using our Tyk Operator. I think you can also use the dashboard here.

  1. What does it mean by cloud & self managed ?

Self managed is simply self-hosted or on-prem. You handle the deployment, management and maintenance yourself. You can read more here.

For cloud, we simply just handle the deployment for you. You can compare our offerings to make the best decision.

  1. Can we deploy to our own cloud in our own vpc ?

Does VPC mean Virtual Private Cloud? If yes, then I think this should be possible with our Self-Managed offering.

1 Like

Hi @Olu
Can we deploy into our own AWS VPC (Virtual Private Cloud) in private subnet with Tyk Cloud offering ?

I don’t think this is possible. Tyk Cloud is handled and deployed by Tyk internally.

Thanks @Olu
Have few more questions-
1- Is there any limit on number api’s can be present in catalog ?
2- Can rate limit be done on session object ? It’s not clear from this docs
3- Which algorithm is used for rate limiting do we have algorithm options for open source ?
4- What is key in key-based rate limit ? Is it auth token ?
5- What are other key supported for key-based rate limiting ?
6- What does it mean by environment & team in architecture section in plans & pricing ?

1- Is there any limit on number api’s can be present in catalog ?

No I don’t think so but having a lot in view can be unwieldly

2- Can rate limit be done on session object ? It’s not clear from this docs

Absolutely. The session object has properties for the applied rate limits.

3- Which algorithm is used for rate limiting do we have algorithm options for open source ?

Yes, there ae various algorithm options when using rate limiting. They can be set in the gateway config file or environment variable

However, if you meant to ask for hashing algorithm, the please have a read at our docs.

4- What is key in key-based rate limit ? Is it auth token ?

I assume key should mean the access key or the token that is used for authorizing a request. However, can you share the source or link where you saw this? It would help with context.

5- What are other key supported for key-based rate limiting ?

Would need more context here? Maybe what you are looking for the types of authentication and authorization options we have.

6- What does it mean by environment & team in architecture section in plans & pricing ?

A team is a collection of people in an organisation. While an environment is a group of deployments that can contain one or more of your gateway(s) and control plane(s) (dashboard, portal and MDCB). You can find more information here

  1. Link for ques 4 & 5 -
    Rate Limiting or Throttling Here it’s documented as:

limiting the rate of calls the user of a key can make to all available APIs

so, wanted to know what is key here & what other keys are supported ?

https://tyk.io/docs/basic-config-and-security/control-limit-traffic/rate-limiting/#:~:text=Rate%20Limiting%20Overview,Limiting%20Concepts%20for%20more%20information

It is assumed that the APIs being protected with a rate limit are using our Authentication token Authentication mode and have policies already created

is auth token key here ?

Attached link as text since new users can only attach 2 links in a post.

  1. For ques 3
    I’m interested in sliding window algorithm & from the docs of above algorithm it’s not clear. Can you please let me know if tyk support algorithm like sliding window, sliding log, leaky bucket etc. for rate limiting ?

The key is the access key (token, certificate, username or password etc.) that is used for authorising the request. Except keyless, all methods mentioned in my earlier statement below are supported

Yes, auth token is the key here.

I have asked internally but can you share your goal? I think some of our limiters would work for your use case

  1. We have a use case where the api are having more request in last 15 sec. So, Wanted to have sliding window rate limiter.
  2. Can IP based rate limit be applied without setting nginx rule ? We do not want to use nginx ?
    Creating an IP-based rate-limiter with Tyk and JavaScript middleware - Tyk API Gateway

Based on my reading of what a sliding window rate limiter is, Tyk’s rate limiting options would work for you. The underlying ultimate goal is to ensure the number of requests are not exceeded of a given period. The choice with Tyk is about decising between performance and accuracy:

  • Distributed - is the default. It’s the fastest, but may be inaccurate due to how the Gateways estimate how many requests they should allow. This is based on the number of Gateways in the cluster and the current load, which is achieved by sharing information through Redis pub/sub channels.
  • Transactional and non-transactional - both read/write Redis data to keep an accurate record of usage. This approach has a performance impact, but is very accurate.

Yes it can. I think nginx was used to get the headers. Tyk has context variables that can be used to retrieve those same information. So you don’t have to use nginx

Yes @Olu what a sliding window rate limiter is this is exactly what we needed.
But which among this implements sliding window and which one are you suggesting in above answer (Tyk’s rate limiting options would work for you) for our use case ?

Using non transactional should work. Redis rolling (transitional) could lead to performance issues on large requests

Do Tyk Open Source supports following features ?

  1. Gateway Mocking
  2. Dashboard GUI
  3. Kubernetes Ingress Controller
  4. Caching
  5. gRPC Transformations
  6. Datadog
  1. Gateway Mocking

Not explicitly sure what you mean here. We do have a mock middleware that provides mocking capabilities. Here is a sample API definition.

  1. Dashboard GUI

No. It’s a commercial product that requires a license. Our open and commercial products are displayed on our stack documentation. You can read more about our licensing here. If you have more questions, then please check out the already asked questions

  1. Kubernetes Ingress Controller

Yes. Have you had a look at our helm chart and this blogpost

  1. Caching

Also yes. Please see our caching documentation

  1. gRPC Transformations

Not sure what you mean but our documentation about gRPC and gRPC plugins is a good place to start

  1. Datadog

Yes but this works through our Pump component. Please have a look through our Pump documentation on setting up Datadog

I do recommend inputting your keyword in the search bar and looking for any relevant documentation on. The doc is a great resource that explains it better than I could.

Thanks @Olu for helping us. Asked since it was not clearly mentioned which of features in Gateway are supported in Open Source.

Hi @Olu
Can you please let me know answers to these questions

  1. Do we store rate limiting couters in local or redis ?
  2. How OAuth2 can be used as a rate limiting key ?

@Aayush_Kumar_Gupta Sorry for the delay

  1. Do we store rate limiting couters in local or redis ?

Yes, the rate limits counters are stored in Redis when using transactional and non-transactional rate limiters. For transactional (both redis rolling and sentinel), you can observe the prefixed key rate-limiter-<key-hash> just like quotas in your associated Redis. However, for non-transactional, the key name is random and hard to detect.

For distributed rate limiters, no centralized Redis is used and the counters are are stored locally in memory.

  1. How OAuth2 can be used as a rate limiting key ?

Have you checked out our documentation on OAuth2.0