Small API improvement about pufferpanel HOT 6 CLOSED

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.

from pufferpanel.

Where do you see that the key is being duplicated in requests? The browser should use cookies, and the backends use headers.

from pufferpanel.

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.

from pufferpanel.

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.

from pufferpanel.

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

from pufferpanel.

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.

from pufferpanel.