Expo EAS

Expo provides a React Native build tool called Expo Application Services (EAS), it allows you to build and submit applications easily. By default when you run eas build, it will create a build on their cloud services and you will have to pay for priority pipeline execution. The Free plan at the time of writing only allows you to build one pipeline at a time. In our case we already have CircleCI subscription so it would be better if we can build app bundles there. Fortunately there is a --local option which allows building app bundles locally. You will still need to set up EAS on Expo, for detail guide, please refer to their setup guide. Here is an example command we use to build our app bundles using CircleCI MacOS and JVM executor.

eas build --profile preview --platform ios --clear-cache --local --non-interactive --output "my-app.ipa"

We use eas submit to automatically push master/production build to app store and play store after manual approval. The key here is that for BrowserStack we need to use internal distribution profile so that we can install on their devices. You don’t have to add their remote devices to Expo as BrowserStack re-signs the bundles upon upload so that they can be installed on their devices.

BrowserStack

To make current manual testing easier I decided to introduce BrowserStack App Live, it allows the team to test the app using remote real devices and it offers quite a lot of iOS and Android options. It also comes with local testing which allows us to connect to our backend services hosted behind our vpn. There are some options for getting access to the app. You can upload app .ipa and .apk bundles, or install via Apple TestFlight and Google Play. To test push notification, please refer to guide here. If you are uploading the .ipa Apple bundle, unfortunately it is not supported at the time of writing, the only way to test push notification on iOS is installation via TestFlight.

Overall Pipeline View

Here is what our overall pipeline looks like:

For branch build we have a manual trigger to push bundles to BrowserStack as we don’t want every commit to go through manual QA process. We only trigger this once the PR has been reviewed and ready for QA. The bundles are also uploaded to S3 so that we can retrieve them and install locally easily. You will need to register your test physical devices with Expo using eas device:create so that the bundles can be installed. See internal distribution setup here.

For master/main branch build we went through the similar process with the only difference that builds are automatically pushed to BrowserStack with a manual trigger to push to production following production profile build. We use standard-version to automatically increase our app version so that every build is able to be released. The BrowserStack preview here is quite useful during our review session and following that we will decide whether the candidate version is good enough for release.

CircleCI config

Here are some useful CircleCI steps for the pipeline described above:

Build Android Using OpenJDK executor

eas-build-android:
    executor: android
    parameters:
      profile: 
        description: distribution profile
        type: string
        default: preview
    environment:
      PROFILE: << parameters.profile >>
    steps:
      - attach_workspace:
          at: ~/
      - node/install:
          install-yarn: true
          node-version: '16.9.1'
      - run: echo -n $PLAY_STORE_SERVICE_ACCOUNT_KEY | base64 -d  > serviceAccountKey.json        
      - run:
          name: android build
          command: |
            mkdir android_sdk
            curl -O https://dl.google.com/android/repository/commandlinetools-linux-8512546_latest.zip
            unzip commandlinetools-linux-8512546_latest.zip
            mv cmdline-tools android_sdk
            mkdir -p android_sdk/cmdline-tools/tools
            mv -t android_sdk/cmdline-tools/tools android_sdk/cmdline-tools/lib android_sdk/cmdline-tools/bin android_sdk/cmdline-tools/source.properties android_sdk/cmdline-tools/NOTICE.txt
            export ANDROID_SDK_ROOT=$HOME/project/android_sdk
            yes | $ANDROID_SDK_ROOT/cmdline-tools/tools/bin/sdkmanager --licenses || if [[ $? -eq 141 ]]; then true; else exit $?; fi
            npm install -g expo-cli eas-cli
            npm ci
            eas build --profile << parameters.profile >> --platform android --clear-cache --local --non-interactive --output "${CIRCLE_BRANCH//\//-}-${PROFILE}-${CIRCLE_SHA1:0:7}.apk"

Build iOS using MacOS executor

  eas-build-ios:
    executor: ios
    parameters:
      profile: 
        description: eas profile
        type: string
        default: preview
    environment:
      PROFILE: << parameters.profile >>
    steps:
      - attach_workspace:
          at: ~/
      - node/install:
          install-yarn: true
          node-version: '16.9.1'
      - run:
          name: ios build
          command: |
            npm install -g expo-cli eas-cli
            npm ci
            eas build --profile << parameters.profile >> --platform ios --clear-cache --local --non-interactive --output "${CIRCLE_BRANCH//\//-}-${PROFILE}-${CIRCLE_SHA1:0:7}.ipa"

We are using CircleCI NodeJS Orbs to install NodeJS on the executors. For Android we pass in service account key from pipeline secret and need to download Command Line Tools too.

Overall the pipeline works quite well for us and we have significant improvements on development process. Now product manager/designer and manual QA could easily download the bundle and play with the app on either BrowserStack or our test physical devices.

• It is not modular and things are tightly coupled so teams are stepping on each other’s toes while developing on it
• The technology is outdated and we don’t have the expertise on continuous maintenance and development
• The application is poorly tested in general therefore we don’t feel safe to change the system. One simple change could result in bugs in other places we are not aware of.
• Various performance issues

The migration comes with the following challenges:

• We still need to keep the monolith running and serving our customers.
• We can’t afford a complete rewrite of the monolith as that would take ages.

