Page Comparison

Problem

Different application consuming the API’s but the backend has no idea who is consuming it and from where the request coming is from. 

...

To avoid querying the datastore every time, we can cache custom entities in-memory on the node, so that frequent entity lookups don't trigger a datastore query every time, but happen in-memory, which is much faster and reliable than querying it from the datastore (especially under heavy load).

A. Lazy caching: Cache custom entities in-memory on the node on the first request, so that frequent entity lookups don’t trigger a datastore query every time (only the first time), but happen in-memory. On every first request by a consumer, associated App IDs to requester consumer will be retrieved from datastore and that will be cached, but If there are no APP IDs associated then empty App ID's arrays will be cached. 

By doing so it doesn’t matter how many requests the consumer makes, after the first request every lookup will be done in-memory without querying the datastore.

...

 B. Full table cache on kong service start: Cache the all the records exist in the table on every node immediately after kong service start, so entity lookups don’t trigger a datastore query every time.   

• Pros
  • No lookup on the data-store except initial so it will help for reducing latency in request response time. 
•  Cons   
  • If the database is size is large then the cache and invalidation process will take time. 
  • Every Node will query datastore after the start of service that will put a load on data-store for some time. 
  • It will cache the all records even if record not in use and that will unnecessarily increase cache size on every node. 

Kong does not seem to have an a specific "event" that is broadcasted on startup, so this approach may not be feasible. init_worker is available, but the implementation for that seems complex.

Cache Storage

The cache will be stored in the key-value pair where the key will be 'appid'.consumer_id and value will be an array of APP ids.

...

-- hooks.lua

local events = require "kong.core.events"
local cache = require "kong.tools.database_cache"

local function invalidate_on_update(message_t)
  if message_t.collection == "appids" then
    cache.delete("appid."..message_t.old_entity.consumer_id)
  end
end

local function invalidate_on_delete(message_t)
  if message_t.collection == "appids" then
    cache.delete("apikeysappid."..message_t.entity.consumer_id)
  end
end

return {
  [events.TYPES.ENTITY_UPDATED] = function(message_t)
    invalidate_on_update(message_t)
  end,
  [events.TYPES.ENTITY_DELETED] = function(message_t)
    invalidate_on_delete(message_t)
  end
}

...

In the example above the plugin is listening to the ENTITY_UPDATED and ENTITY_DELETED events and responding by invoking the appropriate function. The message_t table contains the event properties

Error message

• If App ID is not sent with the request: X-APP-ID can't be blank
• Consumer and APP-ID mapping doesn't exist:  Consumer and X-APP-ID mapping doesn't exist
• Invalid App ID: Invalid X-APP-ID

Questions / Note

1. Can we map same APP ID to different consumers ?
2. Process for issuing app id needs to be updated - for developer installation (in this case Sunbird credentials are needed and provided by support team) and for server installation (in this case Ekstep credentials will be needed which the developer currently creates himself)

...