Allow owner to select the API they are viewing the analytics for

[bajiat]

The main user of the dashboard is an API owner who checks the dashboard for performance and to get insight into API usage. When API owner is viewing the dashboard, they should also be able to define or select an API they see analytics for (from their APIs)

User story

As an API owner
I want to determine which API I want to see the analytics for
so that I can gain insight on single API usage

Design

• Selected API
  
• API selection
  

Definition of done

• User has a method for selecting a single API on dashboard page
• Based on the user selection, dashboard charts (and table) get updated
• User can easily select another API for viewing the analytics
• User interface clearly indicates what API you are looking at (vs. looking at all APIs)
• Optionally, user can switch back to all APIs owned by this particular owner

Resources

• Upstream support request: Filter analytics data by API Backend? NREL/api-umbrella#252

[Nazarah]

Is there any case that user wants to see multiple APIs? for comparison purpose?

[bajiat]

See Brylie's support request and Nick's answer to it: NREL/api-umbrella#252

[brylie]

@frenchbread will you be taking this task forward?

[frenchbread]

Yes.

[brylie]

This is number one priority. High priority and urgent. It blocks several other tasks.

[frenchbread]

Got it.

[frenchbread]

Currently the URl for making requests looks like <host>/<prefix>/<api_id>?api_key=<api_key>. Should I make filtering by <api_id> directly?

[brylie]

Generally, an API owner will need to see the API Name. However you link the API Name to the filter is up to you. E.g. if API ID is easiest, go with it, but make sure the end-user has an intuitive way to filter the dashboard.

[frenchbread]

Actually now, when sending custom requests (with api backend id in the URL) there are only 404 responses. I'm not sure how did we manage to add API Id to the request URL but it won't work that way I thing because now API Id is represented in URL as a separate page - not as a parameter.

[frenchbread]

One more question: If there is no API selected, should we show anything?
Possible scenarios:

• Showing "Select API to view analytics for" message with no data
• Showing analyrics data for all APIs managed by current user
• Something else (like the entire analytics in ES) - maybe for admin view

[brylie]

I like the second option, showing analytics for multiple/all API Backends.

We can also consider having a multi-select box, so that an Administrator or API Owner can select multiple API Backends. I have added Bootstrap Select to a project recently, and it is easy to use.

[brylie]

One short-term goal here is to try and share most of the Dashboard code/functionality between Administrators and API Owners.

[frenchbread]

Cool. Yea, that is possible. What about using API Id in the URL then?

Actually now, when sending custom requests (with api backend id in the URL) there are only 404 responses. I'm not sure how did we manage to add API Id to the request URL but it won't work that way I thing because now API Id is represented in URL as a separate page - not as a parameter

[brylie]

If API ID works, go for it. We just need to show the end-user the API Name, so they understand what they are seeing.

[frenchbread]

It works but response is 404, because API ID is provided not as a query parameter

[frenchbread]

That's what I mean.

No API selected:

API selected:

In scope of this issue it works though.

[brylie]

As per the discussion with Nick (@GUI) and your observations, using the the API ID won't work for analytics queries. It was suggested that we filter by the 'path' or 'frontend_prefix'.

How are you filtering the API?

[brylie]

The UI looks good by the way.

[Nazarah]

I have a suggestion. Can we only show the 3XX, 4XX and 5XX requests in the HTTP status code chart with bigger bars. Currently they look small. Also I was thinking that is it necessary to keep the 2XX status bar there? because we are already will be showing success rate if API calls in overview information. SO the HTTP Status code chart should focus on issues other than 2XX.
If you wish to keep interactiveness of all the chart with each other, I'd suggest to increase the unit size for measuring 3XX, 4XX and 4XX so their corresponding bars appear bigger.

[brylie]

One challenge about making the 3, 4, and 5xx bars larger with respect to the 2xx bars, is that there are sometimes 'orders of magnitude' fewer requests with 3xx, 4xx, or 5xx codes. E.g. there may be:

• 1,000 requests with 2xx status code
• 100 requests with 4xx status codes
• 10 requests with 5xx status code
• 1 request with 3xx status code

This type of situation is where a logarithmic scale becomes useful.

@frenchbread can we configure the HTTP Status Codes chart to use a logarithmic scale (d3.js) for the request counts axis?

[frenchbread]

I'm filtering charts by API Id now. It works, but I can switch to frontend_prefix if needed.

[frenchbread]

I think we can configure the HTTP Status Codes chart to use a logarithmic scale but is separate issue.

[brylie]

@Nazarah would you please open an enhancement for the HTTP Status Codes chart? I can add details about the logarithmic axis, if you will add your initial reasoning.

[brylie]

@frenchbread where are you getting the API ID from? If we cannot query Elastic by API ID, then perhaps frontend_prefix is more consistent with what the user would see. How difficult would it be to use frontend_prefix?

[frenchbread]

@brylie If you look at the screenshots above, in the table there is a row with request_path value. API ID is populated there.

It won't be more difficult to use frontend_prefix for filtering.

[brylie]

OK, so does the API ID in the screenshot (/soundcloud/{{ API ID }}/ ) come from the Apinf database or API Umbrella?

[frenchbread]

Yes, and that's why when I send sample requests they return 404.

[brylie]

OK, just use the frontend_prefix. Lets forget about the API ID for now.

[frenchbread]

Updated filtering to use front-end prefix instead of API id.

[brylie]

Cool beans. Let me know when this is ready for review.

[frenchbread]

OK, I'm now going to add filtering for "default selection" - combined analytics for all APIs owned by a user.

[brylie]

@frenchbread good idea 😄