Our team decided to follow Strangler Fig Pattern and gradually tear the monolith apart.

Here is how the entire migration process looks like:

In order for this to work we need to identify our bounded contexts/domains following domain-driven design. One useful way for this process would be Event Storming. The In this case Domain A would be represented in the diagram as Frontend Application A, Backend Microservice A and Database A, these will run inside ECS or EKS behind a Service Mesh.

We take what we need from the monolith by streaming change log from RDS read replica via AWS Data Migration Service to AWS MSK topic, which will give us Kafka events which look like the following:

{
  "topic": "<topic_name>",
  "partition": 3,
  "offset": 53870799,
  "tstype": "create",
  "ts": 1651268333902,
  "broker": 2,
  "key": "<partition_key>",
  "payload": "<the_actual_payload>",
  "_datetime": "2022-04-29T21:38:53Z",
  "_payload": {
    "data": {
      "id": 1,
      "createdOn": "2021-01-23T20:38:16Z",
      "modifiedOn": "2022-04-29T15:45:04Z",
      "version": 0,
      "firstName": "Foo 2",
      "lastName": "Bar 2"
    },
    "before": {
      "id": "1",
      "firstName": "Foo",
      "lastName": "Bar"
    },
    "metadata": {
      "timestamp": "2022-04-29T21:38:53.752816Z",
      "record-type": "data",
      "operation": "update",
      "partition-key-type": "primary-key",
      "schema-name": "<schema_name>",
      "table-name": "<table_name>",
      "transaction-id": 569130413019234
    }
  }
}

Since we are already on AWS we try to its services available. If you are not on AWS, then AWS Data Migration Service could be replaced with Debezium.

Then we create a CDC service transforming raw change event into domain event, this is acting as our ACL (Anti Corruption Layer).

From now on inside each microservice we have Kafka consumers to pick up the events and persist it into individual databases.

On Application Load Balance layer we will forward requests to either old monolith or new microservice frontend based on routing rules. If we are happy with the new microservice then we will deprecate things inside the monolith and make it smaller. Repeating the process would eventually allow us to split the monolith.

During the process monolith application would likely need the data from the new microservices, we can either follow the same approach to feed the data back. How kafka consumer interacts with monolith would depend on individual cases.

There will a lot of issues to resolve along the way but hopefully this will get us where we want to be in future.

Here are some important things to bear in mind during the migration process:

• Think about whether what you need is just modular monolith instead of microservices architecture.
• Keep minimal changes to the monolith.
• Start with the most independent domain.
• Follow Kafka best practices, e.g. make sure Kafka consumers are idempotent.
• Have faith that all these work will eventually be paid off as it will be a long journey.

Platform – These are services provided by mobile device builders (e.g. Apple, Google, Amazon) that transport the messages to the end devices. The Platforms offer device registration, app token creation and management, and the delivery channel for notifications to be delivered to devices. There are several different services that you can use to send push notifications to the users of your applications. The platform you use largely depends on which app store your customers use to obtain your app. The most common platforms are Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM), Baidu Cloud Push, and Amazon Device Messaging (ADM).

Provider – The Provider allows app registration and messaging to be coordinated by your mobile apps backend system, to allow for event or schedule based interactions from your backend with your mobile app. They typically utilise underlining mobile platforms to communicate with your mobile app. Examples are AWS SNS, AWS Pinpoint, OneSignal, Expo Push API, etc.

Client – This is the mobile application running on a physical device or simulator.

The overall architecture looks like the following:

As you can see from the diagram, your service/push trigger will talk to AWS SNS which uses FCM/APNs to push notifications to clients. Note that FCM could also push notifications to iOS devices according to their documentation, but underneath it is also using APNs which you still need to setup.

The first thing you need to do is to create a project in your chosen mobile platform, then use the project information to create a platform application in SNS. The push notification workflow using SNS is shown as below:

1. Your mobile app sets up secure connection with mobile platforms to register for app push notification and request a device and app specific device token
2. The platform returns the device token back to your mobile app
3. Your mobile app could pass the device token along with other information to your service
4. You service calls AWS SNS to set up an application endpoint using the device token and additional user data
5. SNS returns application endpoint response back to your service to save for future reference
6. When your service wants to push a notification, it will call SNS application endpoint with the message for the platform
7. SNS calls mobile platform to deliver the message
8. Mobile platform pushes the message to your mobile client

There are several react native mobile libraries you can use for step 1-2:

• If you are using Expo to create your mobile application, you can use their expo-notifications to receive notifications and call Notifications.getDevicePushTokenAsync() to retrieve native token instead of Expo token. At the time of writing, this approach does not work with Expo Go app and the apple environment is default to production. This library works best with Expo Push API so you might need to put in extra effort to set it up and it also requires physical device in both Apple and Android for push notification to work. One advantage of using this library is that you write in pure JavaScript without having to set up Android and iOS native code.
• If you are using reactive native, there are react-native-push-notification (Warning: No longer actively maintained) and react-native-notifications.

Note: Apple always requires physical devices for push notification while Android simulator could be used to test locally.

One important thing I found out through the research was that there are so many solutions out there and each of them gives you pros and cons. It is better to gather your requirements first then pick the one most suitable for you.