Small API improvement
koval01 opened this issue · comments
Is your feature request related to a problem? Please describe.
I was going through the details of the requests, and I was interested in the issue with the authorization token. Also, I'm wondering why you have to make a separate status request for each server, instead of doing it in one request.
Describe the solution you'd like
You send an Authorization Bearer to the server to get authorized, that's fine. But you store the token, not in local memory, but in a cookie. Which results in a silly situation where you send the same token twice. Why not use only cookies in the custom version, or change the token storage mechanism?
Describe alternatives you've considered
N/A
Additional context
N/A
It is safer to make each call separate, because HTTP 2 persists the connection, so it should really not be much overhead. This makes error handling simpler. Is server X failed, but Y worked, it's hard to track with a single call.
Where do you see that the key is being duplicated in requests? The browser should use cookies, and the backends use headers.
Where do you see that the key is being duplicated in requests? The browser should use cookies, and the backends use headers.
Here, regarding the authorization token.It is safer to make each call separate, because HTTP 2 persists the connection, so it should really not be much overhead. This makes error handling simpler. Is server X failed, but Y worked, it's hard to track with a single call.
It is difficult to agree with your opinion. Why can't you track errors? You can return the structure for this
[
{
"id":"3418148c",
"running":true
},
{
"id":"e87c81c7",
"running":false
}
]I also don't understand what error catching is, you can call a logger in the process of forming the status body and send this error to the records, or to your analytics server for example.
The only thing I see as true in this statement is the increase in the response delay, but this can be leveled by collecting data asynchronously, since the main load is not computing, but simply waiting for a response from the nodes. It's also possible to split it into pages, which you're already partially doing by splitting the list into 10 servers. However, a periodic stream of requests to check the server's status can pose a problem when using request throttling on a proxy server.
If your proxy is doing throttling that hard, then the web doesn't work well anyways. I would say that's a non-issue, and we should not be sending enough requests to trigger a throttle, that would not excessively trigger elsewhere. Github did 147 requests for me, in 2.5 seconds. We aren't sending many requests.
I do not like the idea of merging requests together, because it complicates the API even more than it needs to be,
URLs, which is how requests are done, are predictable, and uniform.
If one endpoint is completely different than others, then it makes documentation, and implementation, harder.
The auth token is noted. We'll remove the header in future releases, since it should not be needed.
In fact the current state of the v3 branch already doesn't do the auth header anymore
The reason it does work like that in v2 was due to me setting everything up with header usage, then getting to the web socket and learning that browsers are as smart as rocks and don't allow opening a web socket with headers, only cookies are sent along, but a lot of code was already assuming usage of headers so I just added the cookie on top because it's not like it causes any issues (and I cannot remember a single issue resulting from that, so I want to say reality agrees)
Regarding merged status calls: It's not necessarily hard to merge calls, but in my experience, on top of the already given arguments, it usually turns out to produce quite messy code in both frontend and backend, so I can't say I'm eager to deal with mixed response endpoints
I've given you a reason to think about the API scheme, I'm not forcing you to implement it. Since everyone has had their say I will close this discussion. Thank you all.