Page MenuHomePhabricator

Remove the MobileView API
Closed, ResolvedPublic3 Estimated Story Points

Description

NOTE: Removing this is blocked on T286836, T236733, T236733, and T236731

The MobileView API was originally made for apps. Now that the Page Content Service is being used by the apps, MobileView's value is questionable given its maintenance cost.

It has been marked as deprecated in T210808. Of course deprecating should be done carefully - there may be other consumers of this API, but we should explore who they are and how we can get them using MCS.

Note: The MobileFormatter will continue to exist for MediaWiki mobile web views. The MobileView API actually has a lot of logic that is not shared by the MobileFormatter.

Problems with the API

  • Older versions of the apps use it for main page
  • Uses an API parameter names inconsistent with action=parse
  • Has a mainpage parameter that doesn't do anything.
  • Nobody is maintaining it any more.

Timeline

As of June 2020, neither of the current app releases (iOS 6.6 and Android 2.7.50320) relies on MobileView directly. They are using the Page Content Service. Prior to these releases, the Android app was using the Mobile Content Service and the iOS app was using MobileView. Enough users will have to upgrade to Wikipedia for iOS 6.6 or newer before MobileView can be removed (T236731).

The other element blocking removal of MobileView was incomplete language variant support in Parsoid (T43716). The Page Content Service used Parsoid for most wikis but needed to use the MobileView API for Chinese Wikipedia. Since T43716 was stalled, the Page Content Service was updated to remove dependence on MobileView for zhwiki and use the action=parse API (see T236733 for more information)

Related Objects

StatusSubtypeAssignedTask
DeclinedNone
ResolvedJdlrobson
DeclinedNone
OpenNone
OpenNone
OpenNone
Invalid GWicke
Resolvedliangent
Resolvedthiemowmde
OpenNone
Resolvedcscott
Resolvedcscott
ResolvedElitre
Resolvedcscott
Resolvedcscott
Resolvedcscott
Resolvedcscott
Resolvedcscott
OpenNone
Resolvedcscott
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedBUG REPORTJgiannelos
OpenNone
DeclinedNone
ResolvedJdlrobson
ResolvedJdlrobson
DuplicateNone
DuplicateNone
ResolvedTgr
ResolvedAnomie
Resolvedtstarling
Resolvedcoren
ResolvedAnomie
DeclinedBUG REPORTNone
ResolvedAnomie
ResolvedEsanders
ResolvedEsanders
Resolvedssastry
ResolvedAnomie
ResolvedCKoerner_WMF
Resolvedjhsoby
ResolvedTgr
DeclinedTgr
Resolvedcoren
ResolvedAnomie
ResolvedTgr
DeclinedNone
Resolvedssastry
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedDeskana
ResolvedCKoerner_WMF
ResolvedWhatamidoing-WMF
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedUrbanecm
ResolvedTgr
ResolvedTacsipacsi
ResolvedTgr
ResolvedCKoerner_WMF
ResolvedJdlrobson
DeclinedNone
DeclinedNone
OpenNone
ResolvedAmmarpad
ResolvedJdlrobson
ResolvedKizule
ResolvedKizule
DuplicateBrandonXLF
ResolvedJdlrobson
ResolvedAmmarpad
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The PageGateway uses the mobileview api to get and allow lazy loaded references and to get pages. How could this work without the MobileView API? Can it work? What are alternative options?

One alternative could be the references endpoint in PCS. The drawback for the web is probably that it requires RESTBase, though.

Jdlrobson updated the task description. (Show Details)
Jdlrobson renamed this task from [EPIC] Deprecate the MobileView API to Remove the MobileView API.Dec 19 2019, 4:09 PM
Jdlrobson changed the task status from Open to Stalled.
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from Inbox to Doing on the User-Jdlrobson board.
Jdlrobson moved this task from Doing to Next up on the User-Jdlrobson board.

Current rate is 14 hits per second. I'd really like us to talk to the iOS team about getting rid of this code sometime this year cc @ovasileva @LGoto as it's a big chunk of code we can throw out and no longer worry about.

From a personal perspective, it's causing me anxiety as one of the two members of the team that actually review the code comfortably.

Jdlrobson changed the task status from Stalled to Open.Mar 8 2021, 11:58 PM
Jdlrobson moved this task from Triaged but Future to unsed on the Readers-Web-Backlog board.
Jdlrobson raised the priority of this task from Medium to High.Jan 27 2022, 9:02 PM

Change 764916 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] Drop ApiMobileView

https://gerrit.wikimedia.org/r/764916

Change 764916 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Drop ApiMobileView

https://gerrit.wikimedia.org/r/764916

nray reassigned this task from nray to Jdlrobson.
nray added a subscriber: nray.

