FFLib Selector Issues

[pgajek2]

Hello devs!

I would like to discuss FFLib Selectors. We all strive to find the best possible solutions to keep our code clean. I learned about the Selectors concept a few years ago and instantly fell in love with it. One of the most widely used implementations of selectors is FFLib Selectors. I have utilized them and encountered a few issues:

1. Wrong assumptions - FFLib Selector assumes that queries across the project are similar, so they should be kept in the Selector class for reuse. The problem is that most queries on the project are unique and have complex conditions (WHERE). Even if the conditions are the same, additional SOQL clauses ( LIMIT, ORDER BY, OFFSET) may be required. This means that queries are difficult to reuse.
2. God Class - A Selector class can become huge and hard to read. Selectors for "popular" objects like Account, Contact, or Opportunity can have hundreds of lines of code.
   This can be a problem, especially on projects with a lot of developers, as it leads to constant overwriting and merge conflicts.
3. Naming convention - It's really difficult to come up with a proper method name when query conditions are complex. Mimicking all conditions in the method name also doesn't seem like a clean solution.
4. Inline Database.query - FFLib Selector has no logic that allows control over sharing rules.
   Of course, you can have inherited sharing, but it will not cover cases where you need with sharing for most of the queries, but without sharing for some.
5. Inline binding - FFLib Selector does not use the newest feature Database.queryWithBinds.
6. Entry threshold - The FFLib Selector is relatively complicated. The documentation does not contain examples and use cases. Will a junior developer be able to understand and use it on the project?
7. Lack of newest features - The FFLib community is huge, however, implementation of a new feature in such complex code will be difficult. Salesforce has released a few cool features that can be used in Selectors:
   • Use the Iterable Interface with Set Type
   • Database.queryWithBinds

Building upon that, I developed SOQL Lib, aiming to address these challenges. Please note that I'm not intending this to be promotional. I wish to share my insights, as continuous improvement is essential. Considering contemporary Salesforce features such as Database.queryWithBinds the FFLib Selector doesn't seem like the most suitable option to do queries.

What do you think?

More about it in:

• FFLib Selector Issues
• SOQL Lib GitHub
• SOQL Lib Documentation

[daveespo]

Hi Piotr,

Thanks for the post. A rather detailed reply could go on for pages so I'll try to keep it brief 😛

My favorite professor in college used to have a particular mannerism when he was presenting a topic when he said "it depends". It stuck with me because throughout life and my software development career because so many things don't have a black and white correct answer. It's always "it depends".

Regarding 1 & 2 & 3: For small to moderately large projects, the "shape" (fields) of your objects and the definition of what makes up the collection (where clause, limit) should be well defined and reusable. Otherwise you're no better off using a Selector than just inlining SOQL all over you code base to address your specific use case at the time .. and then live to regret it when the next developer arrives and writes their own method that almost exactly repeats your work. For large projects, you're right that it becomes harder to define a naming convention that encompass many different business domains. But that's not really an Apex and Selector problem, that's a development team and architecture problem. The https://github.com/apex-enterprise-patterns/at4dx provides tooling to address this using dependency injection. It's an elaborate solution but once you've reached that type of problem, you can likely justify the investment. AT4DX really deals the the God class problem. There's a more elaborate explanation over on #432

Regarding 4 & 6: You're slightly out of date in the materials you're linking to. The link to SObjectSelector is the 10 year old version of that class. Within the past year, we implemented User Mode to specifically address (and dissuade) the use of sharing declarations at the class level. See this topic #419 for more. Additionally, there is a Trailhead module for the Enterprise Patterns as well as Andy's book which was republished earlier this year to reflect some of the aforementioned changes.

Regarding 5 & 7: Let's be fair here. Those features were just introduced in the last seasonal release (Spring '23) -- the maintainers on this project are volunteers and make contributions in their free time. There are several proposals on the table for introducing a Criteria builder (#292 #393, #313 and #458 ) which have relative strengths and weaknesses (some cover every use case at the expense of it being a lot of complexity; others address the common use cases well). All of those were proposed prior to queryWithBind() was made available but it's in our plan to ensure that if and when we integrate a where-clause-builder, it will support bind variables. Updating any library with a large installed user base is a very delicate balance between retaining backwards compatibility while also not remaining stagnant. There are many things we would do differently today if given a blank slate.

Lastly, I'll point out that AEP is more than just a Selector class. It addresses Domains, Services, Unit Of Work, Mocking and if you use force-di and at4dx, offers advanced dependency injection.

I took a quick skim of your Selector Issues doc and am not entirely sure where you got this code: https://beyondthecloud.dev/blog/soql-lib#entry-threshold -- this is not a usage pattern that's documented anywhere that I'm aware of. Under no circumstances should you be concatenating together your own SOQL.

I admire the hard work you put into your SOQL library and wish you continued success in using it.

-Dave