Talk:Requests for comment/Business Layer Architecture on budget

Comments from anomie

Unfortunately there's a good chance I won't be able to participate in the RFC meeting this evening. My concerns with this proposal include:

• I question the assumption "Making SQL queries everywhere is bad." An SQL table is already a structured, indexed, searchable data store, and building thin ORM on top of it because "SQL is bad!" seems like needless additional abstraction to me. What's bad is when further development means SQL isn't abstract enough anymore and people hack around it instead of implementing an abstraction on top of SQL + whatever other layer is necessary.
  • Security, data consistency, backward compatibility - all that comes with an abstraction on top of SQL.

• I'm not too fond of the idea of having to create the API object structure in cases where it would be more straightforward to have a real "business class" / "model" or "controller" / whatever-you-want-to-call-it that both the API and the web UI would call. It seems like another needless layer of abstraction.
  • API object structure for parameters? There is no need of per-api-module object structure (unless we pursue a per-module parameter objects, which might be good for some cases, but not required)

• That said, for input it would mostly work to pass objects instead of strings for known data types. But we'd probably have to add some sort of mechanism for extensions to register new "known data types", or else e.g. Flow would still be stuck marshalling and unmarshalling its UUIDs.
  • Agreed.

• For output the situation is more complicated, since ApiResult is structured around holding a PHP data structure that could effectively be passed to json_encode(), serialize(), or the like. While this could be changed, it would probably be a lot of work: witness the amount of work that was required for the recent much less fundamental change to ApiResult.
  • It would then violate the assumption that "UI rendering PHP code should have access to the same capabilities as JavaScript" since JS would be receiving these strings rather than objects.
  • It's also reasonably likely that we'd either wind up with some calls returning strings and others returning objects based on the internal implementation, or else we'd have code creating objects that exist mainly to be re-stringified later.
  • It would greatly complicate the API result size limiting, unless we stringify every object twice.
• The "Special Permissions" section is also violating the assumption that "UI rendering PHP code should have access to the same capabilities as JavaScript" by granting it additional capabilities.
• The suggestion to not enforce limits opens things up for the developers we supposedly can't trust to make sane SQL queries to instead make deceptively simple API calls that result in excessive database and memory loads.

Anomie (talk) 14:11, 22 April 2015 (UTC)

Assumptions -> goals

I took a stab at rewriting the assumptions part as goals, please see if it makes sense (and feel free to change anything that doesn't). --Smalyshev (WMF) (talk) 19:38, 23 April 2015 (UTC)