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

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: General, enhancement)

Description

[John Whitlock [:jwhitlock]]

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

Comment 1

[MDN Team (:mdn-dev)]

Commits pushed to master at https://github.com/mozilla/web-platform-compat

https://github.com/mozilla/web-platform-compat/commit/e482171003f725bbcba37df04088d16988056746
bug 1063154 - Add `make install_jslint`

Install node and JS lint in the virtualenv

https://github.com/mozilla/web-platform-compat/commit/170c046154e24e403d224a8d313e4213d9faf995
bug 1063154 - Update to latest drf-json-api

Drop workarounds that are now in main repository

https://github.com/mozilla/web-platform-compat/commit/54fac61c7d28d92d6b9852ea4d9d3c64971f2d6f
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
  Features
- 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

https://github.com/mozilla/web-platform-compat/commit/e3b65fa9fc4df995b9562ec9ae8d03de83659a2a
bug 1063154 - Use cache for view_features

https://github.com/mozilla/web-platform-compat/commit/ec4078b82a276fe3f30f0080fcd02d2d9565cd4b
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.

https://github.com/mozilla/web-platform-compat/commit/e04782a266d2a8bc61f3c2aa275c2a0e1114ed73
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.

https://github.com/mozilla/web-platform-compat/commit/11b0f4968f8171dec4c84286929e2a221a0350e7
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.