-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(manager): move and update metrics cards in the server view #2241
base: master
Are you sure you want to change the base?
Conversation
@@ -161,6 +161,28 @@ export class ShadowboxServer implements server.Server { | |||
return usageMap; | |||
} | |||
|
|||
async getTunnelTimeByLocation(): Promise<server.TunnelTimeSecondsByLocation> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be implemented once we finalize the endpoint in this PR: Jigsaw-Code/outline-server#1581
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very helpful to see how the API is used. I believe we will benefit a lot from merging the stats flows into one.
55108a4
to
ee8c388
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated with the new endpoint JSON: will merge methods next
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed offline, Per-ASN breakdown was a significant gap during the Iran crisis. It's a confirmed need and and we put a lot of effort to implement it. It's more of a question of how, not whether we want to surface that.
I would like to see that surfaced somehow in this PR, to inform the UX design. We've discussed a simple table, which seems to work well.
Sure thing, working on it! |
Here's an initial PR for a data table component: #2273 |
@@ -168,6 +168,34 @@ export class FakeServer implements server.Server { | |||
getDataUsage() { | |||
return Promise.resolve(new Map<server.AccessKeyId, number>()); | |||
} | |||
getServerMetrics() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps throw an error instead. The tests should define what to return instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear - by extending this mock and overriding the method? Or via injection?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On that note, I'd like to see some tests for the 2 scenarios (supported and unsupported), probably in app.spec.ts
?
); | ||
|
||
return result; | ||
} catch (e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't fall back on every error. We should pick an API based on the server capability.
An improvement would be to fallback only on 404 errors, but that still means two requests for every update call in the non experimental case. It should be one.
We need a mechanism that will allow for a single request on the non experimental case.
One approach would be using streaming requests or websockets, then the 404 would be ok, because it's only once for all updates.
Perhaps we query in the constructor?
Or it comes in the server config?
@sbruens for thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like testing for "experimental features" in the constructor would be the simplest? If an experimental endpoint 404s in the constructor test, set a flag for that endpoint to false. Then we don't have to change the server while minimizing the number of requests in the manager.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry missed this thread until now. Constructor test works for now. 👍
{ | ||
icon: 'timer', | ||
name: this.localize('server-metrics-user-hours'), | ||
units: this.localize('server-metrics-user-hours-unit'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really how we should be formatting units. Use the standard libraries instead: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat#unit_2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a follow up PR that fixes this and breaks out the units that are baked into the messages (e.g. / last 30 days
) as mentioned above. It just needs to be rethought, as I assumed relying on the localizer was enough. I'll make a ticket for it, fair?
Co-authored-by: Vinicius Fortuna <[email protected]>
Co-authored-by: Vinicius Fortuna <[email protected]>
|
||
let totalUserHours = 0; | ||
for (const {tunnelTime} of serverMetrics.server) { | ||
// convert to hours |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Kind of a pointless comment tbh given the naming of the variables. If it is unclear, prefer to make 60*60 self-documenting, then you won't need the comment. Something like:
const HOUR_IN_SECS = 60 * 60;
...
totalUserHours += tunnelTime.seconds / HOUR_IN_SECS;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha, I think this comment was provided by Gemini. I'll make it self-documenting.
); | ||
|
||
return result; | ||
} catch (e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry missed this thread until now. Constructor test works for now. 👍
@@ -168,6 +168,34 @@ export class FakeServer implements server.Server { | |||
getDataUsage() { | |||
return Promise.resolve(new Map<server.AccessKeyId, number>()); | |||
} | |||
getServerMetrics() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On that note, I'd like to see some tests for the 2 scenarios (supported and unsupported), probably in app.spec.ts
?
TODOs: