| dbarratt added a comment. |
In T173214#4517644, @Tpt wrote:@dbarratt Thank you for planning to work on Wikibase+GraphQL.
The performance problem we face seems very standard, I believe it is the N+1 problem.
The standard way to solve it is to use the DataLoader utility. The original Facebook implementation is here: https://github.com/facebook/dataloader but our PHP GraphQL library also provides an equivalent: https://webonyx.github.io/graphql-php/data-fetching/#solving-n1-problemBut indeed rewriting to JS is a good option if we do not plan to integrate the GraphQL server inside of MediaWiki. If not, the PHP library we use actually allows to use promises and does collection for us: https://webonyx.github.io/graphql-php/data-fetching/#async-php
If you start working significantly on the GraphQL endpoint we should probably move it out of tptools to a separated shared project.
Well that's fascinating, I'm glad the library provides a way to do that. That's something to keep in mind.
I've thought about this for a while and what the final product would look like.
It looks like we have three options:
- MediaWiki extension that would hook into Wikibase (like Special:EntityData).
- External Service connected to Wikibase (like SPARQL).
- Centralized service connected to Wikimedia
I was thinking about T173214#4511629 and the idea of querying other wikis and I wondered why you wouldn't be able to query other wikis (REST API, Action API, etc.) on a single GraphQL server from the top level or deeply nested. I was also thinking about #structured-data-commons, would we setup a new instance or would you able to query both from a single instance? Indeed, it seems that the more APIs you could query from a single endpoint, the better. With that, I think option 3, is the best option for the concept of being able to leverage all of the data that Wikimedia has to offer in an easily consumable fashion.
This will shift some things, for instance in the top level, you'd need some way to specify the wiki you want to query first (perhaps the code and the lang as an argument?). But it also let's us do some interesting things, like getting wikidata entities from wikipedia article titles and then returning data about those entities and then data from other linked wikis (on a single request).
With that.. I think it would be best if we moved your code to a new "graphql" repo, host the GraphQL server on a Cloud VPS, and then rewrite it in _javascript_ (node.js) so it's as fast as it can be. If it gets enough usage we can talk about moving it onto production. :) What do you think? does that sound like a plan?
Cc: Smalyshev, Lydia_Pintscher, Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, He7d3r, Jdforrester-WMF, Mbch331, Jay8g, Tgr
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