I know this has been deprecated for a few years (rEMFR7205a0563d96: Mark the mobileview API as deprecated; I'll check locally how that deprecation appears)...

But was this deprecation, and more specifically the pending removal actually announced anywhere?

I don't see a User-notice tag on the task, and there was no email to the mediawiki-api-announce mailing list. This is how I became aware of it, because a user emailed the owners of said list.

As per https://en.wikipedia.org/w/api.php

Status: The MediaWiki API is a mature and stable interface that is actively supported and improved. While we try to avoid it, we may occasionally need to make breaking changes; subscribe to the mediawiki-api-announce mailing list for notice of updates.

Having a look on the api-feature-usage dashboard, I don't actually see any usages https://logstash.wikimedia.org/goto/5dc90017447bd46902c904507540107d but I don't know if this is a false negative...

Screenshot 2022-06-03 at 08.48.56.png (854×2 px, 207 KB)

Screenshot 2022-06-03 at 08.49.20.png (576×1 px, 107 KB)

Screenshot 2022-06-03 at 08.48.44.png (196×1 px, 51 KB)

^ For reference, the display of deprecated-ness in both API docs and output.

Output specifically

"warnings": {
    "mobileview": {
        "*": "This API is deprecated. See T186627 for more details."
    }
},

Having a look on the api-feature-usage dashboard, I don't actually see any usages https://logstash.wikimedia.org/goto/5dc90017447bd46902c904507540107d but I don't know if this is a false negative...

Using this as a hint..

And finding an updated URL.. https://grafana.wikimedia.org/d/000000559/api-requests-breakdown?orgId=1&refresh=5m&from=now-90d&to=now

Screenshot 2022-06-03 at 08.56.07.png (962×2 px, 359 KB)

There's a constant 2-4 req/s, with a spike around 8-9 earlier this week... I'm guessing due to increased retry requests because they started erroring as rEMFRac655c601ac3: Drop ApiMobileView rolled out with the train.

Screenshot 2022-06-03 at 08.59.53.png (972×2 px, 381 KB)

Screenshot 2022-06-03 at 08.59.42.png (968×2 px, 396 KB)

So there is a very low level, but consistent use of the API

Thanks for the ping @Reedy. We had some internal issues with the mailing list approval due to a lack of moderators (see Slack engineering channel) but that should be fixed now. The email about the removal was sent out Friday.

Regarding original deprecation: I can't see an email so it's possible that was indeed forgotten, which is annoying. I think there has been ample warning, particularly the obnoxious warnings that have been showing in responses for the last 2 months so not all is lost.

Regarding the low level of usage, there are various old versions of the app out there that we can't do much about, so some traffic is expected. @phuedx do you think the rate here is enough to warrant adding some kind of special redirect code to core / Varnish? For example, we could serve a static JSON that says it's been turned off.

I think there has been ample warning, particularly the obnoxious warnings that have been showing in responses for the last 2 months so not all is lost.

The to-be-deprecated status has also been reflected on Special:ApiSandbox (per T210808#5734042) and was also documented on the mw:Extension:MobileFrontend/MobileViewApi (per https://www.mediawiki.org/w/index.php?title=Extension:MobileFrontend/MobileViewAPI&oldid=2988404).

However, not announcing the deprecation via the standard channel was an oversight.

Regarding the low level of usage, there are various old versions of the app out there that we can't do much about, so some traffic is expected.

Looking at https://turnilo.wikimedia.org/#webrequest_sampled_128/4/N4IgbglgzgrghgGwgLzgFwgewHYgFwgBGcATgLQDGAFqWiADTjTxKoY4DKApmhtgOZR82GAgSMMAWy7IcXfCACiaCgHoAqgBUAwgxAAzCAjRcSQvAG1QaAJ4AHeQSnzGJLvoUB9T873OACqZYACbmViDBMCToWLgE/gDsACJ6UCZ2+GQAjBL2jiAI6FxpIAC+ALql9NZ5CmkkEAJ6bh4EURCeAI4wpjZ6cBTscSAUOGhwjUKMYIg9YSADQwC8kpiERlyQXADuIOWM2Jh0ePqIUFwVjFB2SGhhNQ51aA1NjMEQ0thQsQow5ySeOD8LjYOhXTAkY6gFoKKgQO5+WoEf4QYp6d5uQY/AjBYoUEHvV4gBwNTDBBRlRhISTw/BZAAM9MuIBRaMs0PcphB+Nh8KmBghknQ+Ae+Vxp1EYPAs3ylJAtkeBGkcFgbjK+2JjWwXGCSQ+IO+ODCGrsWp1HAhxxAcIRpSAA=:

  • The 3rd, 4th, 5th, and 6th most frequent UAs are older (unsupported) versions of the Wikipedia iOS app
  • The second most frequent UA is okhttp/5.0.0-alpha.2, which, IIRC, is an HTTP library used by older (unsupported) versions Android app
  • The first most frequent UA is Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 which is classified as device_family=iPhone,browser_family=Mobile Safari UI/WKWebView by the UA parser library that we use during refinement. Did the iOS app ever use WKWebView?

The to-be-deprecated status has also been reflected on Special:ApiSandbox (per T210808#5734042) and was also documented on the mw:Extension:MobileFrontend/MobileViewApi (per https://www.mediawiki.org/w/index.php?title=Extension:MobileFrontend/MobileViewAPI&oldid=2988404).

However, not announcing the deprecation via the standard channel was an oversight.

To add to the above, both the action=mobileview API and the action=parse API extension mechanism are also documented as unstable/to be deprecated on mw:Extension:MobileFrontend:

Use these APIs at your own risk. They may disappear (although we will give you sufficient notice when they do)!

This comment was removed by Mazevedo.