Skip to content
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

Add endpoint to retrieve feature IDs for missing one implementation counts #1110

Closed
jcscottiii opened this issue Jan 27, 2025 · 0 comments · Fixed by #1235
Closed

Add endpoint to retrieve feature IDs for missing one implementation counts #1110

jcscottiii opened this issue Jan 27, 2025 · 0 comments · Fixed by #1235

Comments

@jcscottiii
Copy link
Collaborator

jcscottiii commented Jan 27, 2025

Description:

Currently, the /v1/stats/features/browsers/{browser}/missing_one_implementation_counts endpoint only returns the counts of features that are missing one implementation for a given browser and date range. This issue proposes adding a new endpoint to retrieve the actual list of feature IDs that contribute to those counts.

Proposed solution:

Add a new endpoint, /v1/stats/features/browsers/{browser}/missing_one_implementation_counts/{date}/features, that accepts the following parameters:

  • browser: The target browser.
  • date: The specific date for which to retrieve the feature IDs.
  • browser (query parameter): A list of other browsers to compare against.
  • paginationToken: A token for pagination.
  • pageSize: The maximum number of results to return per page.

This endpoint would return a paginated list of objects, each containing the feature ID and potentially other relevant metadata in the future.

Tradeoffs:

  • Why not include feature IDs in the existing listMissingOneImplemenationCounts endpoint?
    • Returning a potentially large array of feature IDs (up to 1000) in the existing endpoint could significantly increase the response size and impact performance, especially when clients only need the counts.
    • It would also make the response less focused and harder to parse for clients that only need the counts.
  • Why not add a generic metadata endpoint?
    • Combining a large array of feature IDs with other smaller metadata fields could lead to inefficient data structures and potential performance issues.
    • A dedicated endpoint for feature IDs allows for more specific filtering, sorting, and pagination options, tailored to the needs of retrieving feature information.

Benefits:

  • Provides more detailed information about missing one implementation counts.
  • Allows users to drill down into the specific features that are contributing to the counts.
  • Enables more targeted analysis and investigation of feature support gaps.
  • Offers flexibility for future expansion with additional metadata and filtering options.

Next steps:

  • Update the OpenAPI specification to include the new endpoint.
  • Implement the corresponding handler logic to retrieve and return the feature IDs.

Something like this:

  /v1/stats/features/browsers/{browser}/missing_one_implementation_counts/{date}/features:
    get:
      summary: Returns the list of feature IDs that were counted as missing one implementation on a specific date for the given browser.
      operationId: listMissingOneImplFeatures
      parameters:
        - $ref: '#/components/parameters/browserPathParam'
        - in: path
          name: date
          schema:
            type: string
            format: date
          required: true
          description: The date for which to retrieve the feature IDs.
        - $ref: '#/components/parameters/paginationTokenParam'
        - $ref: '#/components/parameters/paginationSizeParam'
        - in: query  # Add otherBrowsers parameter
          name: browser
          description: >
            A list of browsers to check if {browser} is lagging behind on
            features. The list is provided by specifying repeating query parameters.
            Example:?browser=fooBrowser&browser=bazBrowser
          required: true
          schema:
            type: array
            items:
              $ref: '#/components/schemas/SupportedBrowsers'
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/MissingOneImplFeaturesPage'

MissingOneImplFeature:  # Schema for a single feature object
  type: object
  properties:
    feature_id:  # Can add more properties here later
      type: string
      description: The ID of a feature.

MissingOneImplFeaturesPage:  # Schema for the paginated response
  type: object
  properties:
    metadata:
      $ref: '#/components/schemas/PageMetadata'
    data:
      type: array
      items:
        $ref: '#/components/schemas/MissingOneImplFeature'
  required:
    - data

Previously: Modify the OpenAPI for missing one implementation to include the feature IDs
Building on #1109, we want to expose that new data.

The openapi document should be modified to allow for that metadata for each data point.

We may want to stop using BrowserReleaseFeatureMetricsPage (and BrowserReleaseFeatureMetric) and instead create new types for the missing one implementation endpoint. But non breaking changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant