This article is a companion piece to my earlier post:
While that article focused on technical pros and cons,
this one documents my personal decision-making process:
how I chose certain architectures, why I abandoned others,
where I hit walls, and what I learned along the way.
Rather than listing abstract reasons, this article focuses on:
- how my understanding evolved,
- where I got stuck,
- and why I changed direction at each stage.
1. Early Stage: I Didn’t Even Think About APIs or Backends
The first thing I tried to build was a small shopping list app.
At that point, I didn’t think an API or server was necessary at all.
My assumptions were simple:
- It only needs to work on an iPhone
- Local storage should be enough
- The priority is to build screens and make something visible
- Backend systems feel optional
With that mindset, I started development assuming a Swift-only, standalone app.
2. First Turning Point: I Didn’t Know How to Share Data
A few days into development, a new requirement appeared:
“I want to share the shopping list with my family.”
At that moment, it became obvious that local storage alone wouldn’t work.
That’s when I first thought:
“Maybe I need a database.”
However, my knowledge of APIs and backend systems was very limited.
In my day job, I had only worked with on-premise systems,
and I barely understood the concept of serverless architectures.
3. Trying Firebase — and Starting to See Its Limits
While researching databases for Swift, Firebase was the first option I encountered.
It was easy to set up, came with authentication, and looked very beginner-friendly.
But as the app idea evolved, several problems became clear.
Firestore (NoSQL) Didn’t Match My Requirements
For features like:
- group-based data sharing,
- managing multiple lists,
- permission control,
- frequently updated records,
a relational database felt much more appropriate.
Firebase was convenient, but it didn’t align with:
- an RDB-centered design,
- or my mental model for future expansion.
4. Moving from Swift to React Native: A Change in Assumptions
Initially, I was building only for iOS.
Later, I realized that React Native would allow Android support as well.
I switched from Swift to React Native.
This unified the frontend, but also made one requirement unavoidable:
“I need a proper relational database.”
At this stage, it became clear that I had to design a system
that could reliably connect to an RDB.
5. Discovering Supabase and Serverless RDBs
Around the time I felt Firebase wasn’t a good fit,
I discovered Supabase and learned that PostgreSQL could be used in a serverless way.
What stood out was:
- Serverless-friendly architecture
- PostgreSQL, which I was already familiar with
- Built-in Row Level Security (RLS)
- A generous free tier
Being able to use an RDB at low cost was very appealing for personal development.
6. Realizing the Limits of Direct Supabase Access
At first, I connected React Native directly to Supabase.
But once I started using it seriously, several issues surfaced.
No API Layer
Business logic and shared processing couldn’t live on the server.
As a result, complexity accumulated on the client side.
Security Design Was Hard
I initially embedded the Supabase anon key directly in the app.
This setup itself is not inherently wrong,
but with my level of knowledge, managing keys and security
without a backend layer felt risky.
The Need for a Shared Backend Emerged
As I started thinking about multiple apps,
I realized that direct client access would not scale well.
Supabase itself was great,
but a direct-connection architecture had clear limits.
7. Considering FastAPI + AWS — and Facing Cost Reality
Wanting a proper API foundation,
I started considering FastAPI + AWS.
What I initially imagined was a fairly “enterprise-style” setup:
- API Gateway or ALB
- FastAPI running on EC2 or containers
- RDS (PostgreSQL) or Aurora Serverless v2
- A private VPC-based architecture
As I researched further, one issue became obvious.
The Running Cost Would Be Too High
AWS can be inexpensive if you use:
- API Gateway
- Lambda
- DynamoDB
But my mental model was:
- always-on RDBs,
- VPC networking,
- monitoring and production-grade setups.
For a small personal project,
this felt too close to enterprise infrastructure.
From this point on, cost awareness became a major decision factor.
8. Trying Next.js API Routes — and Letting Them Go
While looking for a lower-cost alternative,
I found Vercel and Next.js API Routes.
At first, this seemed perfect:
- JavaScript-based API development
- Easy Git and Supabase integration
- Simple deployment
I moved forward with this approach,
but soon encountered problems.
- SSR / RSC billing was hard to avoid
- My expected traffic and usage pattern would exhaust free tiers quickly
I also realized that Next.js works best
when frontend and API are tightly integrated,
which didn’t match my goal of an API-focused backend.
At this point, the conclusion was clear:
“I need an API platform that is API-only by design.”
9. Discovering Cloudflare Workers — Everything Clicked
When I started exploring Cloudflare Workers,
it immediately felt like a good fit.
- Large free tier
- Extremely low latency
- Fully serverless, no maintenance
- KV and Durable Objects available
- Hono looked lightweight and expressive
- Easy integration with Supabase
Problems that had been scattered across previous architectures
suddenly felt unified.
10. Adopting Workers × Hono — Finally a Coherent System
Once I moved the API layer to Workers × Hono,
multiple issues were resolved at once.
Centralized API Logic
Signing, logging, validation, and rate limiting
could all live in the API layer,
making both security and operations easier to reason about.
No Need to Distribute anon Keys to Clients
This was the biggest turning point.
Defense in Depth with Supabase RLS
Combining API-level checks with RLS
gave me confidence in the security model.
Scaling and Cost Were No Longer Concerns
This finally felt like an architecture
designed for personal development.
Although Hono requires more manual implementation,
my experience maintaining custom frameworks at work
made this manageable.
At this point, I concluded that:
React Native × Cloudflare Workers × Hono × Supabase
was the best solution for my needs.
11. Reflections on the Decision Process
The final architecture wasn’t obvious from the start.
It emerged through repeated trial, failure, and adjustment.
Looking back, several lessons stand out:
- I didn’t even understand the need for APIs at first
- Firebase is convenient, but has clear long-term limits
- Supabase is powerful, but needs an API layer
- AWS is excellent, but often overkill for personal projects
- Cloudflare Workers align extremely well with personal development needs
12. Relationship to the Comparison Article
This article documents how I thought and why I decided,
based on hands-on experience.
For a more objective, technical comparison,
see the related article here:
Final Thoughts
I’ve now settled on a stack built around:
React Native × Cloudflare Workers × Hono × Supabase
Going forward, I plan to use this API foundation
to support multiple small applications.
This article records one part of that journey.
If you have suggestions or alternative approaches,
I’d love to hear them in the comments.
Update
A demo API based on this architecture is now available:
https://github.com/umemura-dev/hono-supabase-auth-security-demo
Top comments (0)