Architect JavaScript SDK

Example usage

Prereqs

• Ensure you have node v20 or newer
• npm install

Environment Setup

• Create your API key. Guidelines: Creating an API key.
• Create a copy of .env.example at .env with keys filled in

Usage

See examples in ./examples or in the API docs at https://docs.architect.co/architect-api-and-sdk-guide.

Running examples

[!WARNING] The provided examples and tests depend on creating your own API keys and environment. If you are exploring the examples or tests, be careful to not make any actions you want to avoid seeing done in a live environment.

• Run node --env-file .env.demo ./examples/<example-name>.mjs

Contributing

Key Tools

• node.js LTS release. In practice, we will probably support LTS-1, but develop with and track LTS
• npm
• TypeScript. Some modules use jsdoc comments for the convenience of using node directly, though src is written in TypeScript
• graphql-codegen is our core library for generating the SDK
• biome: one of our exploration tokens in this project—biome is way faster than Prettier, eslint v9 migration is non-ideal. This isn’t critical either way so we can explore.
• @grpc/grpc-js is for interacting with our grpc APIs. We don’t use protobufs, so we have our own simplistic codegen format

Guidelines

• We bias towards TypeScript’s jsdoc approach where we can, to enable a native developer workflow without extra build or compilation tooling while maintaining the high quality feedback loop of TypeScript. The SDK uses TS enums which don’t have jsdoc interop so that is fully TypeScript.
• Ensure your contributions are valid TypeScript and formatted.
• Double-check the ROADMAP and consider proposing a non-trivial change before submitting a patch.
• Ensure some level of unit and type-level tests (both success and error cases).
• Avoid breaking changes. Additive changes are fine. Breaking changes create a maintenance tax. We want to ensure a seamless upgrade process for consumers to support adoption.