Disclaimers:

• This document is accurate at the time of writing. No future guarantee.
• I am no longer associated with this project. I do not represent any businesses or people herein. All writing and opinions are my own.

Overview

The client is a player in the alcohol sales industry with 10s of thousands of regular customers. We were tasked with building out an app for Android and iOS devices.

My role on this project was as the lead engineer and architect. I chose the technologies and lead the implementation.

Technologies

The app was written in React Native for both the Android and iOS side, utilizing Expo for hardware integrations such as QR scanning. The API used Hasura with Postgres.

The reason we used React Native was because our team had expertise in React technologies and could work with it at higher velocity than Swift and/or Kotlin. Also, we eventually planned to port the app to the web, and in doing so would greatly benefit from already having used React. Finally, some members on our team already had prior experience with React Native.

The reason we used Hasura was because our team wanted a low-effort backend which required little to no coding, since our allocation was going to be heavily concentrated on the app to meet our aggressive timelines. Alternatives we considered included Firestore. However, Hasura had special appeal in its ability to handle webhooks and external requests, as well as the fact that it used Postgres–a database which we had already used for previous projects–which enabled easy migrations if needed in the future, and of course the integration of GraphQL which enables easy expansion with other APIs as needed. Finally, a nice side-benefit was that it gave us an opportunity to try this relatively new technology to see if we wanted to use it for future projects.

We wanted to keep the backend deployment simple as well. For the MVP, we chose not to allocate resources to any kind of deployment automation. For scaling, we simply calculated the machine necessary to handle our maximum expected load. This was done by running the machine locally and then stress-testing it with Vegeta, measuring the resource use under a heavily-populated database with hundreds of thousands of rows generated automatically by Navicat.

Hasura was then deployed in a simple AWS EC2 instance (slightly favoring memory over CPU) which was open to the public with a Caddy server. All updates (except environment updates) were then done with the Hasura CLI.

Outcome

The application happily stood up to the load of a few thousand users per day from day one. The initial launch had a couple of bugs which were quickly caught and updated, and fewer than 1% of users experienced any crashes or critical errors. In my opinion from an engineering perspective, our implementation was professionally executed and can be considered a success.

React Native and Hasura are fine technologies to utilize for production purposes and were the correct decision here. Hasura has some edge-case limitations (for example) which may require minor workarounds, but otherwise worked perfectly for us!

For more specifics, please feel free to reach out to me at my email! hello@wyatt.engineer