When building any kind of application, it’s important to have a space that can be used for development, testing, and debugging that is separate from your end users. This should be a space where you’re free to build and test new features, store sample data, and (inevitably) make mistakes and break things, without having any negative impact on real users. In Squid, we call this our dev (development) environment.

It’s equally important, however, to have a space that is stable and reliable for users, where you deploy your developed features and store real user data. This is our prod (production) environment.

When creating an application in Squid, you’re provided with both a dev environment and a prod environment out of the box.

Note: You can switch between environments in the Squid Cloud Console using the environment selector in the application header.

What’s the difference?

Once you’ve created your application, the two environments are kept pretty much entirely separate. Each environment has its own integrations, secrets and logs. This includes the built-in integrations, meaning dev and prod have separate built-in databases, queues and storage. They also have separate Squid API keys, and when deploying your backend, you deploy to one environment without deploying to the other.

There are a few different reasons for this separation:

• Developers are able make changes to integrations and secrets in the dev environment without impacting the prod environment. This allows for quick, easy development and removes the risk of accidentally breaking production when building in dev.

• Although you will often create the same integrations in dev and prod, they may have different configurations. For example, if you’re connecting to an API, that API may offer a sandbox URL for testing. In dev you would create an API integration pointing to the sandbox URL, and in prod you would create an integration with the same ID, pointing to the production URL.

• Similar to making integration changes, being able to deploy your backend to dev without affecting production allows risk-free testing and faster development.

Environments and local development

The dev environment is great for building and testing, but we realize that developers need a quicker, more dynamic way to develop than redeploying every time they change a line of code. To solve this problem, Squid allows developers to run their backend locally, without needing to deploy.

While writing code, the locally running backend is automatically rebuilt and restarted to include any new changes.

To learn about the Squid CLI and local dev commands, check out the documentation.

Developer IDs

To run your local backend, you’ll need your Squid Developer ID. Each user that’s added to a Squid organization has a corresponding developer ID, which can be found on the overview page of any Squid application in the console. When starting up your local backend, Squid pulls the application ID, region, and developer ID from the .env file in your backend directory and starts up a local server.

To view an example of a Squid backend running locally, check out this video:

To communicate with your local backend, the instance of Squid running on your client application must be initialized with the same developer ID. For example:

// Requests will be made to the `my-developer-id` local backend.
const squid = new Squid({
  appId: "YOUR_APP_ID",
  region: "us-east-1.aws",
  environmentId: "dev",
  squidDeveloperId: "YOUR_DEVELOPER_ID"
})

// Requests will be made to the deployed `dev` backend.
const squid = new Squid({
  appId: "YOUR_APP_ID",
  region: "us-east-1.aws",
  environmentId: "dev"
})

So how do environments fit into all this? Well it’s important to note that the local backend runs on thedev environment. There is no “mocked” environment - your local backend references the actual dev integrations. This means that:

• Any mutations (inserting/modifying data, creating/updating secrets, etc) made from within your local backend will be reflected in the dev environment.

• Any mutations made from a client connected to the local backend (with a squidDeveloperId) will be reflected in the dev environment.

• Integrations created in production cannot be accessed from the local backend.

Connecting to different environments

When initializing Squid on the client, you pass a few different options, including your appId, region, environmentId and squidDeveloperId:

const squid = new Squid({
  appId: "YOUR_APP_ID",
  region: "us-east-1.aws",
  environmentId: "dev",
  squidDeveloperId: "YOUR_DEVELOPER_ID"
})

• The environmentId option determines whether you’re connecting to the prod or dev environment.

• The squidDeveloperId option determines whether you’re connecting to dev or a locally running backend. Note: If prod is passed as the environmentId, the squidDeveloperId is ignored.

In most applications, you’ll want development builds to connect to dev and production builds to connect to prod. This means that typically you won’t see environmentId or squidDeveloperId as hardcoded strings, but instead as dynamic environment variables that can be configured at build or run time.

const squid = new Squid({
  ...
  environmentId: process,env.SQUID_ENVIRONMENT_ID,
  squidDeveloperId: process.env.SQUID_DEVELOPER_ID
})

Note: In dev and production builds (i.e. non-local builds), the SQUID_DEVELOPER_ID environment variable should be undefined.

Additionally, if you’re using Squid in a secure context (in another backend, a script, etc), you may want to initialize Squid with the apiKey option. This option bypasses security rules, and should be used only in non-user-facing contexts. Since the dev and prod environments have different API keys, you’ll need to be sure the apiKey passed matches the environmentId option.

Deploying

We’ve referenced “deploying” a couple of times, and it’s important to understand exactly what deploying is and when you should deploy your code. Effectively, deploying is the act of bundling your backend code and publishing it to Squid. A deployed backend behaves exactly like your locally running backend, except it runs on the Squid servers instead of your local machine.

When the dev and prod environments are initially created, they are created without a deployed backend. Since (almost) all integrations require security rules to be able to properly access data, you must deploy your backend before connecting to it from a non-local client (a client without a squidDeveloperId).

To deploy, you simply run the squid deploy script in your backend directory with the correct environmentId and apiKey options. This script is different per environment, and can be found on the application overview page in the Squid Cloud Console.

Deploying to dev

Now you might be wondering, if I can develop with a locally running backend, why should I deploy my backend to the dev environment at all? Well it’s a good question, and typically it’s best to think of dev as a middle ground between a local backend and production backend.

• A locally running backend is flexible, constantly changing, and may have bugs or be completely broken. Each developer can have their own locally running backend for testing their own features.

• A prod backend should be stable and well tested, and deploys should be made consciously. A bug in a deployed backend could lead to real impact for users.

A deployed dev backend falls somewhere in between. It’s essentially a place to trial run your backend before it goes live. Features are often developed in local backends and then deployed to dev once they’re reviewed. The dev backend should be somewhat stable, and ideally developers who aren’t working on any backend features can just develop against it by removing squidDeveloperId from their clients. However it also shouldn’t be so precious that you’re afraid to deploy and potentially break changes - it is for development after all!

Putting it all together

• Squid offers two environments: dev, an internal sandbox which can be used for development and testing, and prod, the environment for real production users.

• These two environments are kept separate, and any integrations or secrets created in one environment must also be created in the other.

• Additionally, Squid provides a local backend for development that runs based on the dev environment, which can be accessed by running squid start in your backend directory and setting the squidDeveloeprId option in your client.

• After developing a feature locally, it can be deployed to dev for testing, and then eventually deployed to prod.

To get a feel for developing for local and deployed backends, try out one of Squid Cloud's tutorials locally, and then deploy to dev. Happy coding!