Spring 2018

Beam is a fintech company making an improved online banking system offering 2-4% APY. We built a web administration dashboard with TypeScript and React on the frontend and GraphQL on the backend.



Introduction
Beam Financial is a mobile-first online banking platform that offers 2-4% APY on your assets stored in their system. Through the Beam app, users can invite their friends to gain daily interest rate rewards, called Billies. The platform is zero-fees, no interest rate, and FDIC insured.
Problem Statement
During our working period with Beam, their lean engineering team was fully focused on the initial launch of their application to the iOS App Store. Many of the backend and database systems were in place, but the engineers had no easy way to query for and visualize their data.

Our job was to build, from scratch, an internal facing administration dashboard for various Beam data. This included a standardized table view of Customers, Transactions, Interest Rates, etc. as well as visualizations and core metrics for Beam to track their performance over time. We were to own this project from end-to-end - everything from initial Google OAuth authentication to deploying the application on their Heroku instances.
Implementation
The implementation of the project happened in 2 pieces. The first of which was a frontend in React.js and TypeScript that queried data from our backend to display in various formats and communicated with AWS Cognito and Google OAuth for user authentication. The second was our GraphQL backend layer, built on top of Beam’s own Postgres databases. We implemented a one-to-one GraphQL mapping with Postgres, implemented our own custom endpoints, and also ran daily CRON jobs for aggregation metrics.
Technical Challenges
Once we moved our development process in to Beam’s QA database, we became painfully aware that many of our data operations could not be handled on the client side. This meant ripping out much of our frontend code, and implementing, among other things, server-side data pagination, server-side data sorting, and server-side fuzzy search. These technical challenges, combined with our relative unfamiliarity with GraphQL, proved to be a time-consuming roadblock.

The authentication flow in our application resulted in quite a bit of churn in our application. We were trying to integrate AWS Cognito, Google OAuth 2.0, and both our React application and backend GraphQL servers all into one seamless workflow. Our users were to hit a Google sign in link on our React application, have it be okayed by Google OAuth, redirect to AWS Cognito, quickly confirm with our GraphQL layer, swing back to AWS Cognito, and then finally confirm with our React frontend. There was no simple fix for this and we had to get our hands dirty with each request in the pipeline.
Key Takeaways
In retrospect, there were still a couple pieces of the project specification that were not clear, and we ran into some trouble near the end of the project trying to clarify expectations. Beam did not provide a dedicated designer on the application and we should have allocated more design resources, on our end, towards the project.

Everyone on the team still learned a lot from the experience. It’s not often a team gets to own the entire life of an application from end-to-end like we did. Building a web application with concretely definable tasks allowed us to focus on operations, coding practices, and teamwork. Our final application was running on real Beam data and offered real, tangible insights for Beam employees.