| WMDE-leszek added a comment. |
the request to index.php is conditionally routed directly to the SSR service. In our world, the SSR service is there, so we configure it in Varnish, it returns html, and Vue takes over client-side. For other mediawiki installations, index.php knows to render a basic version of the html which pulls in the Vue.js modules. Once this loads in the browser, it renders the interface.
@Milimetric I am not sure if I get the suggestion right, but it sounds like almost what we are proposing, with the only difference that it would include some server side rendering of the Wikidata parts of page in PHP ("rendering a basic version of HTML").
We've decided to not do this because one of our goals is to have the single implementation of the rendering logic. That's why the rendering code is in JS/node. Having a second implementation of rendering in PHP, including rendering vue templates in PHP etc, is the solution we didn't want to lock ourselves in, as it basically asking for trouble (forgetting to update a second place when updating the other one is bound to happen at some point, for example).
Or maybe you meant, that without the SSR in place, the server will only render some kind of placeholder, and once vue js is loaded on the client, the UI will be rendered. This would mean a less pleasant user experience (UI "appearing" later), but would still provide the full experience to the user, as long they have JS enabled in their browsers. If this is your suggestion, I am happy to confirm that this is the approach we're planning here.I believe answers from WMDE staff above have already been touching on this topic, but to explicitly mention them, let me try to answer it:
"We should not introduce a service that is called by MediaWiki, and itself calls MediaWiki."
The intention of introducing the service is not to have a service that call Mediawiki. As discussed above, it is needed for the service to ask for some data, and this data shall be provided by some API. Currently, the only API that can provide data about Wikidata items etc is indeed wrapped in MediaWiki. Should there be another, more light-weight API providing access to the same data, the service would most likely be using it.
The implementation, as can be seen by looking at the linked source code, is not bound to those APIs it talks to be MW-ones at all.
If between lines people are here suggesting to have some lighter API to access Wikidata data, I can only second those ideas. Introducing such API(s) seemed to be too much of an endeavour to do together with introducing new front-end solution. We preferred to take one step at a time.
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
