We support drop-in SDKs for many languages for several programming languages. Most of them has the same structure and outcome, and even the configuration phase is pretty much the same.
Below you could find the in-depth details about the potential arguments you could be passing when initializing any of the SDK. Depending upon the individual SDKs, other fields could exists but they shall only be SDK dependent.
|Application ID||String||Yes||Unique-ID of the consumer, Learn More|
|Application Secret||String||Yes||Secure secret of the consumer, Learn More|
|Debug||Boolean||No||If you want to enable SDK's logging, Learn More|
|Cache Enable||Boolean||No||If you want to enable Cache, Learn More|
|Cache TTL||Int||No||Time till data is served from Cache, Learn More|
The Application or Consumer are unique Entities that organization create more consuming any SDK or API. The uniqueness of Consumer credentials (Application) help us to identify you individually, while you could visually see which consumers consume what.
Often times, multiple consumers are created for the following use cases:
- Consumer per microservice
- Consumer per customer
- Consumer per region
- Consumer per market
- Consumer per server
So even if you would like to stick to one consumer, that is fine too. The granted API Quota will be distributed across the consumers and we do not have any individual rate limiting per consumer.
Application ID is unique and remains fixed till the lifetime of a consumer. There is no way to rotate or modify it respectively.
Application Secret is a unique string generated by the system for each of the consumer. This could be rotated (or regenerated) at the request. However, it could always be opened in combination with Application ID only.
We rely on the pair of
Application ID and
Application Secret to identify an individual consumer, or an organization respectively.
If you ever get to know that your secret has been compromised, simply navigate to:
Admin Panel -> Settings -> Consumers and select the particular consumer, click
Regenerate Secret button.
The effect of regeneration is Instant and must be used with caution.
We support an option to enabel
Debugging in our SDKs. By enabling the SDK, you could see the internal logging of the SDK in the form of logs printed on
Usually these logs will show the inner workings of the SDK, which could include calling the remote API call to fetch the configurations on the demand. The logs do not include Application Id and Application Secret, therefore they are totally GDPR compliant, though a manual check is recommended.
Ideally only enable Debugging when the SDK's behavior is under scrutiny.
We support minimal Caching in our SDKs for following reasons:
- Reduce API Consumptions
- Reduce Network throughput
- Eliminate Single point of failure
- Prevent Retry/Backoff or any complex engineering
By default "Caching" is not enabled in SDK instance. But it could always be enabled by passing affirmative boolean in the initializing arguments.
SDK Caching TTL
TTL or Time to Live in Caching's context is just to define the life of cached data. Setting the higher value will reduce API calls and burden to fetch often, but it also means that the changes made will take a particular time before making a visible change.
The Pros and Cons should be individually discussed with Stakeholders as to whether Real time is important or Near Real Time could fit the purpose too.
The default TTL is 60 seconds and could be increased to any positive number.
Since we store cached data in memory, if you restart or redeploy the Software Application, the cache will definitely flush and the data has to be regathered again.