Adapters

An adapter is a context: it captures a platform's cause, normalises it into an intention, and emits the result as a native effect. This section documents each first-party adapter A to Z. Adding one is always the same move, a decorator or a blueprint, and your domain never changes.

#The shared pattern

Every adapter is enabled the same way: install the package, add its decorator to the manifest (or its blueprint imperatively), and deploy. Adapters stack, so several can coexist and the collapse to one happens at runtime.

#The catalog

#Choosing and stacking

Pick the adapter for where you deploy; stack several to keep the choice open until runtime. The pages that follow cover each one's install, decorator and blueprint, configuration keys, platform specifics and deployment.

#How the adapter is selected

When several adapters are stacked, Stone.js resolves exactly one at run time, when the app runs, not when you build or deploy. The order is:

1. the current adapter, if an adapterAlias names one (set per environment, so a platform can pin its own);
2. otherwise the adapter marked default: true;
3. otherwise the single adapter present.

So the same artifact, with Node and Lambda stacked, collapses onto Node when you run it locally and onto Lambda when it runs there, decided freshly at run time on each host.