Quick question... Any strategies for rate limiting a single page apps? I have a set of APIs consumed primarily by single page app clients who are issued a single API Key. I see potential problems with it bumping up against concurrent request rate limits if the API Key is shared.
Can you explain/confirm a bit more regarding the question you are asking. Can you confirm you have a gateway integrated with a Portal (in which case what versions?), you have one app that is accessing a APIs using the same key provided by the portal, is this the case?
If so how many endpoints/polices does this equate to on the gateway and have you got the policy snippet included in this/them? (See https://docops.ca.com/ca-api-developer-portal/3-5/en/set-up-the-api-portal/configure-service-policy-integration/convert-the-gateway-service)
If these are the case then the rate limit would be applied per gateway policy. If this does not help let me know why you think the rate limit would be effected.
I assume you're talking about the rate limit in the portal integration fragments.
As you can see there are 2 levels of "plans" -- account plan and api plan, so there are 2 different rate limit assertions here.
One is based on account plan which relevant with organization, another is based on (policy ID + API key). So shared API key should not be a concern.
Yes, I am talking about limits enforced by the portal integration fragments. Please forgive me, I'm still a little unclear on how a shared key wouldn't be of concern in this situation.
Contrived example... If I have an API Plan for my Test environment defined such that I have rate limits set for 5 requests per second, and I have 10 clients sharing the same API Key, shouldn't I run into limits if all 10 clients made a call at the same time?
I didn't state it clearly.
API Key on portal is exactly the ID of "Application", an "Application" can have one or few APIs, their ID is called API ID on portal, and it has one to one relationship with a policy ID on gateway.
As the rate limit depends on the API plan, or "policy ID + API key", or API ID, it has nothing to do with API key (the ID of Application). That's what I meant "API key should not be a concern".
And yes, if the rate limits set as 5 req/sec as per the API plan, 10 clients cannot access the same api at the same time. But this is working as expected as per the API plan. If you think it's not enough, you should assign proper API plan to the API by editing the API on portal and modify the "Applicable Plan(s) *" field. The API plan can be preset by admin under Home -> Dashboard -> APIs -> API Plans
Thanks. I understand your description. Bottom line is that a shared key is going to create problems in a rate limited setup.
So, my question about an approach still remains. In the case where a single page app is considered the client application, how does one manage multiple instances of one (same client app, different users)? Are multiple keys created per client (SPA App - Client #1, SPA App - Client #2, ...)? This would require an additional link to be established and get complicated quickly.
I'm a bit confused. Would you apply the rate limit via portal API plan, or via a rate limit assertion in your policy?
For rate limit assertion, you can configure the rate limit base on any condition you want,
For api plan, you could customize the rate limit assertion in the api plan fragment, but it's not recommended and could cause problem if it's not configured properly.
Sorry if I've confused this a bit... Let me give you my setup and maybe that will clear things up:
My client is that it is a single page app. If I naively deploy my application and have multiple users sharing an API Key, I expect to hit limits quickly. I say this because rate limiting and quota enforcement appears to be tied to the API Key. This is the nature of my question around "strategy" for single page applications.