Everything is optional

Given the wildly different use cases for Sapling, as many of its features as possible should be optional.

Purpose

The multitudes of different database technologies, templating languages, email transport, and others that Sapling supports mean that the core project cannot effectively focus on the development and testing of all of it. It also makes the user download a bunch of dependencies, which they might not need. Splitting features into separate dependencies helps both goals.

Given the priority of minimal boilerplate, it's also imperative that the user is able to run Sapling with minimal configuration, or even no config file whatsoever.

Sapling should therefore be resilient enough to always work, regardless of what modules are disabled, misconfigured, unconfigured, or uninstalled.

In practice

Sapling should be capable of running without errors with almost all of its features disabled - even core ones. For instance, if you want to use Sapling to solely build an API to drive a separately developed client application, it would make sense to turn off all routing and templating.

There are two major areas where Sapling depends on a "headline" external dependency; databases and templating. Sapling has chosen to use MongoDB and Nunjucks respectively as the default "recommended" approaches. However, to avoid locking the user in to these technologies, the storage and templating functionalities have been abstracted into "drivers", allowing the user to swap out to other technologies fairly easily (or even write their own driver).

Any feature that requires its own specific major dependency (i.e. MongoDB, Nunjucks, AWS SDK, Stripe, etc) should be extracted into a separate package. The CLI should be updated to be able to offer installing and configuring the package. This way the core Sapling framework isn't littered with tons of specialised dependencies that most won't use, while still offering the user a quick way to turn these features on or off.