The ReportStream Experience team is researching how to solve for unauthenticated users (i.e. users without login) to access the validator UI and endpoint. To achieve that, we need to ensure our endpoint is opened up safely before the UI is made public. In doing this research, we now have additional questions about how our rate-limiters work.
What you need to know
Previous research is documented this in ticket: 6495
Acceptance criteria
-Open questions
How does our rate-limiter work? (We know it's through Akamai, but need details.)
Do we need to limit this public page more than other pages? Can we even do that?
Do we need to separate the endpoint in any way from the prime_dev container that other functions run in? Do we gain anything by doing this?
To do
Heather to set up meeting with Experience Team and DevOps
Problem statement
The ReportStream Experience team is researching how to solve for unauthenticated users (i.e. users without login) to access the validator UI and endpoint. To achieve that, we need to ensure our endpoint is opened up safely before the UI is made public. In doing this research, we now have additional questions about how our rate-limiters work.
What you need to know
Previous research is documented this in ticket: 6495
Acceptance criteria
-Open questions How does our rate-limiter work? (We know it's through Akamai, but need details.) Do we need to limit this public page more than other pages? Can we even do that? Do we need to separate the endpoint in any way from the prime_dev container that other functions run in? Do we gain anything by doing this?
To do