How to minimize fields queried per Selector methods (and speed up queries)?

[rsoesemann]

Selector classes centralize the decision which fields your query and this is a good thing BUT it also leads to the situation where over time each selector defines dozens/hundreds of fields and most queries only need a small subset. But all fields are always queried.
I realized that a query (or the deserializing into SObjects after that) takes MUCH longer the more fields are in the query (can someone confirm that?)

So is there a way to keep the Selectors and still minimize the number of fields queried per-method?

[ImJohnMDaniel]

So, I believe the common misconception is that the Selector Pattern is suppose to list “all fields possible”. That would be incorrect.

The Selector Pattern should list “the minimal fields that would be needed by every application in the org”. This ensures the records that are queried have what they need to operate correctly. This is essentially the “Selector’s contract to the org”. (think ‘service contract’ but focused on what fields are guaranteed to be populated).

For certain, be judicious in which fields you add to the base list. Avoid adding fields that are Long Text Area or Rich Text as they take up a huge amount of memory compared to other fields. Definitely look to add common parent fields (Lookup or Master-Details) and key external id fields.

Each selector method is free to add more fields to the base set of fields and this is encouraged. This is fundamentally what occurs in the AT4DX Selector Field Injection pattern because in an org with multiple packages, new packages could add more fields/methods to the SObject’s base selector which exists in an upstream package.

Ultimately, this falls to the org/app governance bodies to enforce.

Does this make sense @rsoesemann? Let me know if you have more questions.