API Architecture Comparison for Personal Projects
When I first started personal development, I assumed the app could be mostly self-contained.
However, as requirements such as data sharing, user authentication, and multi-app expansion grew,
it became necessary to select a proper backend (API) and serverless infrastructure.
After evaluating multiple setups — including Swift-only, Firebase, FastAPI, direct Supabase access, and Next.js —
I ultimately concluded that React Native × Hono × Cloudflare Workers × Supabase was the optimal architecture.
This article objectively summarizes the characteristics of each option and explains the technical reasons for adoption or rejection.
1. Selection Criteria
The API architecture was evaluated based on the following requirements.
Functional Requirements
- APIs usable from both iOS and Android
- Support for guest users and authenticated users
- Persistent data storage (RDB required)
- A shared API used by multiple small applications
Non-Functional Requirements
- Affordable for long-term personal development
- Protection against unauthorized access at the API level
- Scalability toward multi-tenant / SaaS use
- Low operational and maintenance overhead
- Preference for a serverless architecture
2. Evaluated Architectures
Each candidate architecture is reviewed below, along with an assessment of how well it meets the requirements.
2-1. Swift (iOS Only)
Overview
A native iOS app built using Swift only, with data stored locally.
Evaluation
Pros
- Fast UI development
- High performance due to native execution
Cons (Requirement Mismatch)
- No Android support → fails cross-platform requirement
- Cannot include RDB or API layer → fails data-sharing requirement
- Relying solely on app-side security is inappropriate
→ Rejected due to unmet requirements
2-2. Swift + Firebase
Overview
Uses Firebase Authentication and Firestore as the backend.
Evaluation
Pros
- Low learning curve
- Fast development with SDK integration
Cons (Data Requirement Mismatch)
- No Android support
- Firestore does not satisfy RDB requirements (joins and normalization are difficult)
- Security rules become complex and fragile at scale
→ Rejected due to RDB and scalability constraints
2-3. React Native + Firebase
Overview
A cross-platform React Native app connected directly to Firebase Authentication and Firestore.
Evaluation
Pros
- Cross-platform support
- Very fast development speed
Cons (API Requirement Mismatch)
- Firestore does not meet RDB requirements
- Direct client access prevents building a proper API logic layer
- Audit logs, signatures, and advanced security logic cannot be enforced server-side
→ Rejected due to insufficient security architecture
2-4. React Native + FastAPI + AWS
Overview
FastAPI (Python) used as the API layer, with AWS services such as RDS, Lambda, and VPC.
Evaluation
Pros
- Enterprise-grade security design
- Highly flexible business logic
- Broad database options (PostgreSQL, MySQL, Aurora)
Cons (Cost Mismatch)
- Overkill for personal development once RDS, VPC, and monitoring are included
- High operational cost and fixed expenses
- Even serverless setups accumulate costs via API Gateway and CloudWatch
→ Rejected due to poor cost-performance balance
2-5. React Native + Supabase (Direct Client Access)
Overview
React Native connects directly to Supabase (PostgreSQL + RLS).
Evaluation
Pros
- Full RDB support
- Basic security via Row Level Security (RLS)
Cons (No Server Layer)
- No API layer to implement business logic
- Risky secret management on the client side
- Insufficient as a shared backend for multiple applications
→ Rejected due to security and architectural limitations
2-6. React Native + Next.js (Vercel) + Supabase
Overview
API built using Next.js API Routes and Vercel Edge with KV caching.
Evaluation
Pros
- Fast responses with Edge Runtime
- Easy KV-based caching
- Seamless integration of web and API
Cons (Cost and Purpose Mismatch)
- SSR / RSC billing can quickly exhaust free tiers
- Limited benefit when using Next.js purely as an API
- Less cost-efficient for API-focused workloads compared to Workers
→ Rejected due to cost efficiency concerns
2-7. React Native + Hono + Cloudflare Workers + Supabase (Final Choice)
Overview
Hono runs on Cloudflare Workers as the API layer.
Supabase (PostgreSQL + RLS) is used as the primary datastore, with Workers KV for caching.
Reasons for Adoption
1. Meets Security Requirements
- JWT verification, request signing, and rate limiting at the API layer
- Defense in depth with Supabase RLS
- Cloudflare WAF can be placed in front
- No need to distribute Supabase anon keys to clients
2. Low Cost
- Workers remain free under ~100k requests/month
- KV and caching reduce Supabase query volume
- Zero fixed operational cost
3. High Scalability
- API modularization suitable for multi-app expansion
- Hono provides Express-like ergonomics with high performance
- Serverless scaling removes infrastructure concerns
4. High Development Efficiency
- Workers + Hono are optimized for API-only use
- Simple middleware composition
- Smooth integration with Supabase
→ Adopted as it best satisfies both technical and non-functional requirements
3. Architecture Diagram
[ React Native App ]
|
HTTPS
|
[ Cloudflare Workers (Hono API) ]
|
+--> JWT Verify -----> [ Supabase Auth ]
|
+--> SQL + RLS ------> [ Supabase PostgreSQL ]
|
+--> Rate Limit -----> [ Workers KV ]
4. Comparison Table
Security, cost, and scalability are subjective evaluations based on this project’s assumptions.
| Architecture | RDB | Security | Cost | API Extensibility | Overall |
|---|---|---|---|---|---|
| Swift | × | Low | Low | Low | Rejected |
| Swift + Firebase | × | Medium | Low | Low | Rejected |
| RN + Firebase | × | Medium | Low | Medium | Rejected |
| RN + FastAPI + AWS | ○ | High | High | High | Rejected |
| RN + Supabase (Direct) | ○ | Medium | Low | Low | Rejected |
| RN + Next.js + Vercel | ○ | Medium | Medium | Medium | Rejected |
| RN + Hono + Workers + Supabase | ○ | High | Very Low | High | Adopted |
5. Summary
This article compared multiple API architectures for a personal development project,
evaluating each option against functional and non-functional requirements.
The final choice — React Native × Cloudflare Workers × Hono × Supabase — stood out for:
- Strong API-level security controls
- Reliable RDB support with Supabase and RLS
- Excellent cost efficiency via Cloudflare Workers
- Flexible serverless scaling
- A structure well-suited for multi-app expansion
Top comments (0)