[Compat Data] Add API endpoint for generating MDN compat table



4 years ago
4 years ago


(Reporter: jwhitlock, Unassigned)



(Whiteboard: [specification][type:feature])



4 years ago
What problems would this solve?
An MDN compat table could be generated from multiple loads of resources.  However, this will slow down both the API and MDN pages.  Instead, KumaScript should be able to make a single request that returns all the data needed to generate the table.

Who would use this?
KumaScript or other embedding scripts would use this endpoint when generating feature set tables.

What would users see?
Users would see an MDN page and compat table loading quickly

What would users do? What would happen as a result?
Users would be impressed with the speed of MDN, and embed compatibility tables in their own blog posts.

Is there anything else we should know?
Draft API docs at http://web-platform-compat.readthedocs.org/en/latest/draft/views.html#view-a-feature-set


4 years ago
Blocks: 996570
Severity: normal → enhancement


4 years ago
Depends on: 1066301


4 years ago
Depends on: 1077879


4 years ago
No longer depends on: 1077879
Commits pushed to master at https://github.com/mozilla/web-platform-compat

bug 1063154 - Add `make install_jslint`

Install node and JS lint in the virtualenv

bug 1063154 - Update to latest drf-json-api

Drop workarounds that are now in main repository

bug 1063154 - Working dynamic view

All the data needed to generate the MDN section for a Feature, which is
the Feature plus:
- Features that are descendants of the Feature
- Browsers, Versions, Sections, Specifications, and Maturities for those
- Names of tables (Desktop, Mobile) and the order of tabs in the table
- What Supports are 'important', for browsers where the support changed
  between versions.

100% test coverage, but there is still work to do:
- The list view is like other resource list views (first 10 feature
  views), and isn't useful or performant.
- The representations are larger than they need to be, due to the inclusion
  of nested data (~450K for one sample).
- Multiple database queries are needed to render with a warm cache

bug 1063154 - Use cache for view_features

bug 1063154 - Remove reverse relations

Removed most reverse relations from view_features in the linked
instances.  These are not needed for displaying an MDN table, and can
get quite large.  For example, you don't need to know the IDs of all the
versions or a browser, just the ones in the table, which are all
included in the linked.versions section.

bug 1063154 - Better list for view_features

Display the link to the view_features detail, as well as the feature
representation minus the linked relations.

fix bug 1063154 - Paginate deep feature trees

Large feature trees, such as the root feature node for CSS, can include
hundreds to thousands of descendant features, as well as an explosion of
related items.  This change detects a large feature tree and paginates
the view into 100-feature chunks.  For the CSS tree, it requires over
15 seconds and 1082 SQL queries to generate the first page on my laptop,
and 3.5 seconds and 2 queries from a warm cache.

This also caches the descendant IDs of small feature trees, for a slight
performance improvement in the more common case.


4 years ago
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.