Why I Created This Site and Apex Eloquent

title: "Why I Created This Site and Apex Eloquent"

date: "2025-07-02"

author: "Hiroyuki Matsuoka"

tags: ["ApexEloquent", "Salesforce", "Story", "Testing"]

🏠 Why I Created This Site

Hello! Thank you for finding this blog.

Here, I plan to casually write about "Apex Eloquent," a query library for Salesforce Apex, stories about its development, and some tips along the way.

Since this is the first post, I thought I'd talk about why I created this site and why I built Apex Eloquent in the first place.

😵 "Wait, why is writing tests so difficult?"

When I first encountered Salesforce development, I had a light impression like:

"Hmm, so Apex lets you do database operations in code... that's convenient!"

However, as I actually got involved in projects and started developing, reality gradually became clear.

The Salesforce environment I was working on had already been in use for 3 years since implementation, with many custom objects, complex relationships, and making even small changes required preparing tons of test data for related objects.

"To test this process, I need to follow that relationship, put data in its parent, and... wait, how do I create this data again?"

This became a daily occurrence.

As a result, there were massive amounts of code sections without proper test coverage.

Honestly, I often wanted to run away because writing tests was just too painful.

🔧 Why I Started Building a Framework

In such an environment, I increasingly felt: "I wish writing tests could be easier..."

Actually, I had experience developing with Laravel in my previous job, and the Eloquent ORM I used there was incredibly user-friendly.

I thought, "I wish I could write queries like that in Salesforce too," which was the initial trigger for creating Apex Eloquent.

I started with a library for dynamically building SOQL queries.

But that alone didn't solve the difficulty of testing.

So the next thing I tackled was establishing a testing strategy based on mocks.

While Salesforce officially recommends "creating test data with TestDataFactory," the situation was already beyond what could be handled with factories. So I explored how to write tests in a more realistic and easier way, and eventually arrived at a design pattern called the Query Delegation Pattern.

Along with that, I built a system that could smartly handle queries, mocks, and even relationships, resulting in a framework that makes writing tests much easier.

Along the way, I hit Salesforce-specific walls like "how to handle non-writable fields," but I managed to overcome them by developing Evaluator and MockEvaluator.

🌐 And Why I Created This Site

Using Apex Eloquent made development easier and my testing strategy became much more organized.

However, looking around, I noticed that the community around Apex mocking strategies wasn't very active. I thought that by widely promoting Apex Eloquent, which incorporates elements of Laravel's Eloquent and solutions for non-writable fields, we could energize the community and improve the development environment for Apex engineers.

That's why I created this site.

🎯 Conclusion

So in this blog, I plan to share not just feature introductions of Apex Eloquent, but also how I actually use it in development, design considerations, and some small tips about Salesforce development.

For those thinking, "I wish Salesforce Apex development could be more enjoyable," I hope this can be of some help!

🙏 Acknowledgments

I would like to take this opportunity to express my gratitude to Mr. James Simone and his excellent work The Joy of Apex. ApexEloquent received much inspiration from his insights on Apex development patterns, testing strategies, and clean architecture principles. His contributions to the Salesforce developer community have been invaluable, and I'm honored to build upon the foundation he helped establish.

See you in the next article! 👋