arc sandbox
Start a local development server that emulates AWS infrastructure for your Architect application. Sandbox provides a complete local development environment that includes:
- HTTP server for your
@httproutes - WebSocket server for
@wsroutes - Dynalite in-memory database for
@tablesand@tables-indexes - Local event bus for
@eventsand@queues - Static asset serving for
@staticassets - File watching and live reloading
Additionally,
@scheduledand@tables-streamsLambdas can be emulated via the @architect/plugin-lambda-invoker plugin
Usage
arc sandbox [flags]
Flags
-p,--port: Port the HTTP server will listen on (default is3333)-h,--host: Host the server will bind to (default is0.0.0.0)--disable-symlinks: Do not use symbolic links for shared code; use file copying instead (slower)--disable-delete-vendor: Do not deletenode_modulesorvendordirectories upon startup-q,--quiet: Minimize console output during operation-v,--verbose: Print more detailed output during operation-d,--debug: Print even more detailed information for debugging
Environment Variables
The following variables can be set on the command line when running arc sandbox:
ARC_HTTP_PORT,PORT- Set the HTTP server port (same as--port)ARC_EVENTS_PORT- Set the events/queues service port (default4444)ARC_TABLES_PORT- Set the DynamoDB emulator port (default5555)ARC_HOST- Set the host the server will bind toARC_QUIET,QUIET- Minimize console output (same as--quiet)ARC_ENV-testing|staging|production- Defaults to
testing
- Defaults to
ARC_LOCAL- If present and used in conjunction withARC_ENV=staging|production, emulates livestagingorproductionenvironment- Uses your local preferences
@envenvironment variables for the appropriate stage - Connects Sandbox to live AWS events and DynamoDB infrastructure
- Requires valid AWS credentials with the same profile name as defined in your project manifest
- Uses your local preferences
ARC_INTERNAL_PORT- Manually specify internal Sandbox + AWS services port- Defaults to
2222
- Defaults to
ARC_DB_EXTERNAL- (Boolean) Use an external DynamoDB tool (such as AWS NoSQL Workbench)
Example
Run Sandbox in quiet mode on a different port:
ARC_QUIET=1 PORT=8888 npx arc sandbox
Keyboard Shortcuts
Sandbox registers keyboard shortcuts to help with local development (note: they are all capital letters!):
S- Hydrate onlysrc/sharedV- Hydrate onlysrc/viewsH- Hydrate bothsrc/sharedandsrc/viewsCtrl+C- Gracefully shut down the sandbox
Local preferences
Several Architect local preferences can be leveraged to change how Sandbox works while developing locally.
Sandbox preferences
Check out the @sandbox preferences reference for more information.
⚠️ These preferences should be used with care as they can allow your local development sandbox to use live deployed infrastructure and data.
@sandbox
livereload true
env production
useAws true
no-hydrate true
Sandbox startup scripts
Sandbox can run shell commands on startup by setting @sandbox-start in local preferences like so:
@sandbox-start
node scripts/seed_db.js
echo 'hello'
@create
Upon starting, Sandbox can automatically scaffold resources (via init) found in the application’s manifest that do not yet exist. Options are set with @create in local preferences.
@create
autocreate true
templates
http path/to/template/http.js
events path/to/template/events.py
@env
Architect Sandbox will load variables for Sandbox’s current environment (testing, staging, or production) from a local preferences file with @env. If a project contains a .env file, Architect will load those variables instead, and only for the testing environment.
Variables from local preference files and .env will not be merged. Further details, including the variable load-strategy are outlined below.
Environment variables
Sandbox automatically loads environment variables for availability at runtime (process.env.MY_VAR in Node.js). Environment variables can be set in a few locations. It’s important to understand how each source is prioritized when developing locally.
Load strategy
Sandbox will prioritize…
- A project’s
.envfile (if it exists), - then project-level Architect preferences,
- and finally global Architect preferences.
Variables across these sources are not merged.
Using a local preferences file with @env offers the most flexibility since variables can be specified per environment: testing, staging, and production.
Example scenario
If .env is found, Sandbox will only use the variables for the testing environment, and not load any variables from any Arc preferences files. Given the following case with 3 environment variable sources:
# ./.env
URL="https://arc.codes"
# ./prefs.arc
@env
testing
URL www.architect.fake
# ~/.preferences.arc
@env
testing
URL ftp://arc.ftp
ADMIN_PASS zero cool
The following is true in a Node.js function run with Sandbox:
process.env.URL === 'https://arc.codes' // true
process.env.ADMIN_PASS // undefined
Local database
Sandbox creates an in-memory instance of dynalite with @tables and @tables-indexes found in the app.arc file. @tables-streams is not currently supported by dynalite.
When Sandbox is terminated, any data written is cleared from memory.
You can set a custom port by using an environment variable: ARC_TABLES_PORT=5555.
Database seed data
You can automatically seed data to Sandbox upon startup by adding a sandbox-seed.js or sandbox-seed.json file to the root of your project. (You can also specify a custom path with the seed-data preference.)
Your seed data should be an object whose properties correspond to @tables names, and have arrays of rows to seed. For example:
@tables
things
id *String
sort **String
// sandbox-seed.js
module.exports = {
things: [
{
id: 'foo',
sort: 'bar',
arbitrary: 'data',
},
{
id: 'fiz',
sort: 'buz',
arbitrary: 'info',
}
]
}
The above example would add the two rows above to the things database each time Sandbox is started.
Note: This feature is only enabled if the environment is
testing, so as to prevent the accidental (over)writing of data to a live database.
Live database example
Connect Sandbox to the DynamoDB staging database on AWS:
ARC_ENV=staging ARC_LOCAL=1 npx arc sandbox