| Addshore added a comment. |
There sure has been a fair amount of discussion on this ticket!
So I have created an updated interacting diagram showing off a few more details of the overall flow (and updated the description)
F27687680: Wikidata Termbox SSR Sequence-SSR.png
This highlights the various levels of caching.
- Calls for entity data will be going via varnish, and Special:EntityData is cacheable
- Other calls to the mw / wb api will not be varnish cached but will be cached and reused by the service itself, probably be a TTL of 1 minute.
Load Details (now included in the description)
The initial responsibility of this service will be the rendering of the term box for wikidata items and properties for mobile web views.
Currently wikidata.org gets no more that 80k mobile web requests per day (including cached pages, and non item/property pages).
If we were to assume all of these requests were actually to item and property pages that were not cached this would result in this SSR service being hit 55 times per minute.
(In reality some of these page views are not to item or property pages, and some will be cached) so we are looking at no more than 1 call per second.
Replies to specific points, with notes from @Jakob_WMDE & @Pablo-WMDE
In T212189#4833536, @daniel wrote:Oh, I got that wrong - I thought the service would be public facing and called directly from the client! But apparently, itt's not, it would be hidden behind api.php. So, my first point, "we would not expose a new endpoint we would not expose a new endpoint", is invalid. Instead, it should read "We should not introduce a service that is called by MediaWiki, and itself calls MediaWiki."
The initial deployment will not even have a proxy to the service via api.php, it will be entirely internal.
No part of the SSR service is public facing.
In T212189#4835359, @Milimetric wrote:As I understand it, in the proposed architecture, mediawiki sits in between the browser and node to prevent exposing another public endpoint for the node service. Is my understanding correct?
Yes.
Now, I started looking through the code and it looks like there's an effort to keep server and client logic as common as possible, with factories and interfaces and nice patterns, but there are still differences. It looks like there's good reason for this, but how would the client be able to act as a fallback for the server as proposed?
This is an exceptional case and only works for user with JS enabled.
"Client" here would be the client-side JS, served by Wikibase.
In case there is no response from the SSR, the fallback would be CSR-only, i.e. it will only work for people with js enabled.
This addresses the rare scenario that there is no working SSR configured (in installations run by 3rd parties now WMF) and still offers termbox features, but at the cost of not being accessible to users with JS disabled.
In T212189#4837833, @mobrovac wrote:If index.php has all the data to render it, then that means that it can send it to the service directly without the need for the service to call MW back (now, whether the client will be used as a proxy is a different issue).
The "termbox" is more of an application than a template.
Only it knows which data it needs - actively "sending" data to it requires knowledge of which information is needed.
While seemingly trivial in the beginning this will, as the application grows, become a burden in maintenance - and potentially in performance if data data that has become obsolete is sent "just to be sure".
In T212189#4837867, @daniel wrote:(Actually, this is an assumption, it may not be true. Currently, we do render the personalized term box on the server for logged in users, and merge it into the output by substituting a placeholder; I assume that the plan is to not do that, and drop support for a personalized term box for people without JS. But I did not confirm this assumption)
Personalized = user language on top, then "languages most likely to be spoken" by user. We still strive for this behavior.
Cacheability will have to be taken into account.
Cc: akosiaris, Krinkle, Milimetric, daniel, mobrovac, Joe, Matthias_Geisler_WMDE, Jakob_WMDE, Pablo-WMDE, Aklapper, Lydia_Pintscher, Lea_WMDE, Addshore, WMDE-leszek, Legado_Shulgin, Nandana, thifranc, AndyTan, kostajh, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, _jensen, D3r1ck01, SBisson, Wong128hk, Eevans, Hardikj, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, faidon, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, fgiunchedi, Legoktm
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
