proxy-server

Use Case:

• proxy-server is the service to handle request for proxy paths.

• Previously every proxy paths request from api-gateway was going to tether-server but now we have created proxy-server and now proxy paths requests will be directed to proxy-server from api-gateway.

• proxy-server and tether-server uses same code repository and share image-patch for deployment.

• From api-gateway we have directed paths to proxy-server, some are given below:

tether/govt-apis/public

tether/epod-service/v2/integration

tether/marketplace

other requests for tether/ from api-gateway will go to tether-server.

• Diagram:

Open

Open

Configuration and Request & Response Processing:

We can add the configuration in config.json file inside 'urls’ list inside json 'redirection-proxy'.

• context is the path of api hit by client which is needed to be proxied to some other target.

• target is the targeted host. If target is different for different types of methods then use target_get/target_put/target_delete/target_post.

• manipulateReqPath is the name of the file in proxy-server code which has the logic for manipulating the request.

• manipulateResPath is the name of the file in proxy-server code which has the logic for manipulating the response.

(If you want to manipulate request or response then only pass file name in manipulateReqPath/manipulateResPath. context and target are mandatory, others are not)

• If want to use same file for all methods(POST, GET, etc) of api request, use manipulateResPath/manipulateReqPath.
  If request file is different for different methods, then use
  manipulateReqPath_put,manipulateReqPath_post,etc. for request manipulation.
  If response file is different for different methods, then use
  manipulateResPath_put,manipulateResPath_post,etc. for response manipulation.

(For manipulating any specific request/response, in config if you write, say manipulateResPath_post, then no use of passing manipulateResPath.
Similarly for target, in config if you write, say target_get, then no use of passing target.)

See example below:

Example 1:

Example 2:

Rate Limit Support:

We are using @upstash/ratelimit package for rate limiting.
Link: https://github.com/upstash/ratelimit#example

• Algorithms Supported: FIXED_WINDOW,SLIDING_WINDOW,TOKEN_BUCKET,OPEN
  The details related to algorithms is given in above github link.
  OPEN algorithm is used to not have rate limit for any api.If we do not want rate limit for any api then we can set algo as OPEN.

• Configuration: Configurations are stored in rateLimitConfig.json file in json format.
  In it key is string which is guid of the company and value is list of objects. This object has:

  • path: The api path.

  • method: Method of the api.

  • algo: Algorithm to use for the rate limiting.

  • time: Time window of the rate limit in seconds. This is mandatory field.

  • allowed: Number of hits allowed in the given time window. This is mandatory field.

  
  Example:

  { "COM-8e1b4e79-3d86-415c-95fd-aac28c81adca": [ { "path": "/vehicle/location/push", "algo": "FIXED_WINDOW", "time": 60, "allowed": 3 }, { "path": "/trip", "method": "GET", "algo": "FIXED_WINDOW", "time": 60, "allowed": 3 }, { "path": "/trip/id/:pathVariable", "algo": "FIXED_WINDOW", "time": 60, "allowed": 2 }, { "algo": "SLIDING_WINDOW", "time": 60, "allowed": 2 } ], "default": [ { "path": "/connect/test/rateLimit", "method": "GET", "algo": "FIXED_WINDOW", "time": 60, "allowed": 5 }, { "algo": "FIXED_WINDOW", "time": 60, "allowed": 3 } ] }

• How to Set Rate Limit for API: In setting rate limit config we have two ways in config:

  1. Setting config for a particular company: This will be based on guid of that particular company.

  2. Setting same config for all other company: For this we will have to use key as default at the root level instead of guid.

     
     In the config object, inside value (which is the list) of the guid or default key, there are following cases:

     1. path and method provided: Rate limit will be applicable to that particular path and method.

     2. path provided: Rate limit will be applicable to that path for all methods.

     3. path and method both not provided: Rate limit will be applicable to all paths. It’s like default for all paths for particular guid or default key.

• Response on rate limit reached: On rate limit reached, we return response with status 429 and give below information in headers:

  • x-rate-limit-limit: Limit of the api hit.

  • x-rate-limit-remaining: Remaining hits in rate limit.

  • x-rate-limit-reset: Remaining time after which you can hit api for successful api response.

• Grafana Link to Monitor: https://grafana.int.freighttiger.com/d/vvvlWif4z/integration-services?orgId=1&from=now-2d&to=now&viewPanel=67