```yaml
---
slug: mocking-aws-with-msw
published: 2024-03-06T18:49:00-08:00
description: A Better Way to Mock AWS
changelog: ~
---
```

We use AWS pretty heavily at Taskless, with their compute-on-demand making it easy for us to scale our bi-directional API Gateway from zero to thousands of concurrent requests with no additional effort. It's truly wonderful; that is, until it's time to write tests.

The path most developers go is to grab the [aws-sdk-client-mock](https://github.com/m-radzikowski/aws-sdk-client-mock) library, which works really well assuming you don't have presigning, are using AWS Timestream, and can keep all your AWS libraries on the exact same version to avoid type conflicts.

I'm also assuming you're here because you either need pre-signing, are using AWS Timestream, think force-upgrading all AWS client libraries for a single fix is a difficult pill to swallow, or are otherwise jammed on a traditional mocking approach. The good news is, there **is** another way. We just have to move from the node / module layer down to the network layer.

## What Are You Testing, Really?

First, the realization. We don't actually care what the `@aws-sdk/*` libraries do.

There's a lot of internals in the AWS client libraries (middleware, smithy, signing, etc). Every one of them has their own abstractions, inputs, outputs, and naming conventions. Some concepts, like middleware, are impossible to mock. None of that matters though. What we **do** care about is how our app reacts to network conditions, including those made by the SDK libraries.

And **that** we can test.

* We can introduce network delays and ensure the libraries we depend on handle these events well
* We can simulate a service being down
* We use APIs instead of SDKs, which are less volatile
* We gain a better understanding about how AWS makes its network requests
* We catch if a dependency suddenly starts phoning home

So how do you go about mocking the network? There's [nock](https://www.npmjs.com/package/nock) and Mock Service Worker / [MSW](https://www.npmjs.com/package/msw). Both are excellent libraries; I just prefer MSW so I can use the same testing patterns on the node.js and browser. While these next sections are written for MSW, they can be easily applied to a nock-based setup.

## Preparing for Network Mocks

Setting up for network based mocking requires a little bit of pre-work. Specifically, we want to knock out all our AWS environment variables with dummy values; this ensures if a request ever does fall through to the network layer, it cannot trigger a billable event. When launching any node.js app, including tests, you can include a `NODE_OPTIONS` environment variable which passes additional options through to the node process. In the case of a multi-process tester like [AVA](https://github.com/avajs/ava), this ensures the options are carried to each worker. For a single-process worker like [Jest](https://jestjs.io/), any node options are passed through as if they were directly on the command line.

```json
{
    // ...
    "scripts": {
        "test": "NODE_OPTIONS='-r ./test.setup.js' ava"
    }
}
```

The above snippet adjusts our test command to include additional node options. `-r <file>` tells node.js to include a file _first_ before running any other code. In this case, we want to load a bootstrap file. Our bootstrap will take care of removing all AWS environment variables for us, first by explicitly deleting all `aws_` prefixed values, then setting suitable test values for access, secrets, and tokens. I'm using [dotenv](https://www.npmjs.com/package/dotenv) for readability, but you can also explicitly set `process.env` if you prefer.

```js
const dotenv = require("dotenv");
const util = require("node:util");

util.inspect.defaultOptions.depth = 10;

for (const key of Object.keys(process.env)) {
  if (key.toLowerCase().startsWith("aws_")) {
    delete process.env[key];
  }
}

dotenv.populate(
  process.env,
  {
    AWS_ACCESS_KEY_ID: "testing",
    AWS_SECRET_ACCESS_KEY: "testing",
    AWS_SECURITY_TOKEN: "testing",
    AWS_SESSION_TOKEN: "testing",
    AWS_DEFAULT_REGION: "us-east-1",
    AWS_REGION: "us-east-1",
    // DEBUG: "*",
  },
  { override: true }
);

```

One important reason we remove all `aws_` items is because the `AWS_PROFILE` environment variable messes with pre-signing. If the variable is set, smithy middleware will attempt to authenticate and load the profile in question. So, don't be clever; take a scorched earth approach to the `aws_*` environment variables and ensure they're all replaced.

With confidence our AWS account won't get any surprise billing, we can [follow MSW's Getting Started Guide](https://mswjs.io/docs/integrations/node) for node.js and create our handlers. We can verify MSW is working because running our tests will tell us about unhandled requests, and our first call to AWS should automatically fail.

To make it easier to mock our network requests, we'll want to create a default handler.

## The Default Handler at `*`

Unhandled requests from MSW are fine, but I find that it's not always helpful telling you where / why something fell through to the unhandled request. I recommend adding these two handlers at the end of your chain, ensuring you get actionable errors when tests try and call out to AWS.

```ts
const handlers: RequestHandler[] = [
  // force inercept of any attempts to call the local AWS Credential Provider
  http.all("http://169.254.169.254/*", () => {
    throw new Error("Attempted to call local AWS Credential Provider");
  }),

  // Provide additional info beyond MSW's default unhandled request error
  http.all("*", async (info) => {
    const request = info.request.clone();

    const debug = {
      url: request.url,
      method: request.method,
      headers: Object.fromEntries(request.headers.entries()),
      body: await request.text(),
    };

    console.error("Unhandled Request");
    console.error(JSON.stringify(debug, null, 2));
  }),
];
```

Our first handler (the `169.254...`) takes care of the AWS Credential Provider. In some scenarios, like when `AWS_PROFILE` is set to a dummy value, the credential provider is automatically called by AWS. Adding a catch-all for the credential provider will tell us immediately if AWS is attempting to verify our test credentials.

The second handler is a better debugger. Instead of a thrown error that tells you the network request came from within AWS, you can unpack the URL, method, headers, and body. Usually this additional data makes it much easier to see what request isn't being mocked. As a bonus, this gives you all the information you need to write a matching handler of your own.

## Make a Lot of Mocks

There's no limit to the number of mocks you can have. Don't be afraid to have a dozen handlers for `https://dynamodb.*.amazonaws.com`, and return `undefined` if you don't want to handle the request. A return value of `undefined` from a handler tells MSW to try the next one in-sequence. For example, I check DynamoDB handlers for a specific table using the following TypeScript:

```ts
export const isGetForTable = async (original: Request, table?: string) => {
  const request = original.clone();
  const body = (await request.json()) as GetItemInput;
  if (table) {
    return body.TableName === table;
  }

  return true;
};
```

DynamoDB operates off of JSON, making it trivial to check the `TableName` for a match. When adding these checks, don't forget to `clone()` the request object! Because MSW uses the built-in `Request` object, you can only read from the request body once, just like when you're using `fetch()`.

Most of your helpers will focus on "is this a `<blank>` command" and "is this a `<blank>` command for resource `<blank>`". You only have to write these once, and then you can reuse them anywhere.

## A Little JSON, A Little XML, A Few Surprises

As you mock, you're going to discover some clients operate on XML while others work with JSON, even though all v3 endpoints support JSON now. Just [roll with it](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-xml-api-responses.html) and follow the AWS API doc's XML responses when required. You'll know when this happens because despite returning JSON, the AWS client will complain about a missing `<` or unhandled `{` in the response.

Some services, like AWS Timestream, make multiple requests. The first request (the one you'd normally associate with an endpoint) just retrieves the *real* endpoint, and the second request goes to this discovered endpoint. When you find these discovery-based services, take advantage of wildcard routes to simplify the network mocks.

Finally, while all this may seem more difficult than the usual mocking pattern, keep with it. The AWS API itself is absurdly stable. Seriously. The SQS API version is tagged November 5, 2012. So once you get these mocks working to your liking, they'll continue to work for the foreseeable future. And if AWS changes something that causes your network requests to change, you'll find out about it immediately.

## Supplement: Known Weird AWS Replies

Because not everything mocked in AWS is obvious, I'll add specific notes about libraries and mocks as I uncover them.

### SQS Uses XML

It's used in almost all infrastructure, but SQS responses are XML. Even worse, you have to include an MD5 digest that is checked by a smithy middleware. The following snippet can create XML success and error responses for the AWS XML API.

```ts
export const sendMessageXMLError = (
  code = "TestingError",
  message = "This is a custom error"
) => /* XML */ `
<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>${code}</Code>
  <Message>${message}</Message>
  <RequestId>7fe4446e-b452-53f7-8f85-181e06f2dd99</RequestId>
</Error>
`;

export const sendMessageXMLResponse = (messageBody: string) => /* XML */ `
<?xml version="1.0" encoding="UTF-8"?>
<SendMessageResponse xmlns="http://queue.amazonaws.com/doc/2012-11-05/">
    <SendMessageResult>
        <MessageId>374cec7b-d0c8-4a2e-ad0b-67be763cf97e</MessageId>
        <MD5OfMessageBody>${createHash("md5")
          .update(messageBody)
          .digest("hex")}</MD5OfMessageBody>
    </SendMessageResult>
    <ResponseMetadata>
        <RequestId>7fe4446e-b452-53f7-8f85-181e06f2dd99</RequestId>
    </ResponseMetadata>
</SendMessageResponse>
`;

export const createMockSendMessageRespone = (messageBody: string): Response =>
  HttpResponse.xml(sendMessageXMLResponse(messageBody), {
    status: 200,
  });
```

### S3 PutObjectCommand Requires an Empty Body

When putting an object into s3 via `PutObjectCommand`, smithy (the engine underneath the AWS client libraries) expects an HTTP body. A test response needs to include both an empty body and a `Content-Length` header of `0`. This helper makes it easier to create responses for the command.

```ts
type MockResponseBodyOptions = {
  time?: Date;
  etag?: string;
  requestId?: string;
};

export const createMockPutResponse = (
  options?: MockResponseBodyOptions
): Response =>
  HttpResponse.arrayBuffer(new TextEncoder().encode(), {
    status: 200,
    // https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html#API_PutObject_ResponseSyntax
    headers: {
      Etag: options?.etag ?? "1b2cf535f27731c974343645a3985328",
      "Last-Modified": options?.time
        ? options.time.toISOString()
        : new Date().toISOString(),
      "x-amz-request-id":
        options?.requestId ?? "7fe4446e-b452-53f7-8f85-181e06f2dd99",
      "content-length": "0",
    },
  });
```

Link

strong

code

{
    // ...
    "scripts": {
        "test": "NODE_OPTIONS='-r ./test.setup.js' ava"
    }
}


Fence

const handlers: RequestHandler[] = [
  // force inercept of any attempts to call the local AWS Credential Provider
  http.all("http://169.254.169.254/*", () => {
    throw new Error("Attempted to call local AWS Credential Provider");
  }),

  // Provide additional info beyond MSW's default unhandled request error
  http.all("*", async (info) => {
    const request = info.request.clone();

    const debug = {
      url: request.url,
      method: request.method,
      headers: Object.fromEntries(request.headers.entries()),
      body: await request.text(),
    };

    console.error("Unhandled Request");
    console.error(JSON.stringify(debug, null, 2));
  }),
];


export const isGetForTable = async (original: Request, table?: string) => {
  const request = original.clone();
  const body = (await request.json()) as GetItemInput;
  if (table) {
    return body.TableName === table;
  }

  return true;
};


export const sendMessageXMLError = (
  code = "TestingError",
  message = "This is a custom error"
) => /* XML */ `
<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>${code}</Code>
  <Message>${message}</Message>
  <RequestId>7fe4446e-b452-53f7-8f85-181e06f2dd99</RequestId>
</Error>
`;

export const sendMessageXMLResponse = (messageBody: string) => /* XML */ `
<?xml version="1.0" encoding="UTF-8"?>
<SendMessageResponse xmlns="http://queue.amazonaws.com/doc/2012-11-05/">
    <SendMessageResult>
        <MessageId>374cec7b-d0c8-4a2e-ad0b-67be763cf97e</MessageId>
        <MD5OfMessageBody>${createHash("md5")
          .update(messageBody)
          .digest("hex")}</MD5OfMessageBody>
    </SendMessageResult>
    <ResponseMetadata>
        <RequestId>7fe4446e-b452-53f7-8f85-181e06f2dd99</RequestId>
    </ResponseMetadata>
</SendMessageResponse>
`;

export const createMockSendMessageRespone = (messageBody: string): Response =>
  HttpResponse.xml(sendMessageXMLResponse(messageBody), {
    status: 200,
  });


type MockResponseBodyOptions = {
  time?: Date;
  etag?: string;
  requestId?: string;
};

export const createMockPutResponse = (
  options?: MockResponseBodyOptions
): Response =>
  HttpResponse.arrayBuffer(new TextEncoder().encode(), {
    status: 200,
    // https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html#API_PutObject_ResponseSyntax
    headers: {
      Etag: options?.etag ?? "1b2cf535f27731c974343645a3985328",
      "Last-Modified": options?.time
        ? options.time.toISOString()
        : new Date().toISOString(),
      "x-amz-request-id":
        options?.requestId ?? "7fe4446e-b452-53f7-8f85-181e06f2dd99",
      "content-length": "0",
    },
  });


Document

Mocking AWS at the Network Level

```yaml
---
slug: expo-community-flipper-retired
published: 2023-08-04T18:19:00-07:00
description: Thoughts on "completing" an open source project
excerpt: That moment when you're comfortable putting a temporary project to rest.
changelog: ~
---
```

With [the release of Expo 48](https://blog.expo.dev/expo-sdk-48-ccb8302e231), `expo-community-flipper` (gh)[https://github.com/jakobo/expo-community-flipper] (npm)[https://www.npmjs.com/package/expo-community-flipper] can finally declare its purpose fulfilled. A year ago, I was trying to debug redux inside of the Chrome Debugger and nearly lost my mind. It wasn't just a bad experience. It was an **awful** experience, defined by `console.log` and prayers.

There was [react-native debugger](https://github.com/jhen0409/react-native-debugger) and [reactotron](https://github.com/infinitered/reactotron), but nothing that worked for me specifically. My setup was **weird** but not unlikely. WSL2, Windows 11, and the iOS app running via Expo's custom dev app. Only one thing really worked with this setup, and that was [Flipper](https://fbflipper.com/). Plus, I could finally see FPS information for animations as an added bonus (more on that later).

## Expo & Flipper in a Graph

![Download statistics for expo-community-flipper](https://user-images.githubusercontent.com/1795/222308501-930d3ee3-1121-4895-801d-0c3a544d7f88.png)

One of the problems with using Flipper was that it required editing the Podfile. This is all well and good if you're using react-native on a mac and love running XCode yourself. But if you're that weird-dev-guy with WSL 2, running XCode is ~~impossible~~ legally troublesome at best. As a lucky coincidence, Expo pushed out SDK 43 and began documenting their config plugin system: scriptable JavaScript that could edit & change build files as part of a remote CI or build pipeline.

And so, starting with SDK 43, I released the [first version of expo-community-flipper on npm](https://www.npmjs.com/package/expo-community-flipper/v/43.0.0) into the wild. With every subsequent SDK, I'd check the [expo base template](https://github.com/expo/expo/tree/main/templates/expo-template-bare-minimum/ios) and the [React Native Upgrade Helper](https://react-native-community.github.io/upgrade-helper/) and focus on changes to the `Podfile`.

It was a scramble. It wasn't always obvious _what_ changed. Sometimes a random `AppDelegate.m` was the culprit, other times it was the ruby scripts to include Flipper upstream in the React Native libraries. It got better though with every release.

* [I wrote a post for the Expo team](https://blog.expo.dev/developing-react-native-with-expo-and-flipper-8c426bdf995a) to go along with my WSL 2 article I did earlier for them
* [Alexandre Moureaux hooked performance monitoring in](https://www.youtube.com/watch?v=Yl6gj0ZLB3Y) and gave a talk
* [Abdulrahman wrote an article](https://medium.com/@abdulrahmanhashem/8-ways-to-debug-your-react-native-app-with-expo-the-comprehensive-guide-538655cf1684)

Debugging was finally _easier_. It would just be nice to get out of reaction-mode when new SDKs were imminent.

## Enter the Expo Team and Merging Up

SDK 47 marked the beginning of the end in a positive way. There were changes coming that would break `expo-community-flipper`, and the expo team wanted to be proactive about the changeset. This was the first time in the project's history that `expo-community-flipper` was going to be SDK ready on launch. This proactive outreach got the wheels turning though. What if expo just did the "Flipper bits" itself? They've got a much better testing suite, there are already plugins for modifying the `Podfile`, and then Flipper could get the attention it deserved.

Ideally, SDK 47 would be the last time we'd have to do this npm release dance. After talking with the Expo team, we [launched a plan to merge `expo-community-flipper` upstream](https://github.com/jakobo/expo-community-flipper/issues/41) into the `build-properties` plugin. [It landed in January](https://github.com/expo/expo/pull/20890) and Flipper support became an official part of the `expo-config-build-properties` plugin in SDK 48.

This section is pretty uneventful because the Expo team is just that good. I worked with [Kudo Chien](https://github.com/Kudo) for most of the PR and integration, and Expo had the infrastructure to absorb the changeset without issue. I was honestly impressed at how smooth everything went. I also like the "Why" and "How" sections they encourage on PRs for explaining their changes.

## Ending `expo-community-flipper`

Finally came the goodbyes. A README change, a release on SDK 48 with a `peerDependency` that keeps it from running against newer Expo versions, and an `npm deprecate`. And it was done. With Expo SDK 49 released and deprecating 46, and SDK 50 on the horizon, `expo-community-flipper` will be finally be archived and the project complete.

It's surreal. It feels good. Not many open source projects get a happily ever after.

Thoughts on "completing" an open source project

The End of expo-community-flipper

```yaml
---
slug: line-numbers-in-eval
published: 2015-03-16T00:00:00.000Z
description: You should never do this. But "never" is a bit too absolute for engineering
changelog:
  - on: 2017-10-01
    note: Better alternatives than `eval` finally exist with `await import()` syntax. You should definitely explore those. Additionally, LinkedIn has sunset [Inject](https://github.com/linkedin/inject) on their production site now that many viable alternatives exist. Hoo-ray modern web development!
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

When it comes to executing code, `eval()` is a [terrible idea](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval). However, somewhere in your coding career, you will need to evaluate code.

And unfortunately, if there's an error in the code, any line numbers are going to point to the invocation of `eval()` and not the erroring line within the body itself. Lucky for us, `<script>` tags correctly report erroring lines with line numbers.

Before we go any further, this is an obligatory **don't use eval**. It should be an option of last resort. Your Content Security Policy is hopefully already preventing you from doing this.

## Trying to not Evaluate: `.innerHTML` or `.text`

The first attempt was to set `innerHTML` to your JavaScript, and then place that node onto the page via `appendChild`. If you are only concerned with modern non-Microsoft browsers, you'd be done at this point.

```js
// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  scr.innerHTML = code;
  return scr;
}
```

Internet Explorer won't execute the JavaScript inside of this script tag, even though the `innerHTML` property is set. However, it uniquely [supports the "text" property](http://msdn.microsoft.com/en-us/library/ie/ms535892(v=vs.85).aspx), which no other browsers seem to support. When set, scripts in IE will execute once appended to the DOM. A few changes to our above script, and we have a "safe" method. Borrowing from the idea of [feature testing for things only IE supports](./enhancing-for-bugs), we'll actually feature test against this text property, falling back to alternate versions as needed.

```js
// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  try {
    scr.text = code;
  } catch (e) {
    try {
      scr.innerHTML = code;
    } catch (ee) {
      return false;
    }
  }
  return scr;
}

```

## Tying it Together

Further optimizations can be used to pre-select the best insertion method. In [inject](https://github.com/linkedin/inject/blob/68c343180ed3a08dffb0ad445fe45d70908683e1/src/executor.js#L129), we wrap the code we want to execute within a function declaration and assignment. This enables us to store the results of the `eval` so that modules can then be executed on demand. The below example is just a simple JSON evaluator as a proof of concept. Like all things `eval`, you should always be cautious with invoking it on items that are not 100% in your control.

```js
// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
var createScriptNode = (function () {
  var testScr = document.createElement("script"),
    property = "innerHTML";
  testScr.type = "text/javascript";
  try {
    testScr.text = ";";
    property = "text";
  } catch (e) {}
  return function (code) {
    var scr = document.createElement("script");
    scr.type = "text/javascript";
    scr[property] = code;
    return scr;
  };
})();

var evalJSON = function (jsonString) {
  var exec = ["window.results =", jsonString],
    node = createScriptNode(exec),
    results;
  document.body.appendChild(node);
  results = window.results;
  delete window["results"];
  return results;
};
```

While this code definitely makes it possible to do more harm than good (we're stepping around JSLint/Hint `eval` checks), the upside is huge when you're evaluating code and need to understand at what line something is failing on. In the case of a module loading system, having both the upsides of a lazy `eval` and the  embedded script tag is a huge win.


This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.

Better alternatives than `eval` finally exist with `await import()` syntax. You should definitely explore those. Additionally, LinkedIn has sunset [Inject](https://github.com/linkedin/inject) on their production site now that many viable alternatives exist. Hoo-ray modern web development!

You should never do this. But "never" is a bit too absolute for engineering

// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  scr.innerHTML = code;
  return scr;
}


// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  try {
    scr.text = code;
  } catch (e) {
    try {
      scr.innerHTML = code;
    } catch (ee) {
      return false;
    }
  }
  return scr;
}



// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
var createScriptNode = (function () {
  var testScr = document.createElement("script"),
    property = "innerHTML";
  testScr.type = "text/javascript";
  try {
    testScr.text = ";";
    property = "text";
  } catch (e) {}
  return function (code) {
    var scr = document.createElement("script");
    scr.type = "text/javascript";
    scr[property] = code;
    return scr;
  };
})();

var evalJSON = function (jsonString) {
  var exec = ["window.results =", jsonString],
    node = createScriptNode(exec),
    results;
  document.body.appendChild(node);
  results = window.results;
  delete window["results"];
  return results;
};


Line Numbers in eval

```yaml
---
slug: developing-react-native-with-expo-and-flipper
published: 2021-12-07T01:00:00.000Z
description: Goodbye Chrome Debugger, hello Flipper
repost:
  url: https://blog.expo.dev/developing-react-native-with-expo-and-flipper-8c426bdf995a
  text: This article was written for the Expo Blog and appeared with the title _Developing React Native with Expo and Flipper_. It's been reproduced here with permission.
changelog:
  - on: 2021-12-03
    note: There’s now an Expo community plugin for setting up Flipper in your Expo projects. The section on Flipper integration was updated to reflect this change.
---
```

There’s a lot of great React Native modules out there, but most of them require a custom iOS or Android build, leaving “ejecting” as the only option for Expo users. That changed in SDK >42, when Expo added the ability for Expo Application Services to create custom development builds of your app.

What’s a custom development build? It’s not just any Expo Go app, it’s your Expo Go app; complete with any React Native module you ever wanted, all without ever having to hit the eject button.

And now that Expo 43 includes React Native 0.63, [Flipper by Facebook](https://fbflipper.com/) is available by default; there’s no better time to ditch the old “Chrome Developer Tools” way of debugging your React Native app. Not only will you gain access to device information and crash logs, you’ll also have Flipper’s amazing plugin library. Everything from Apollo to Redux debuggers are in there.

If you’d like to skip to the end result, check out the [jakobo/expo-cdc-example](https://github.com/jakobo/expo-cdc-example) repo as that’s what we’ll be building towards.

## Overview
- Configuring your code for EAS
- Creating a development build of your app
- Connecting to your app via Flipper
- Final considerations

## Create an EAS-Friendly Expo App
We’re going to start our journey by making a run-of-the-mill Expo application (install Expo CLI if needed with `npm install -g expo-cli`). When we run `expo init -t expo-cdc-example`, we’ll be given a standard Expo application, configured for Typescript. If you would prefer vanilla JavaScript, just omit the `-t` option. The result (minus our hidden folders and our lockfile) looks like this:

```
/
|- assets
|- app.json
|- App.tsx
|- babel.config.js
|- package.json
|- tsconfig.json
```

From here, we can run `expo start` and view our Expo app. We could also build locally, but what we’re really looking for is to let someone else do all the work for us. This is doubly true if we’re developing on Windows, as XCode isn’t even an option for making an iOS app. Enter Expo Application Services (EAS).

EAS lets you use Expo’s hardware to build your iOS/Android application, and has its own CLI. You can use EAS for building non-expo applications as well, so the EAS cli isn’t bundled with Expo. We’ll need to install it globally like we did with our `expo-cli`.

    npm install -g eas-cli

Let that run, and you’ll have a new `eas` command available. The EAS CLI doesn’t have an `init` command, and while running the `eas` build command will generate the configuration file for us, we’ll have greater control if we create the file ourselves. Create a file named `eas.json` in your application root and copy/paste the following configuration in:

```json
{
  "cli": {
    "version": ">= 0.34.0"
  },
  "build": {
    "base": {
      "env": {}
    },
    "development": {
      "extends": "base",
      "developmentClient": true,
      "distribution": "internal",
      "releaseChannel": "default",
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "extends": "base",
      "distribution": "store",
      "releaseChannel": "stable",
      "android": {
        "buildType": "app-bundle"
      }
    }
  }
}
```

This sets up EAS to build something we’ll call a “preview” build. It will behave just like our production app, but it’s claimed ownership of the default release channel. By utilizing `releaseChannel: "default"` in our development build, and not our production builds, we can make sure that an accidental `expo publish` doesn’t push code to our live application. There’s [a lot more to `eas.json`](https://docs.expo.dev/build/eas-json/) than we’re covering in this article, but the above is enough for us to launch our builds. If you’re already using the default channel for your app store releases, you can change value of the `releaseChannel` property.

We can now tell EAS to build our app. We’ll want to specify our build profile preview as part of the command.

If this is your first time running EAS, you’ll want to associate any iOS devices with your ad hoc provisioning profile. You can [follow the steps in the Expo documentation](https://docs.expo.dev/build/internal-distribution/), or just run `eas device:create` and follow the prompts. To generate our build, we just need to run `eas build --profile=preview`.

EAS will be off building things, and you can go get a cup of coffee. ☕

After a while, you’ll have a shiny build that you can install on your iOS/Android device! EAS runs in the background too, so no need to wait for a build to finish, you can get back to coding.

## Configuring EAS For a Development Build

So far, we’ve created an Expo app, we’ve configured EAS, and we’ve kicked off a custom build. But EAS doesn’t just let you make custom production builds, it **lets you make development builds too!** That’s right, it is your own Expo Go, with your own modules. And we’ll be using EAS to build it.

Enabling a development builds means creating a new profile in our `eas.json`. These additions should go alongside your preview build.

```json5
{
  "build": {
    // ...
    "devclient": {
      "extends": "base",
      "releaseChannel": "default",
      "distribution": "internal",
      "developmentClient": true,
      "android": {
        "buildType": "apk"
      },
      "ios": {
        "simulator": true
      }
    }
  }
}
```

Our new profile, `devclient` adds a few EAS options. The `developmentClient` flag tells EAS that we want a custom build of the Expo development app, and the `ios.simulator` field tells EAS not to create an iOS app, but a bundle that’s designed for the iOS Simulator.

Now, kick off your new build and go get more coffee. ☕

    eas build --profile=devclient

When that finishes up, you’ll have a custom simulator build. When you install that on your simulator and launch it, it will look different than your usual Expo Go app.

![The Expo Custom Development Client launch screen](https://user-images.githubusercontent.com/1795/146845551-1bd86cb8-8236-4805-ba10-2bf24ab0cb82.png)
_The Expo Custom Development Client launch screen_

Instead of the usual expo start command, it tells us our app needs to be started with the `--dev-client` flag, so let’s do that. Stop your expo start if it’s running, and restart it with `expo start --dev-client`.

The project will show up in your development build with a URL structure of `exp+<project>://expo-development-client/…`. The `exp+<project>` protocol helps the native OS tell the difference between your custom Expo app and any others you might have on the simulator or device.

So long, Expo Go, hello Development Builds. 💅

## Hello Native Modules, Hello Flipper

All of the above setup needs to be done exactly once, and the payoff is huge. We’re going to get a better debugger for React Native, called [Flipper](https://fbflipper.com/), by Facebook. Go download the app, and we’ll set up our development build to use this native module.

First, we’ll need to install Flipper and its dependencies, which is a straightforward pair of command: `expo install react-native-flipper react-devtools-core` for our expo related code and `yarn install expo-community-flipper` for our build plugin we'll be using later.
Then, we’ll need to tell our App to connect to Flipper in our `App.tsx` file:

```tsx
// App.tsx
import { connectToDevTools } from "react-devtools-core";
if (__DEV__) {
  connectToDevTools({
    host: "localhost",
    port: 8097,
  });
}
```

Since we’ve added a new native module, we’ll need to create a new development build that has our native iOS and Android code bundled in. Because Flipper also requires changes to our app’s `Podfile`, we’re also going to make use of Expo’s [Config Plugin](https://docs.expo.dev/guides/config-plugins/) system. Because we already installed the [community Flipper plugin](https://www.npmjs.com/package/expo-community-flipper), it's as easy as adding the plugin to our `app.json`.

```json5
{
  "expo": {
    // ...
    "plugins": ["expo-community-flipper"]
}
```

One last time (and one last ☕): `eas build --profile=devclient`

Install the new build on your simulator, open up the Flipper App and it just works 🤯

You can repeat this for any Native Module you want, though Flipper is an excellent starting point since it lets you use `react-native-reanimated` v2 with TurboModule support, frees you from the built-in Chrome debugging tools, gives you crash logs, and more. Just remember that you’ll need to create a new development build when you add a new module, or make judicious use of try/catch blocks to ensure you don’t throw an error.

## Keep Building From Here

This is just the start of what you can do with Expo’s development builds and Native Module support. Most Native Modules will work out of the box in a development build thanks to React Native’s autolinking, but if you do need custom changes to your `Info.plist` or `Manifest.xml` files (or even editing a `Podfile` like we did today), Expo can take care of that too as part of the build process. These [config plugins](https://docs.expo.dev/guides/config-plugins/) let you modify the plist and manifest without ejecting your app and are configured from within your `app.json`.

If you still run into issues, there’s an #EAS channel on the [Expo discord](https://discord.gg/4gtbPAdpaE) and the [Expo Forums](https://forums.expo.dev/) have an entire section dedicated to EAS.

There’s now an Expo community plugin for setting up Flipper in your Expo projects. The section on Flipper integration was updated to reflect this change.

This article was written for the Expo Blog and appeared with the title _Developing React Native with Expo and Flipper_. It's been reproduced here with permission.

{
  "build": {
    // ...
    "devclient": {
      "extends": "base",
      "releaseChannel": "default",
      "distribution": "internal",
      "developmentClient": true,
      "android": {
        "buildType": "apk"
      },
      "ios": {
        "simulator": true
      }
    }
  }
}


// App.tsx
import { connectToDevTools } from "react-devtools-core";
if (__DEV__) {
  connectToDevTools({
    host: "localhost",
    port: 8097,
  });
}


{
  "expo": {
    // ...
    "plugins": ["expo-community-flipper"]
}


Developing React Native with Expo and Flipper

```yaml
---
slug: nodejs-memory-leak-heroku
published: 2022-07-19
description: You can connect to your production Heroku instance, debug it live, and even trace down memory leaks.
keywords: heroku, r14, r15, memory leak
changelog: ~
---
```

There's nothing more frustrating that your node.js app leaking memory. If you're coming here because of Heroku R14 / R15 errors, take some deep breaths, it'll be okay. Heroku's smart enough to swap to disk when this happens, and will kill and restart your app if things get absolutely wild.

## Background

![Heroku Dashboard with a lovely orange band of R14 errors](https://user-images.githubusercontent.com/1795/163650457-2371246f-bc80-4482-b42e-8bfdbf664a1a.png)

It started with my email box getting pelted with warnings that the memory quota on a project I advise for was getting hit with R14 errors. Going to the Heroku metrics page confirmed that yes, something was clearly wrong. In the above picture, you can see again and again the memory usage surge and then Heroku responding with an R15 and force rebooting the server. Moments later, the memory usage was growing again.

It's a Memory Leak, Ruin of Productivity and afternoons. 😭 

However, since the last time I dealt with a memory leak (2011) the tools have come a long way. So here's how you triage a production memory issue, run analysis against your currently leaking production boxes, and stamp out the issue.

## Modern Tools

The tools for dealing with a memory leak have gotten much better, especially if you're on Heroku. You only need two:

* A current version of Chrome (which comes with the amazing v8 debugger)
* The Heroku CLI (if on Heroku)

The first does 90% of the heavy lifting, while the second now has all the commands we need to turn on a debugger in production and forward debug data to our local machine. Make sure you've logged in to the Heroku CLI if you're triaging Heroku.

## Opening Chrome's Inspector

The Chrome Developer Tools are always available on `chrome://inspect`, which can be put in your browser's address bar. The DevTools are useful for debugging everything from node.js processes to Service workers. For now, we want to stay on the `Devices` tab, make sure `Discover network targets` is checked, and leave that window open while we set other things up. You may even see a few device targets show up that Chrome's discovered. In my case, apparently my TV can be seen. Odd, but neat.

![The Chrome developer tools](https://user-images.githubusercontent.com/1795/163651415-d75abf95-e781-45fb-ab2c-3e9adcb6ba1d.png)

## Enabling the Debugger With a Signal

The most common way to start debugging node is to add the `--inspect` CLI arg, either directly (via `node --inspect <your file>`), or in the appropriate env values ( `NODE_OPTIONS="--inspect" node <your file>`). In production environments, it may not be desirable to enable the debugger on every start; in the case of Heroku which randomly assigns ports, you can't even guarantee the debug port of `9229` is available. But, you can enable the debugger a different way.

From the [node.js debugging page](https://nodejs.org/en/docs/guides/debugging-getting-started/)

> Node.js will also start listening for debugging messages if it receives a SIGUSR1 signal. (SIGUSR1 is not available on Windows.) In Node.js 7 and earlier, this activates the legacy Debugger API. In Node.js 8 and later, it will activate the Inspector API.

Sending a signal is as easy as using the unix `kill` command, where `<PID>` is your node.js process ID:

```sh
$ kill -usr1 <PID>
```

You can try this locally by running `ps aux | grep node` to find your node.js process, and then using the `PID` for the above `kill` command. Personally, I find that the `usr1` signal is not only more reliable (works everywhere) but also means you don't have to completely restart the server. When you send `usr1`, node just sees the signal and starts up its debugger. It'll pop up moments later in the Chrome DevTools.

![local development showing the inspector starting](https://user-images.githubusercontent.com/1795/163651616-5d423ec2-bdd9-4bcd-828c-29e4bbf5335e.png)

![the development tools showing the new remote target](https://user-images.githubusercontent.com/1795/163651579-b7181e72-86d9-47e9-9d46-eb4c3cf76bc4.png)

Hit the `inspect` link and you'll be taken to a very familiar DevTools interface, but optimized for node.js debugging. In addition to the Console and Sources, you'll also have "Profiler" for CPU profiling, and "Memory" for memory usage profiling,

![connected development tools, ready to go](https://user-images.githubusercontent.com/1795/163651715-22c7a39a-81cb-43da-bc97-4e17523ffb56.png)

## Connecting to Heroku in Production

Once that's all working, it's time to connect to our production instance in Heroku and take some live samples. Close the inspector and local development server if needed, and make sure your `heroku` command works. If you're using a different environment such as Digital Ocean, look up SSH instructions to get to your host. They'll be different on every provider.

For heroku, there's the `ps:exec` command which gives you a shell on your default process for dyno 1. Be sure to specify your `<APP_NAME>` so that you're ssh-ing into the correct box, and if you need to connect to a dyno process that's not `web`, add the `-d <dyno>` flag.

```sh
$ heroku ps:exec -a <APP_NAME>
```

![connecting to a remote box over SSH](https://user-images.githubusercontent.com/1795/163652037-8309d4c9-452a-4bf5-848a-98f466346471.png)

From here, we can search our node process with `ps aux | grep node` and start the debugger with `kill -usr1 <PID>`. Our debugger will start, but obviously we can't see it yet. Heroku (and other providers) don't expose port `9229` to the internet for security reasons. Open another terminal window and use heroku's forwarding command to create a local tunnel for your debugger (and add the optional `-d` flag if needed).

```sh
$ heroku ps:forward -a <APP_NAME>
```

And just like that, your production instance shows up in the Chrome DevTools.

## Sampling

Taking samples is straightforward. Wait for the VM instance size to grow, click the trash can icon (force GC) to ensure it's actually grown by a reasonable amount, and then hit the **Take Snapshot** button to capture a memory heap. Chrome DevTools will be busy for a bit, but it'll create a Heap, which it adds to the left-hand side of the Memory profiler. Every heap is a detailed analysis of what was in JavaScript at that exact moment. Every string, object, key, event, closure, callback; you name it, it's here.

Collect several samples (5-6 is ideal) since you'll be looking for identifiable trends. I also recommend waiting about 2-3 MB between each sample. We want our growth in memory to be noticeable, and whatever's leaking to stick out.

Here, I've got 6 production samples of a leaking app. In the time I sampled, we added about 15MB to the footprint. 😱 

![chrome devtools with several heaps loaded](https://user-images.githubusercontent.com/1795/163652520-5df538be-aa9a-4ae7-bf41-17617abe030f.png)

What matters is we can see the memory growing, we have several samples of the Heaps in question (which contain our growing memory), and those Heaps are readable by the Chrome DevTools. We can save the Heaps, disconnect from our production machine (which also closes the debugger), and get to our analysis.

## Using Heap Compare

Select the newest (largest) Heap, and above the list of objects in the heap, change from `Summary` to `Comparison`. This changes the Heap view from telling you what's in the Heap to what changed **between** Heaps.

![how to change from summary to comparison view](https://user-images.githubusercontent.com/1795/163652680-cd5f2530-6b12-4c00-8014-326df53c8a80.png)

Sort the table by `# Delta`, and the problem suddenly becomes very obvious.

![a sorted by delta comparison](https://user-images.githubusercontent.com/1795/163652782-5832abe0-c4c3-4e79-b804-100f1916fa47.png)

We can compare against a few other Heaps (that's why we captured them) to isolate the source of the memory leak. Here, I'm comparing Heap 5 to Heap 4, where the number of `(concatenated string)` is much smaller and easier to manage. There's a lot of weird date strings like "-137 days, 21" being created and retained. Clicking on one gives us the full Retainer log. It's part of a larger string, that's part of a larger string, that's in `discountTimeLeft` in the update cycle of a React component called `DiscountBanner`, inside of a... `Timeout`.

![The memory leak source](https://user-images.githubusercontent.com/1795/163653410-35a401c4-0b85-4eb6-9c14-4eec51878a0d.png)

Opening up the `DiscountBanner` culprit, there's a `setInterval` in the `constructor`. Fixing this and redeploying closed the memory leak. It turned out that when next.js was running in Heroku, the `setInterval` would just keep on running and building its string about how many days were left on the discount. Since that string was locked in the `setInterval` callback, it could never be garbage collected by v8. Add in a few thousand requests per second, and those discount strings would ultimately take up all of the available memory and cause Heroku to restart the server with an R15 error.

## More than Heaps

I only needed the Heap compare, but the CPU profiler and the Memory timeline (Allocation instrumentation on timeline) can help narrow the issue even further in a larger application. The hardest part is getting a reproducible issue. Looking at production not only makes it easier, but ensures you're solving the right problem. And when you're done, you'll never put a `setInterval` in a React component constructor again. 😆 

You can connect to your production Heroku instance, debug it live, and even trace down memory leaks.

blockquote

Solving a Node.js Memory Leak on Heroku

Because everything is just some form of print()