apex-recipes is a pattern library you can install into an org and poke at

Examples that are meant to be read, and then run

The description is a library of concise, meaningful examples of code for common use cases following best practices, and the README adds the intent, that the examples reflect enterprise patterns that can be used for real world solutions and should be relevant to developers of all skill levels, with the code intended to reflect clarity while trying to maintain brevity. Those two goals pull against each other, because an enterprise pattern is usually longer than a demonstration, and the resolution is the instruction set this repository is really offering. Each example is a self-contained demonstration of one thing, in a form you can deploy and open in the developer console, rather than a chapter of a manual. The companion trail is the Quick Start: Explore the Apex Recipes Sample App project and a short presentation video, which is where a newcomer is pointed first. The project also publishes a Trailhead badge, which is the mechanism that turns a repository into a learning path rather than a reference.

The scratch org route, which is the recommended one

The installation options are three, and the first is the recommended one, installing into a scratch org, for a developer who wants to experience the app and the code. The environment setup follows the Quick Start: Lightning Web Components Trailhead project, which means enabling Dev Hub in a Trailhead Playground, installing the Salesforce CLI, installing Visual Studio Code and the Visual Studio Code Salesforce extensions. The hub org is then authorised with an alias, and the repository is cloned, and a scratch org is created from the project definition file:

sf org login web -d -a myhuborg
git clone https://github.com/trailheadapps/apex-recipes
cd apex-recipes
sf org create scratch -d -f config/project-scratch-def.json -a apex-recipes

The app is then pushed, and the permission sets are assigned to the default user, one for the app itself and one for the walkthroughs:

sf project deploy start
sf org assign permset -n Apex_Recipes
sf org assign permset -n Walkthroughs

The sample data is imported, the anonymous Apex setup script is executed, and the org is opened, after which the Apex Recipes app is selected in the App Launcher.

Sample data and the setup script, which is where the examples get content

The last steps of the scratch org route are the ones that make the examples meaningful. Sample data is imported with two data tree plans, one after the other, and then an anonymous Apex setup script is executed:

sf data tree import -p ./data/data-plan.json
sf data tree import -p ./data/data-plan2.json
sf apex run --file data/setup.apex
sf org open

Two data plans rather than one suggests the data is split by concern, and the setup script is the piece that has to run in Apex because some of the records, junction objects and the like, cannot be inserted by the data import. In the unlocked package route the same idea appears in the developer console, where the Open Execute Anonymous Window is used to run DataFactoryForPackageInstalls.generateData();, a call that exists precisely because the package installer cannot create the data that the examples assume. That is a good detail to notice, because it tells you the examples are interconnected rather than independent, and a developer who deploys the code without the data will see empty screens rather than errors.

The unlocked package route, and the platform feature it needs

The second option installs the app as an unlocked package, which allows anybody to experience the sample app without installing a local development environment, and it is the route for a more permanent environment than a scratch org or for a free Developer Edition Org or a Trailhead Playground. The instruction is to start from a brand-new environment to avoid conflicts with previous work. Then there is a platform feature to request first, because the app uses platform cache, and the steps are to log in, go to Setup, under Platform Cache, and click the Request Trial Capacity button. The package itself is then installed through a packaging link, and the choice Install for All Users is selected. After that the optional data can be added, using the sample CSV files in the data folder, which can be used by dataloader.io or the Import Data Wizard, and the Apex Recipes permission set is assigned to the user through Setup, Users, Permission Sets, Manage Assignments.

The developer edition and playground route, for badges and permanent orgs

The third option is the Developer Edition Org or a Trailhead Playground via the Salesforce CLI, and the README says it is useful when tackling Trailhead Badges or if you want the app deployed to a more permanent environment than a scratch org. The sequence is the same shape as the scratch org route, with the difference that the authorisation uses the -s flag and a different alias, because the org is a persistent one rather than a hub:

git clone https://github.com/trailheadapps/apex-recipes
cd apex-recipes
sf org login web -s -a mydevorg

The Developer Edition path repeats the platform cache trial capacity request under Setup, Platform Cache. The three routes together cover the three audiences the project has, a developer who wants to try the code, somebody who wants a permanent org to click around in, and a person working through Trailhead badges who needs the app deployed where it persists.

The tooling around the samples is part of the sample

The repository carries a full development setup, and it says something about how the examples are meant to be written. Formatting is prettier over a file glob that includes .cls, .cmp, .component, .page, .trigger and the metadata files, with an apex-specific parser plugin, and there are local variants that run the apex parser as a standalone process against a host on 127.0.0.1, which is how a formatter for a language that is not JavaScript gets integrated. Linting is eslint, and the unit tests run through sfdx-lwc-jest with watch, debug and coverage modes, and there is a jest-sa11y-setup.js, which is the accessibility testing setup, so the Lightning Web Components in the samples are checked for accessibility rather than only for behaviour. The Apex documentation is generated by a shell script, bin/generate-apex-docs.sh, and the precommit hook runs that script, stages the generated documentation, and runs lint-staged, with husky installed in prepare. There is also a code-analyzer.yml, which is the configuration for Salesforce's own static analysis, and a .forceignore for what is not deployed.

What this is for, and what it is not

The honest framing is that this is a sample application rather than a library, and the distinction matters for how you use it. You clone it, deploy it, click through it, and then read the code that produced the screen you are looking at, which is a much better way to learn a platform language than reading about it. What it is not is a framework, because there is nothing to depend on, the npm package is marked private under the name @salesforce/apex-recipes with a version of 1.0.0. The second limit is the platform itself, since the examples need a Salesforce org, and for several of them a platform feature that has to be enabled first, which is the platform cache trial capacity request in two of the three routes. The third is the audience, since the code is written to be read by developers of all skill levels, which means an experienced Apex developer will find the patterns recognisable but the packaging, the permission sets and the walkthroughs more interesting than the code itself. The licence is CC0, which is the dedication to the public domain and the right choice for material you want a company to copy into its own codebase without attribution obligations.

Editorial conclusion

apex-recipes is worth cloning if you are learning Apex or working on the platform without a body of production code to read, because the examples are deliberately short, they are deployed rather than described, and the sample data and permission sets mean you can run the thing instead of reading about it. It is the wrong tool if you want a framework, since this is a sample app and not a library, and it is the wrong choice if you only need one pattern, since the repository is large and the pieces are not packaged for selective use. Before you start, read the installation options and pick the one that matches whether you want a disposable environment, and check the platform feature requirements, since the unlocked package route asks for platform cache trial capacity.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. Project website
4. README
5. trailheadapps/apex-recipes on GitHub