At the moment, we have two separate requests to poll for meeting and attendance requests.
While this does somewhat simplify the server architecture, it has a not insignificant bandwidth penalty (since we need to negotiate two separate TCP connections and send two separate HTTP responses with two separate headers). It also forces us to raise the api rate limit a ludicrous amount (since we might be polling two separate endpoints at most 60 times per second per endpoint, it needs to allow at least 120 requests/s).
It might be worth consolidating the two endpoints into a single /api/poll endpoint, that returns info about both meeting events and attendance events. We might also consider somehow excluding this endpoint from the global rate limit, or setting a specific, more lenient rate limit exclusively for that endpoint.
At the moment, we have two separate requests to poll for meeting and attendance requests. While this does somewhat simplify the server architecture, it has a not insignificant bandwidth penalty (since we need to negotiate two separate TCP connections and send two separate HTTP responses with two separate headers). It also forces us to raise the api rate limit a ludicrous amount (since we might be polling two separate endpoints at most 60 times per second per endpoint, it needs to allow at least 120 requests/s).
It might be worth consolidating the two endpoints into a single
/api/pollendpoint, that returns info about both meeting events and attendance events. We might also consider somehow excluding this endpoint from the global rate limit, or setting a specific, more lenient rate limit exclusively for that endpoint.