Six Months Ahead of the Curve: Betting on GraphQL and React Native Web in 2018

In May 2018, I walked into a non-technical company with a problem: their entire digital product was built and maintained by outside contractors, running on ColdFusion. ColdFusion. That was… a choice. Not one I agreed with, but a choice nonetheless.

They hired me to bring digital knowledge in-house and figure out what came next. I evaluated the existing platform, realized it needed to go, and started thinking about what a modern, maintainable platform should actually look like. We had a baseline of known functionality to rebuild, but that wasn’t enough — the current app had terrible adoption and mediocre design. People barely used it beyond the directory feature. Simply rebuilding what existed would be a waste of everyone’s time.

Building the Team and Setting Direction

I knew the team would be small for a long time. Turns out, it was three engineers for two full years. To minimize context switching and maximize velocity, I made a call: TypeScript front-to-back. One language, less cognitive load, more shipping.

Then came the harder decisions — the ones that would define whether this thing succeeded or cratered.

The Architecture: Betting Early on Unproven Tech

I started by learning the data architecture, which lived primarily in Salesforce. I identified weak points and designed around them, promoting several fields into first-class data citizens for better relational handling. The data model needed to be generic and flexible enough to support anything we’d want to build — not just what we knew about today, but what might come years down the road.

For the API layer, I chose GraphQL. REST is fine, but I’d versioned enough REST APIs over the years to know I wanted a different path. GraphQL was still fairly new in 2018 — mostly Facebook and a handful of early adopters. It was risky, but it looked promising, and I was willing to bet on it. Six years later, I’m still happy with that call.

On the frontend, we knew we’d need mobile apps eventually, so React Native was the obvious choice. But here’s where it got interesting: I also chose React Native Web for our web presence. This was way before Expo went down that road. At the time, React Native Web had basically one real-world user: the mobile version of Twitter. That’s it. We were building a unified codebase to serve web, iOS, and Android from a single source — and doing it with tech that barely existed yet.

The ORM Decision: Pragmatism Over Idealism

We wanted to use Prisma for our ORM. We’d played with it and really liked its simplicity — it seemed to flow better with our GraphQL + PostgreSQL setup. But Prisma didn’t have migrations yet. The version with a robust migration system was in beta, and we weren’t about to bet our data layer on beta software. We evaluated a couple of alternatives and quickly landed on TypeORM as our best option.

Part of the reason we wanted an ORM in the first place was that most of the dev team weren’t super comfortable deep in SQL. Plenty of developers aren’t — they work with ORMs or have dedicated DBAs to handle the hard stuff. The joke I made at the time, riffing on Office Space, was “the ORM talks to the database so the engineers don’t have to!”

TypeORM started out promising. I came from a Ruby on Rails and ActiveRecord background, and at first, it felt very similar. Until it didn’t. We found ourselves having to work around the ORM instead of working with it. Some features, like eager loading, have been great. Others, like complex filtered queries, have been a fight. We’ve run into migration system bugs, Postgres features that TypeORM doesn’t support, and quirks where certain query setups return unexpected results.

At this point, after years of working with it, I’d rather just write SQL queries directly — it’s second nature now. That said, TypeORM does do a very good job of sanitizing inputs to prevent SQL injection attacks, which is a genuinely valuable freebie. Would I choose it again? Probably not. But it was the pragmatic choice at the time, and we made it work. Sometimes that’s what building software is: making the best call you can with what’s available, then dealing with the consequences.

The Reality of Non-Technical Stakeholders

There was definite hesitation internally. We had a non-technical company that didn’t understand what it would take or why we wanted to start from scratch. They trusted us — more or less — but they didn’t get it. They couldn’t give meaningful feedback on designs or ideas until they had something tangible to see and touch. It made things harder, but we eventually won them over with the finished product.

The key to getting adoption where the old platform failed wasn’t just technology — it was presentation and reach. We redesigned how information was displayed, made posts and replies actually usable, expanded who could communicate with whom, improved visual fidelity, and added features that made the platform engaging instead of just functional. People went from “I only use this as a directory” to actually using the platform.

Going Live: GCP Over AWS

When it was time to deploy, we chose Google Cloud Platform over AWS. AWS is powerful, sure, but it’s also complicated. It felt like we’d all need certifications just to understand how to make it hum. GCP had great documentation and an “it just works” vibe. With a team of three people building an entire platform under a time crunch, we didn’t have bandwidth for AWS’s complexity. GCP was the pragmatic choice, and it’s worked out well.

We split our backend into a semi-monolith for the primary API (deployed to App Engine Flex for the extra memory), then carved out microservices for background tasks, notifications, and ETL processes. Most of it runs in App Engine Standard environments. It’s been humming along for six years now, with adjustments for speed and efficiency as needed.

Six Years Later: What Held Up

Looking back, the thing I’m most proud of is the data architecture and GraphQL. They’ve both firmly withstood the test of time. We’ve pivoted several systems to broaden them based on business decisions, and the data model just rolled with it. I made it highly flexible on purpose, and that paid off in spades. Six years later, the data model remains largely unchanged. The changes that have happened have either been entirely new systems or minor tweaks to existing ones.

Here’s the thing about this project: we found ourselves perpetually about six months ahead of the curve. GraphQL was still fairly new. React Native Web had basically just Twitter on it. We were constantly betting on tech that wasn’t proven yet, with a tiny team, under time pressure, for stakeholders who needed to see it to believe it.

And it worked.

Sometimes the biggest risk is staying safe. Choosing proven tech is comfortable, but it can lock you into patterns that don’t serve the actual problem. We bet early, we bet smart, and we built something that’s still running strong six years later — with a data model flexible enough to adapt to business pivots we couldn’t have imagined in 2018.

Need someone to make the tough architectural calls for your platform? Let’s talk - I’ve been doing this for over 25 years.