Comparing API Architecture Choices: A Technical Evaluation of Six Setups Tested in Personal Development

Source: Dev.to

Overview

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.

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

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

Result: → Rejected due to unmet requirements

2‑2. Swift + Firebase

Overview
Uses Firebase Authentication and Firestore as the backend.

Evaluation

Result: → 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

Result: → 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

Result: → 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

Result: → 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

Result: → 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 ~100 k 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

Result: → Adopted as it best satisfies both technical and non‑functional requirements

Architecture Diagram

[ React Native App ]  [ Cloudflare Workers (Hono) ]  [ Supabase (PostgreSQL + RLS) ]
                                   |
                                   v
                               [ Workers KV (cache) ]

Detailed Diagram

        |
      HTTPS
        |
[ Cloudflare Workers (Hono API) ]
        |
        +--> JWT Verify -----> [ Supabase Auth ]
        |
        +--> SQL + RLS ------> [ Supabase PostgreSQL ]
        |
        +--> Rate Limit -----> [ Workers KV ]

Comparison Table

Security, cost, and scalability are subjective evaluations based on this project’s assumptions.

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 relational‑database support with Supabase and Row‑Level Security (RLS)
• Excellent cost efficiency via Cloudflare Workers
• Flexible serverless scaling
• A structure well‑suited for multi‑app expansion.