| Milimetric added a comment. |
Thanks @Jakob_WMDE, I think we're saying the same thing in slightly different terms, and it's because I'm not being precise. It's ok for the client and server to have different implementations, but you're saying the have the same capabilities, right? I was thinking that for the client to be able to render everything the server does, plus handle interactivity and other features in the future, its capabilities would have to be a superset of the server capabilities, right? So, there's no html that could only be rendered by the server, right? It seems that way, components and interface are all shared.
If so, great. If not, it feels important to understand what happens when the server's not there and the client doesn't have some of the server-specific functionality.
So then for me the main question remains around the request flow that everyone else is discussing. From @Addshore's response it sounds like you considered this option and decided against it:
- 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.
If this was rejected, I'm just curious, what were the expected problems? One potential optimization with that approach could be, if SSR is enabled, you send a smaller client-side module that doesn't include data-access which would only ever happen once, on page-load. So you could put that in a client-fallback folder or something, include it in the version served by index.php but exclude it from the version served by SSR.
(by the way, the build is nicely separated for client vs. server here https://github.com/wmde/wikibase-termbox/blob/faf3dcca602da9f2287e8be9acaa1023144b23d7/vue.config.js#L14, where webpack analyzes the code and includes only what's required by the particular environment it's building against)
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
