GraphQL/Falcor seem like a very elegant abstraction for "fetching" data. But I see a performance problem arising - all data queries are not created equal, and s

GraphQL/Falcor seem like a very elegant abstraction for "fetching" data. But I see a performance problem arising - all data queries are not created equal, and so it may turn out that there is a significant speed difference between requesting {Object: [field1]} and {Object: [field1, field2]} as a consequence of some particular implementation detail at the persistence layer (SQL joins perhaps). A well designed BFF would abstract away this problem by providing a set of individually optimized endpoints, presumably crafted in a way that reflects the underlying persistence layer (like any good REST API) as well as gathering data together for a particular client's needs, so that the front-end designer can decide which calls to make, and whether requesting [field2] is worth the cost. The alternative in a GraphQL world would be to have a set of best-practices which annotate the data model. So a backend engineer would write a piece of documentation saying : "Warning: consider avoiding [field2] for significant performance gains".