[Wikidata-bugs] [Maniphest] [Commented On] T109836: Try replacing Wikibase usages with API usages
JanZerebecki added a comment. make business logic that does not know or care about UI or web API Where should this code live and how can one declare a dependency on it?TASK DETAILhttps://phabricator.wikimedia.org/T109836EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JanZerebeckiCc: RobLa-WMF, Anomie, Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Winter, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, bd808, Tgr___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T109836: Try replacing Wikibase usages with API usages
RobLa-WMF added a comment. In T109836#2433074, @daniel wrote: We can have this as an ArchCom session, but there was quite a strong consensus when we discussed this in Lyon The problem that @Jdlrobson correctly identified is that the discussion wasn't captured in a way that we can clearly refer back to it. An RFC is a great tool for that. An ArchCom session is merely a tool to help create a well-written RFC. [Consensus in Lyon]: don't use the Web API interface and FauxRequests for internal requests. Reasons: It's a "stringly typed" interface, it lacks type safety the encoding/decoding is a performance issue. it makes things very hard to test - it's an antithesis to the idea of injecting narrow, easy-to-mock interfaces. Best practice IMHO: make business logic that does not know or care about UI or web API, write a thin layer of UI or API on top of it. Would someone be willing to file that an #ArchCom-RFC?TASK DETAILhttps://phabricator.wikimedia.org/T109836EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: RobLa-WMFCc: RobLa-WMF, Anomie, Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Winter, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, bd808, Tgr___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T109836: Try replacing Wikibase usages with API usages
daniel added a comment. We can have this as an ArchCom session, but there was quite a strong consensus when we discussed this in Lyon: don't use the Web API interface and FauxRequests for internal requests. Reasons: It's a "stringly typed" interface, it lacks type safety the encoding/decoding is a performance issue. it makes things very hard to test - it's an antithesis to the idea of injecting narrow, easy-to-mock interfaces. Best practice IMHO: make business logic that does not know or care about UI or web API, write a thin layer of UI or API on top of it.TASK DETAILhttps://phabricator.wikimedia.org/T109836EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: RobLa-WMF, Anomie, Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Winter, D3r1ck01, Izno, Wikidata-bugs, Mbch331, Jay8g, bd808, Tgr___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T109836: try replacing Wikibase usages with API usages
JanZerebecki added a comment. My intent is in this task to only try if we can get by with only the existing HTTP API functionality. If we find that some of the Wikibase uses can be replaced and some can't be replaced with what the current HTTP API supports then we replace the ones that makes sense and note what is missing and this task is done. TASK DETAIL https://phabricator.wikimedia.org/T109836 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki Cc: Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Wikidata-bugs, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T109836: try replacing Wikibase usages with API usages
JeroenDeDauw added a comment. Nobody talked about introducing a new API module. And I did not say you did. I'm bringing up a concern I have about something not explicitly talked about yet. Without doing that it'd rather hard to tell what the intent is, or how people will interpret it. TASK DETAIL https://phabricator.wikimedia.org/T109836 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Wikidata-bugs, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T109836: try replacing Wikibase usages with API usages
JanZerebecki added a comment. In https://phabricator.wikimedia.org/T109836#1561975, @JeroenDeDauw wrote: While there might be places where this is a good pragmatic solution, doing this everywhere would not be wise. I don't understand. Do you have examples where it would not be wise? Why would it not be wise? Don't forget about dependency injection. Yes, please. And carefully consider if there is no simpler approach before introducing a new API module meant for internal requests. Nobody talked about introducing a new API module. TASK DETAIL https://phabricator.wikimedia.org/T109836 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki Cc: Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Wikidata-bugs, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T109836: try replacing Wikibase usages with API usages
JeroenDeDauw added a comment. While there might be places where this is a good pragmatic solution, doing this everywhere would not be wise. Don't forget about dependency injection. And carefully consider if there is no simpler approach before introducing a new API module meant for internal requests. TASK DETAIL https://phabricator.wikimedia.org/T109836 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: Jdlrobson, hoo, Aklapper, JanZerebecki, Lydia_Pintscher, aude, daniel, Legoktm, JeroenDeDauw, Ricordisamoa, Wikidata-bugs, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
