DEV Community: Khue Pham

The Hotel Upgrade Hack: Mass Assignment Vulnerabilities in APIs

Khue Pham — Sun, 12 Jul 2026 07:16:24 +0000

The hotel check-in trick

Imagine you walk up to a hotel front desk, pick up the paper check-in form, and fill it in normally: your name, check-in date, number of guests, room type: Standard. But before you slide it back across the counter, you quietly pencil in one more line — room type: Presidential Suite. The receptionist types every field into the system without a second glance. You just upgraded yourself for free.

That is Mass Assignment. And developers reproduce this exact vulnerability in API code every single day, usually without realising it.

What is Mass Assignment?

Mass Assignment happens when a server takes user-supplied data and binds it directly to an internal model, without filtering which fields the user is actually allowed to set.

In a Rails-flavoured example it looks like this:

# Dangerous — creates a user from whatever the client sends
User.create(params)

In Node.js / TypeScript land it is just as easy to write:

// Dangerous
const user = await db.insert(users).values(req.body);

// Also dangerous
Object.assign(existingUser, req.body);

Now suppose your users table has columns like email, name, passwordHash, isAdmin, and role. A normal user submitting a sign-up form sends:

{ "email": "attacker@example.com", "name": "Attacker", "password": "hunter2" }

An attacker submitting the same endpoint sends:

{ "email": "attacker@example.com", "name": "Attacker", "password": "hunter2", "isAdmin": true, "role": "superuser" }

If the server binds req.body directly, both requests succeed. The attacker now has an admin account. No password cracking, no token theft, no exploiting a cryptographic weakness — just one extra JSON key.

The GitHub 2012 incident

In March 2012, security researcher Egor Homakov exploited a Mass Assignment vulnerability in GitHub and added himself as a member of the rails/rails organisation — the official GitHub repository for Ruby on Rails — without any invitation or admin approval. He did this by injecting organization_id (and related fields) into a form POST that was meant only for updating his own profile.

GitHub suspended his account initially, then reinstated it and acknowledged the bug. The vulnerability was OWASP-known at the time; it simply hadn't been plugged.

The incident was a watershed moment for the Rails community. Mass Assignment had been called out before, but this was the first time it was demonstrated publicly against a flagship open-source project with millions of followers. Rails subsequently introduced strong_parameters to force developers to whitelist fields explicitly.

Why Mass Assignment is particularly dangerous

Privilege escalation. The most direct impact: an attacker sets isAdmin: true, role: "admin", subscriptionTier: "enterprise". No brute force needed.

Data corruption. If createdAt, updatedAt, or audit fields can be overwritten, you lose tamper-evident logging. Compliance audits break down. Forensics become unreliable.

Multi-tenancy bypass. This is the one that keeps me up at night. In a multi-tenant system every domain record carries a siteId. If an attacker can inject siteId into a create or update payload, they can write data into another tenant's namespace, or re-parent their own records to escape rate limits and quotas scoped to their tenant.

Subtle escalation paths. Sometimes the dangerous field isn't isAdmin. It's planId, ownerId, verifiedAt, emailVerified, or stripeCustomerId. Attackers probe every field in a response body and try to send each one back in the next write request. Any field that sticks is a potential attack surface.

Where Lumibase is exposed

Lumibase is a Content OS — a headless CMS that accepts writes from multiple surfaces simultaneously: the Studio editor UI, AI skill output piped through the agent harness, incoming webhooks from external platforms, and third-party extension callbacks. Every one of those surfaces eventually calls the same Hono route handlers and lands in the same service layer.

The schema for a content item looks roughly like this (simplified):

// packages/database/src/schema/items.ts
export const items = pgTable('items', {
  id: text('id').primaryKey(),
  siteId: text('site_id').notNull(),           // tenant boundary
  collectionId: text('collection_id').notNull(),
  data: jsonb('data').notNull(),
  status: text('status').notNull().default('draft'),
  createdBy: text('created_by').notNull(),
  createdAt: timestamp('created_at').notNull().defaultNow(),
  updatedAt: timestamp('updated_at').notNull().defaultNow(),
  publishedAt: timestamp('published_at'),
});

If a route handler did something naive like this:

// apps/cms/src/routes/items.ts — BAD example, do not do this
app.post('/items', async (c) => {
  const body = await c.req.json();
  const item = await itemService.create({ ...body, siteId: c.get('tenant').siteId });
  return c.json({ data: item });
});

An attacker could include createdBy, publishedAt, or status: "published" in the body, skipping the review workflow entirely. Worse, if the spread order were reversed, they could overwrite siteId itself.

Fix layer 1: Zod strips unknown keys at the boundary

The first and most important line of defence is to never let raw req.body touch business logic. Parse every incoming request through a Zod schema, and let Zod strip fields the schema doesn't declare.

// packages/shared/src/schemas/items.ts
import { z } from 'zod';

export const createItemSchema = z.object({
  collectionId: z.string().min(1),
  data: z.record(z.unknown()),
  status: z.enum(['draft', 'review']).default('draft'),
  // Notice: no siteId, no createdBy, no publishedAt, no id
});

export type CreateItemInput = z.infer<typeof createItemSchema>;

By default, z.object() strips unknown keys when it parses (.parse() drops them; .strict() would throw instead). Either way the poisoned fields never make it through.

// apps/cms/src/routes/items.ts
import { createItemSchema } from '@lumibase/shared/schemas/items';

app.post('/items', async (c) => {
  const raw = await c.req.json();

  // parse() drops any key not declared in createItemSchema
  const input = createItemSchema.parse(raw);
  // input is now typed as CreateItemInput — no isAdmin, no siteId, no createdBy

  const item = await itemService.createItem(c.get('tenant').siteId, c.get('user').id, input);
  return c.json({ data: item });
});

siteId and createdBy are injected from the verified middleware context — not from the request body. The client never gets to supply them.

Fix layer 2: Typed DTOs in the service layer

Zod at the boundary is excellent, but defence in depth means the service layer should also be structurally incapable of accepting unsafe inputs. The pattern is to define a strict DTO type and have every service function accept only that type.

// apps/cms/src/services/item-service.ts
import type { CreateItemInput } from '@lumibase/shared/schemas/items';
import { nanoid } from 'nanoid';
import { items } from '@lumibase/database/schema';

export class ItemService {
  async createItem(
    siteId: string,
    createdBy: string,
    dto: CreateItemInput,          // only the fields Zod already validated
  ) {
    const now = new Date();
    const record = {
      id: nanoid(),
      siteId,                      // from verified tenant context, not dto
      createdBy,                   // from verified auth context, not dto
      collectionId: dto.collectionId,
      data: dto.data,
      status: dto.status,
      createdAt: now,
      updatedAt: now,
      publishedAt: null,           // only set by publish workflow, never by create
    };

    const [inserted] = await this.db.insert(items).values(record).returning();
    return inserted;
  }
}

The function signature makes the contract machine-checkable: TypeScript will refuse to compile if you accidentally pass something that has isAdmin or siteId on it and try to spread it into record. The type system becomes an automatic audit.

Fix layer 3: Readonly fields — never let user-supplied data touch system fields

Some fields should be immutable after creation, or only writable by internal system processes. The cleanest way to express this in a Drizzle + TypeScript stack is to never include those columns in any user-facing DTO and to always set them programmatically.

// Readonly fields checklist for every entity:
// id           → nanoid() at creation, never updatable
// siteId       → from tenant middleware, never from body
// createdBy    → from auth middleware, never from body
// createdAt    → DB default, never from body
// updatedAt    → set by service on every write, never from body
// publishedAt  → set only by the publish workflow, never by generic update
// auditFields  → written only by the audit module

For updates, define a separate schema that only allows the fields that genuinely should change:

export const updateItemSchema = z.object({
  data: z.record(z.unknown()).optional(),
  status: z.enum(['draft', 'review']).optional(),
  // collectionId is also omitted — you can't move items between collections via a plain update
});

export type UpdateItemInput = z.infer<typeof updateItemSchema>;

Attempting to pass { siteId: "other-tenant", publishedAt: "2020-01-01" } to an endpoint that parses through updateItemSchema will silently drop both fields before the service ever sees them.

Whitelist, never blacklist

The instinct when you first learn about Mass Assignment is to write a blacklist:

// Tempting but wrong
const { isAdmin, role, siteId, createdBy, ...safeBody } = req.body;
await db.insert(users).values(safeBody);

This breaks the moment you add a new sensitive column and forget to add it to the destructuring. You are playing catch-up with your own schema.

The whitelist approach flips the default: only explicitly declared fields pass through. Adding a new sensitive column to your database has zero impact on the attack surface because it was never in the allowlist to begin with.

One extra field in a JSON body should not hand someone a Presidential Suite. Or admin access. Or a ticket into another tenant's data. The framework's convenience — req.body, Object.assign, spread operators — is exactly what makes this vulnerability so pervasive. Comfortable patterns are the ones that hide the worst assumptions.

Wrapping up

Three layers working together: Zod parses and strips at the HTTP boundary, typed DTOs constrain what the service can receive, and system fields are never in the DTO at all. Each layer catches what the previous one might miss. Any one of them alone is useful; all three together make Mass Assignment effectively impossible to sneak through.

I'm building Lumibase — a Content OS designed for AI agents operating at the edge. Security is structural from day one: multi-tenant isolation, typed service contracts, and strict schema validation at every entry point — whether the write comes from a human editor, an AI skill, a webhook, or an extension. If that sounds interesting, come take a look at lumibase.dev 🌱

The Key That Unlocks Everything: Prototype Pollution in JavaScript

Khue Pham — Sat, 11 Jul 2026 18:26:13 +0000

Imagine a hotel where every room key is cut from a master template. When a guest checks in, the front desk hands them a key that opens only their room. Simple enough. Now imagine a guest who, during check-in, sneaks a tiny modification into the key-cutting machine itself — changing the template so that every new key cut from that moment on also opens the manager's office, the safe, and the server room.

The guest didn't break a lock. They didn't clone anyone's key. They changed the factory that makes all keys.

That factory is JavaScript's Object.prototype. And the attack is called Prototype Pollution.

The Labor Illusion: Why Making Users Wait Can Build More Trust

Khue Pham — Tue, 07 Jul 2026 18:09:31 +0000

Here is a counterintuitive idea from behavioral psychology that quietly runs a lot of the software you use every day: the labor illusion. The core finding is that people tend to trust and value a product more when they can see the effort that went into producing it — even when the final result is exactly the same.

The flight-search story

The classic example is travel search sites like Kayak or Skyscanner. Early on, they could return flight results almost instantly. You'd expect users to love that. Instead, many of them were suspicious: if it's that fast, how could it possibly have found me the cheapest fare?

So the teams did something that sounds absurd on paper — they deliberately slowed the system down. They added a progress bar and a stream of status lines: "searching Delta…", "comparing prices across 200 airlines…", "checking baggage fees…". The actual work hadn't changed, but now users could watch it happen.

The result? People waited longer and yet booked more. Seeing the system visibly grind away on their behalf made them trust the answer.

Why it works

Waiting with no feedback feels like being ignored. Waiting while watching concrete, legible work feels like being served. The perceived value of an outcome isn't just the outcome — it's the outcome plus the visible evidence of the effort behind it. Strip away that evidence and, paradoxically, the same result feels cheaper and less trustworthy.

There's a flip side worth naming: this is a tool, not a trick to abuse. Fake delays that don't map to real work erode trust the moment users catch on. The honest version of the labor illusion is exposing work that is genuinely happening — not inventing work that isn't.

How I'm applying it to Lumibase

Building lumibase.dev, I kept running into moments where the honest version of this principle fits perfectly. When you hit deploy or sync, plenty is actually happening under the hood — validating config, running migrations, warming caches, spinning up the database. The old default was to hide all of that behind a spinner: a bored little circle going round and round while the user wonders whether anything is working at all.

So instead of the spinner, Lumibase surfaces a live terminal-style log that lists each real task as it runs:

▸ validating config…            ✓
▸ initializing database…        ✓
▸ applying migrations (3)…      ✓
▸ warming edge cache…           ⋯

The operation takes the same amount of time it always did. Nothing is faked — every line maps to a step that's really executing. But by exposing the process instead of hiding it, the wait stops feeling like dead air and starts feeling like the system working hard for you. Users come away calmer and more confident, because they can feel the value behind every click.

The takeaway

Progress is not just a technical state; it's a story you tell the user about their time. If real work is happening, show it. A legible process turns an anxious wait into evidence of effort — and evidence of effort is one of the cheapest, most honest ways to earn trust.

I'm building all of this in public. Lumibase is a Content OS — a headless, AI-native CMS operated by governed agents. If you like this kind of UX-meets-engineering thinking, come hang out at lumibase.dev. 🌱

The Server That Robs Itself: How We Shut Down SSRF in LumiBase

Khue Pham — Mon, 06 Jul 2026 08:45:00 +0000

Imagine your company has a courier everyone trusts completely. You hand him an address, he drives there, picks up the package, and brings it back — no questions asked. Most of the time customers give him a normal street address, so everything is fine. Then one day a con artist hands him an address that points inside your own building — straight to the vault where every key and password is kept. The courier, being helpful, walks in, grabs the contents, and cheerfully hands them to the con artist, never realizing he just helped rob the place.

That courier is your server. That con artist is an attacker. And that little heist has a name: Server-Side Request Forgery (SSRF) — CWE-918.

This is the story of how Lumibase closed that door.

What SSRF actually is

Lots of applications need to fetch a URL on the user's behalf: importing an image from a link, verifying a webhook endpoint, rendering a link preview, pulling a remote config. The user provides a URL, and the server makes the request.

SSRF happens when an attacker supplies a URL that points somewhere they shouldn't be able to reach — and the server, which usually lives inside the trusted network, dutifully makes the request for them. The attacker never touches the internal network directly; they borrow the server's privileges, and the firewall waves the request through because it came from a machine it trusts.

The classic targets:

Internal services that are only reachable from inside the network (admin panels, databases, dashboards).
localhost / loopback services bound to 127.0.0.1.
Link-local addresses.
And the crown jewel in the cloud: the instance metadata endpoint.

Why the metadata endpoint makes SSRF terrifying

On most cloud platforms there is a special internal address — 169.254.169.254 — that any instance can call to retrieve information about itself, including temporary credentials. It's convenient for the platform and lethal in the wrong hands.

If an attacker can trick your server into fetching http://169.254.169.254/…, the response can hand them the keys to the kingdom: cloud credentials scoped to whatever your instance can do. That is essentially the shape of the breach that leaked personal data of over a hundred million customers at a major US bank a few years ago. One trusted server, one carefully chosen URL, one very bad day.

The scary part of SSRF is not brute force. It's misplaced trust.

How LumiBase fixed it

LumiBase is an edge-native, AI-native headless CMS being reshaped into a Content OS, so it does plenty of legitimate server-side fetching — extension bundles, remote resources, and outbound calls made by governed agents. Every one of those is a potential SSRF sink. Rather than sprinkle ad-hoc checks around, we put a single guard in front of every request the server makes on a user's behalf.

The guard runs before the fetch and enforces a strict deny list of destinations. Conceptually:

Parse and resolve the target. Never trust the raw string. Resolve the hostname to its actual IP(s) so a friendly-looking domain can't smuggle you to an internal address.
Reject anything that isn't a real, public destination, specifically:
- Private ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- Loopback: 127.0.0.0/8 and ::1
- Link-local: 169.254.0.0/16 and fe80::/10
- The cloud metadata endpoint (169.254.169.254) explicitly
- Unspecified / reserved / unique-local ranges
Cover IPv6 too. Attackers love format tricks — IPv6, IPv4-mapped IPv6 (::ffff:169.254.169.254), decimal or hex-encoded IPs. The guard normalizes and checks both families so nobody sneaks in by changing notation.
Fail closed. If the address can't be confidently classified as safe and public, the request is blocked, not allowed.

Here is a representative (simplified, illustrative) version of the approach — not a verbatim copy of the production file, but it captures what the guard does:

// ssrf-guard.ts — illustrative version of the approach
import { isIP } from "node:net";
import ipaddr from "ipaddr.js";

// Ranges we never allow a server-side fetch to reach.
const BLOCKED_RANGES = [
  "10.0.0.0/8",
  "172.16.0.0/12",
  "192.168.0.0/16",
  "127.0.0.0/8",       // loopback
  "169.254.0.0/16",    // link-local, incl. 169.254.169.254 metadata
  "::1/128",           // IPv6 loopback
  "fe80::/10",         // IPv6 link-local
  "fc00::/7",          // IPv6 unique-local
];

function isBlockedIp(ip: string): boolean {
  const addr = ipaddr.parse(ip);
  // Normalize IPv4-mapped IPv6 (e.g. ::ffff:169.254.169.254) to IPv4.
  const normalized =
    addr.kind() === "ipv6" && (addr as ipaddr.IPv6).isIPv4MappedAddress()
      ? (addr as ipaddr.IPv6).toIPv4Address()
      : addr;

  return BLOCKED_RANGES.some((cidr) => {
    const [net, bits] = ipaddr.parseCIDR(cidr);
    return normalized.kind() === net.kind() &&
      normalized.match(net, bits);
  });
}

export async function assertSafeUrl(rawUrl: string): Promise<URL> {
  const url = new URL(rawUrl);

  if (url.protocol !== "http:" && url.protocol !== "https:") {
    throw new Error("SSRF: only http(s) is allowed");
  }

  // If the host is a literal IP, check it directly.
  if (isIP(url.hostname)) {
    if (isBlockedIp(url.hostname)) {
      throw new Error(`SSRF: blocked address ${url.hostname}`);
    }
    return url;
  }

  // Otherwise resolve the hostname and check every answer.
  const { lookup } = await import("node:dns/promises");
  const records = await lookup(url.hostname, { all: true });
  for (const { address } of records) {
    if (isBlockedIp(address)) {
      throw new Error(`SSRF: ${url.hostname} resolves to blocked ${address}`);
    }
  }

  return url;
}

Then anywhere the server fetches on a user's behalf:

const safeUrl = await assertSafeUrl(userProvidedUrl);
const res = await fetch(safeUrl);

Two details that matter as much as the list itself:

It's centralized. One guard, applied to every outbound-on-behalf-of-user request, so there's no forgotten code path. In Lumibase this sits alongside the extension sandbox that only loads bundles from an allowlisted origin.
It's covered by tests. The blocked ranges, the metadata endpoint, and the IPv6/encoding tricks all have test cases. So if a future refactor accidentally weakens the guard, the suite screams before it ships. A silent regression here is exactly the kind of thing that becomes a breach.

The lesson

The most dangerous vulnerabilities usually aren't about a clever exploit chain. They're about trust that was never questioned. A helpful, obedient server that fetches whatever it's told is, in the wrong moment, more dangerous than the attacker — because it has credentials and network access the attacker doesn't.

So the rule we keep coming back to: anything that goes out to the internet on a user's behalf must have its destination inspected before it's allowed to leave. Validate, resolve, and fail closed.

We're building all of this in public. LumiBase is a Content OS — a headless, AI-native CMS operated by governed agents against declarative intents, with full provenance and earned autonomy. If this kind of security-first, build-in-public engineering is your thing, come hang out at lumibase.dev. 🌱

Fail-open vs fail-closed: the security decision you make without realizing it

Khue Pham — Fri, 03 Jul 2026 02:51:12 +0000

If you build software long enough, you eventually ship a bug that isn't a typo or a logic error — it's a default. Specifically, it's the answer to a question nobody asked out loud: "What happens when this check fails?"

That question has a name in security engineering: fail-open vs fail-closed.

The door analogy

Picture a badge-controlled office door. Normally you need a card to get in. Then the power dies and the lock controller crashes. In that instant the door has to "decide": swing open so people can move freely, or stay locked so no one gets through. Swinging open is fail-open. Staying locked is fail-closed.

Neither is universally correct. A fire exit is designed to fail-open — in an emergency, human life beats access control. A bank vault is the opposite: it fails closed, because a vault that pops open when the system glitches defeats its entire purpose.

The same choice in code

Say your auth service goes down mid-request. What does your app do?

// Fail-open: keep serving, but the door is wide open
async function authorize(req: Request): Promise<boolean> {
  try {
    return await authService.check(req.token);
  } catch (err) {
    logger.warn("auth check failed, allowing request", err);
    return true; // an attacker's dream
  }
}

// Fail-closed: deny by default when anything is uncertain
async function authorize(req: Request): Promise<boolean> {
  try {
    return await authService.check(req.token);
  } catch (err) {
    logger.error("auth check failed, denying request", err);
    return false; // safe, even if annoying
  }
}

Fail-open keeps the site alive at the cost of letting everyone in. Fail-closed keeps attackers out at the cost of locking real users out too. This is the classic trade-off between availability and security, and the whole point is that you have to pick a side on purpose — not leave it to a stray catch block.

A rule of thumb

The more sensitive the thing, the more it should fail-closed. Payment gateways, authentication layers, data-access checks — when these break, the default must be "deny", because a single fail-open here can cost you the whole system.

The inverse is also true. Auxiliary concerns — logging, notifications, analytics — should usually fail-open. If your metrics pipeline goes down, blocking the entire app over it is the actual bug.

Why this matters for an AI-native CMS

At LumiBase, the Content OS I'm building in public, this decision shows up everywhere — and it gets sharper once AI agents operate content on your behalf.

An agent that wants to publish or delete content touches a schema:write-class capability. If the approval service or policy check is unavailable, the agent must fail-closed: no write happens, the action lands in an approval queue, and a human keeps the veto. Failing open here would mean an autonomous agent shipping changes to production content while your guardrails are offline — exactly the nightmare scenario a headless CMS should never allow.

Meanwhile, the parts that only observe — provenance logging, reconciliation telemetry, usage stats — fail-open. A hiccup in the audit stream should never stop a legitimate content operation.

The takeaway

Fail-open vs fail-closed isn't about which one is "better". It's about whether you chose at all. The scariest vulnerabilities are rarely dramatic — they're the quiet spots where a developer never asked "what happens when this breaks?", and the system silently failed open while everyone assumed it was safe.

Ask the question early. Make the default explicit. Your future incident report will thank you.

Day 5/100: Integrating Payments for App and Web 💳

Khue Pham — Thu, 17 Jul 2025 15:37:54 +0000

On Today's Agenda

Hitting the Limits of AI Tooling
The Core Question: Stripe vs. RevenueCat
The Verdict & A Local Twist
An Indie Developer's Philosophy in the AI Era

Hitting the Limits of AI Tooling

Wow! A guide to making money with AI in 2025? 🤩

Not quite. This is a deep dive into payment gateways and how to integrate them into the website I've built with AI so I can actually start selling.

After getting a relatively complete interface, coded 100% by AI with a ton of prompts, I went through the loop of testing, committing, deploying... over and over. I started to find Bolt AI becoming extremely sluggish, with bugs that I just couldn't fix. It seems it only works well for simple landing pages. The moment I got to the Dashboard screens, Bolt ran into a lot of issues: fixing one thing would break another, fixing that would cause a new page error, fixing the new error would bring back the original bug... So, it's best to just use it to "farm" UIs for quantity during its one-month trial (from the hackathon). The internal logic will probably require Windsurf and Cursor.

On the bright side, reviving old projects with a new interface is something it does in a snap. I had saved some old web designs that I loved but whose sites are now defunct. I found them on the Internet Archive, took screenshots, and had Bolt bring them back to life. Just like that, I had a one-of-a-kind website.

The Core Question: Stripe vs. RevenueCat

Back to payment gateways. RevenueCat requires using Stripe or a Merchant of Record (MoR) with integrated billing, like Paddle. Paddle is great because it handles VAT and is a solution when you can't register for Stripe with a Vietnamese legal entity. In terms of fees, Stripe is cheaper, but the key requirement is having a legal entity in a supported country like the US or UK.

This raises the question: if I can get Stripe, why do I even need RevenueCat?

This is the crucial distinction. I had AI create a comparison table to break it down, but here's the summary:

Stripe solves the problem of "getting paid" on the web. It's the payment processor that handles the transaction.
RevenueCat (RC) solves the problem of "what has the customer bought, and what should the app unlock?" It manages the subscription lifecycle, provides analytics, and syncs purchases across multiple platforms.

In short, Stripe handles the cash; RevenueCat handles the customer's subscription status and entitlements. It's the management and growth tool that sits on top of your payment processor.

The Verdict & A Local Twist

If your product has (or will have) a mobile app, if you want to A/B test paywalls, or if you simply want to save on maintenance time, RC is definitely worth keeping alongside Stripe.

The main reason for me is integrating payments on the App itself. Customers will buy through Apple/Google, and RC helps sync that user data, allowing them to buy once and use anywhere. For this reason, I'm willing to pay the extra 1% fee to RC for now and consider cost-saving measures later.

One more note: if my customers are primarily from Vietnam (>80%), I will redirect them to 9Pay. Using a local Vietnamese payment gateway will save quite a bit on fees.

An Indie Developer's Philosophy in the AI Era

Since the app is in its early development stage, I desperately need users to use it, give feedback, and request new features.

For indie developers like me, the greatest joy is creating products that have real users.

So many products get thrown away. The code can be beautiful, the technology can be fancy, you can even register a company in some far-off land to dodge taxes... but the product has... no users. :D

With the current wave of AI, creating new products has never been so fast—it's like making instant noodles.

Day 3/100: Assembling the Toolkit on a Shoestring Budget 🛠️💰

Khue Pham — Tue, 08 Jul 2025 11:01:52 +0000

This is a submission for the World's Largest Hackathon Writing Challenge: Building with Bolt.

Table of Contents: 100-Day Journey

Day	Topic	Link
1/100	Starting the 100-Day Journey & Introduction	View Post
2/100	AI Showdown: Which AI to choose for project analysis?	View Post
3/100	Assembling the Toolkit on a Shoestring Budget	This post
...
99/100	...
100/100	Reflections on the 100-Day Journey

On Today's Agenda

The Hackathon Opportunity: Why I Jumped In
The Ultimate Low-Cost Tech Stack
Let the Building Begin! From Image to UI

The Hackathon Opportunity

Bolt announced its Hackathon two months ago, but I only decided to join near the end. Partly because I used to think AI tools were like v0—not great for building UIs. Plus, I was already happy with my setup of Cursor and Windsurf. A year or two ago, AI code assistants were riddled with bugs, but they've gradually evolved to the point where they can now code the entire frontend.

However, after trying out Loveable and Bolt, I feel like the options for UI generation have multiplied. The GitHub integration is incredibly fast for pushing code. Just by registering for the Bolt hackathon, I was given 1 million free tokens to build with, along with tons of coupons for other tools. Most importantly, it gave me free access to the RevenueCat payment gateway.

I had also signed up for another gateway called Ruul, which has the advantage of accepting crypto (USDT). However, RevenueCat waives its fees for revenue under $2.5k/month. I decided to use RevenueCat for web payments, Bolt to build the new app, ChatGPT to help shape the idea, and Gemini to choose the app's name and write the Terms & Conditions.

The Ultimate Low-Cost Tech Stack

Here is the complete stack I've assembled for this project:

Logo & Banners: Canva
Manual UI Design: Figma
AI Frontend Generation: Bolt AI
Domain: Namecheap (already purchased, so I didn't use the free one from the Hackathon).
Database: Supabase
Web Server & Deployment: Netlify
CDN & DNS: Cloudflare
Email: Google Workspace (I'm lucky to have a grandfathered free Basic plan from 2011, as they no longer offer it. A good alternative is Lark by Bytedance—I've already registered a few accounts just in case they follow Google and drop their free tier ^^!).
App Store Account: Apple Developer

I'll deal with other security considerations later on during the project. Today's task is to register for the Apple Developer account to push the app to the Apple Store. The cost is $99, which came out to about 1.2 million VNĐ according to the developer site notification.

Total Projected Cost: $7 for the domain + $99/year for the Apple account. Everything else is free.

Let the Building Begin!

Alright then, time to build the interface! Bolt's ability to convert an image into a web interface is excellent. You can find a design you like on a site like UI8, take a screenshot, and feed it to Bolt. Then you just ask it to replicate the image for your idea, swapping out this or that section.

I'm determined to build an MVP with core functions, a smooth end-to-end flow, minimal bugs, and basic security. Therefore, I'm not stressing over the UI being perfect; as long as I think it looks good and isn't buggy, it's a win.

I repeated these steps for the Login, Signup, Pricing, and Dashboard screens... and in a flash, I had dozens of commits. It's been a while since I've felt this productive.

Day 2/100 - Which AI to choose for analyzing investment projects?

Khue Pham — Sat, 05 Jul 2025 13:39:10 +0000

This is a submission for the World's Largest Hackathon Writing Challenge: Building with Bolt.

Table of Contents: Architecting a Giant - 17 Products Enhanced by AI

(100-Day Journey)

Day	Topic	Notes / Link
1/100	Starting the 100-Day Journey & Introduction	View
2/100	Which AI to choose for analyzing investment projects?	This page
3/100	Assembling the Toolkit on a Shoestring Budget	View
...	...	...
100/100	...

🤖 AI Showdown: Gemini vs. ChatGPT vs. Grok for Project Analysis 🚀

Part 1: The Initial Test - Methodology 🧠

(Continued from Day 1...)

My first question to the AIs was simple: "What is your methodology?" 🤔

Every AI provides a pretty slick answer, but in my research, Gemini was the one that presented a clear, structured methodology right from the start. Before even touching the project details, Gemini laid out a strategic analysis framework based on FAST:

Feasibility ✅
Accelerated cash flow generation 💸
Sustainability & Threat (Risk) level 🛡️

This wasn't something I prompted! It showed me that each AI has its own way of thinking. ChatGPT and Grok were similar, giving a general overview and objectives. ChatGPT did a bit better by listing evaluation criteria, but it wasn't nearly as detailed or systematic as Gemini.

Scores for this round:

Gemini: +1 🥇
ChatGPT: +0.5 👍

Part 2: The Data Wars - Who Has the Best Fuel? ⛽

An AI is only as good as its data, right?

Google (Gemini): Has a colossal data advantage. We're talking Google Search, Google Scholar 📚, Google Translate, YouTube, Google Docs... plus the entire internet that's constantly feeding its bots for SEO purposes 😅. This massive, diverse dataset is an advantage rivals can only dream of. 👑
OpenAI (ChatGPT): Has the first-mover advantage. It has a gigantic user base feeding it endless questions, feedback, and prompts. Plus, it's backed by the financial muscle of Microsoft. 💪
xAI (Grok): Has access to the real-time, chaotic data firehose of X (formerly Twitter) with its ~650 million users. However, for deep research, this isn't ideal. X is mostly short-form news, memes, and entertainment. The in-depth data just can't compete with the other two giants.

Scores for this round:

Gemini: +1.5 🥇
ChatGPT: +1.0 👍
Grok: +0.5 🤷

Part 3: The Powerhouse - Context & Ecosystem 🔌

How much information can they handle at once?

Gemini: Supports up to a 1 million token context window. 🤯 This is massive, allowing it to analyze thousands of pages or an entire complex codebase in one go.
ChatGPT & Grok: Limited to 128k tokens.

What about professional integration?

Gemini: Deeply integrated into the Google Workspace ecosystem (Docs, Sheets, etc.), making it highly synchronized. 🔗
ChatGPT: Integrated into the Microsoft ecosystem as Copilot. While the MS ecosystem (Windows, Office) is huge, the integration feels less seamless since OpenAI and Microsoft are separate companies. 🤝
Grok: Just has the Tesla/xAI ecosystem. At this point, I'm taking Grok out of the race. 👋

Scores for this round:

Gemini: +1 🥇
ChatGPT & Grok: +0.5 👍

Part 4: The Real-World Challenge - Project Analysis 📊

This is where it gets interesting.

ChatGPT was very smart and immediately identified the project I was most passionate about. ❤️

But Gemini did something incredible that ChatGPT completely missed (unless I specifically asked for it): it analyzed the legal risks. ⚖️ Gemini independently found the project's GitHub repo, analyzed its open-source license, and gave me clear, serious warnings ⚠️ about potential policy violations and abuses. It even gave my projects cool names like "Project Phoenix" (for a project I wanted to revive) and "Navigating the Walled Garden" (for projects with hidden mandatory costs like a $99 Apple Developer fee). I absolutely loved this. ChatGPT just ignored this critical aspect.

However, when it came to the detailed project analysis (ignoring legalities), ChatGPT shined. ✨ It did the most thorough research on the technical feasibility. As a solo dev, this is the most crucial factor! I don't know why Gemini overlooked it. If you can't overcome the technical hurdles, the project is dead on arrival. 💀

Furthermore, on my question about the fastest path to cash flow 💰, ChatGPT provided a much more realistic timeline, considering development, app store reviews, payment gateway holding periods, etc. Gemini's analysis felt a bit superficial here; it would quickly dismiss a project if it hit any obstacle, without providing a deep, comparative breakdown.

Part 5: The Final Verdict 🏆

So, what's the conclusion?

Gemini is probably the best AI tool for initial, high-level strategic research. It sets up a fantastic framework and catches critical things like legal risks that others miss.

ChatGPT seems to be better for deep, granular analysis, especially on the technical side.

All AIs need good prompts to deliver great results, but Gemini seems to make the initial process a bit easier and safer.

But in the end, why choose? 🤔 I'm a grown-up, I don't choose A or B... I choose them all! 😁 The best approach is to use both, compare their outputs, and synthesize the results yourself.

A Multi-Part Series: Architecting a Giant - 17 Products Enhanced by AI - Day 1

Khue Pham — Fri, 04 Jul 2025 13:46:00 +0000

This is a submission for the World's Largest Hackathon Writing Challenge: Building with Bolt.

Here you go, my friend. Let me retell you the story of my "AI bake-off," just like we're chilling and chatting over a beer.

Day 1 - First Contact: The Initial AI Test / Picking AI (ChatGPT, Gemini, Grok) for a Deep Dive?

So, here's the deal. My brain's been firing off ideas like a broken firework launcher lately. We're talking everything from Open-source projects, Chrome Extensions, Games, Web3, E-commerce, to Health apps, apps for kids... I've even thought about resurrecting old dead projects, making social media videos, or just straight-up cloning extensions and data. I did a quick count, and we're talking about 17 projects with a clear concept. For most of them, I've just dipped my toes in, you know, a little Proof of Concept (PoC) to check the technical feasibility.

So, What's the Mission?

Since my brain is basically a messy browser with too many tabs open, I asked the AIs to pick a starter for me. The main rule? It had to be something that could make money ASAP. Cold, hard cash. The more the merrier (though let's be real, any amount is a good start). Of course, "generating cash flow" is a vague beast and depends on a million things, but I just threw that general request out there to see how the AIs would handle it.

My AI squad is all top-tier stuff: Gemini 2.5 Pro, Grok 3 Pro, and ChatGPT o3-pro. To analyze the feasibility, I made them all use their strongest "Deep Research" features: For Gemini, it was "Deep research" on the Gemini 2.5 Pro model; for ChatGPT, it was o3-pro (the "best at reasoning" one) combined with its Research feature; and for Grok, it was "Deeper Research" with Grok3. To keep things fair, I fed them the exact same prompts in two different ways: first, a series of smaller prompts adding more details each time, and second, a version where I crammed all the questions into a single, massive prompt.

Round 1: The Face-Off

Kicking things off with Gemini, the Google guy, it shot back with a whole research strategy for me to confirm. Meanwhile, ChatGPT wanted more deets, asking a bunch of follow-up questions. And Grok from xAI? Just jumped straight into the analysis. Ballsy.

I gotta say, I liked ChatGPT's approach. It asked some really legit questions, hitting angles I hadn't even thought of. Honestly, this guy made me create new prompts just to feed the other two :)) By the end, even when I combined everything into one monster prompt, it still managed to find more questions to ask @.@ Anyway, I'll admit, this thorough approach is solid. Score: ChatGPT (C): 1, Gemini (Ge): 0, Grok (Gr): 0.

But... and it's a big but... OpenAI's golden boy has this super annoying bug where its 'thinking' process just... hangs. Forever. I'd heard a buddy complain about this before, so I wasn't shocked, but man, is it irritating. I had to F5 the page to see the results, which made me wonder: if I hadn't refreshed, would it still be 'thinking' right now? The UI not updating when the job is done is just awful! But hey, all I care about is the result, so I'll give the other two a little bonus point for not giving me a headache. Score: ChatGPT (C): 1, Gemini (Ge): 0.5, Grok (Gr): 0.5.

While the other two dudes were cruising along, showing their progress as they thought, ChatGPT was noticeably slower. What gives? Out of curiosity, I peeked into its thinking process and saw it was totally different. To analyze a project's real-world potential, ChatGPT spent ages searching and analyzing YouTube videos for a project I'd already shelved, then compared it to other similar projects to scrape for info.

Obviously, this deep-dive method paid off in terms of application analysis—the results were super detailed and spot-on. I guess there's a tradeoff here: more research time for more detailed results. I really want to give ChatGPT points for this, but if it goes down the wrong rabbit hole, all that detail is useless, right? I'll put a pin in that for now and see how other factors play out.

React-Native + Web + Firebase (Part 02) — Implement React Native Firebase cross-app

Khue Pham — Fri, 20 Jun 2025 18:38:12 +0000

Project Structure Overview and Login Flow

In part one, we gained an overview of the directory structure and the packages we will install for the project. Now, we’ll discuss the login flow, which will be implemented as follows:

Login Flow

Opening the App:

If the user is not logged in:

Display the Login Screen.

The user taps “Login with Apple” to initiate the login process on their iPhone.

2. Searching for the User based on the account:

If the user does not exist:

Create a new user and proceed.

If the user exists and is valid:

Retrieve the valid user information and proceed.

If the user exists but is invalid:

Display an error.

3. Returning to the App:

Store the login information in Context.

If the user is valid, navigate to the Home Screen.

If the user is invalid, navigate to the Error Screen.

4. When the User is already logged in:

Open the app and check for the latest user data.
If the user does not exist:

Create a new user and proceed.

If the user exists and is valid:

Retrieve the valid user information and proceed.

If the user exists but is invalid:

Display an error

App Structure:

The app can have multiple Context Providers serving different purposes, such as theme settings or authentication information.
An index file for the providers needs to be created to manage them.

export function AppContextProvider({ children }: { children: React.ReactNode }): JSX.Element {

return (

{children}

)
}

AppConfigProvider is an example of other contexts, which we won’t discuss here.

Now, let’s create the AuthProvider.tsx file with the following content:

// import files
...
type LoginAction = {
  type: 'LOGIN',
  user: User
}
type LogoutAction = {
  type: 'LOGOUT'
}
type ChangeAction = {
  type: 'CHANGE',
  user: User
}
type OnUserChangedAction = {
  type: 'OnUserChangedAction',
  user: User
}
type AuthDispatchAction = LoginAction | LogoutAction | ChangeAction | OnUserChangedAction

export type AuthContextState = User | null
export const AuthContext = createContext<AuthContextState>(null);
export const AuthDispatchContext = createContext<Dispatch<AuthDispatchAction> | null>(null)
export function authReducers(preAuthState: AuthContextState, action: AuthDispatchAction): AuthContextState {
  switch (action.type) {
    case 'LOGIN':
    case 'CHANGE':
      return action.user
    case 'OnUserChangedAction':
      return action.user;
    case 'LOGOUT':
      return null
    default:
      throw Error('Unknown action: ' + JSON.stringify(action));
  }
}

export function AuthProvider({ children }: PropsWithChildren<any>) {
  const [initializing, setInitializing] = useState(true);
  const [authState, authDispatch] = useReducer<Reducer<AuthContextState, AuthDispatchAction>>(authReducer, defaultUserState,)
  const handleAuthStateChanged = useCallback(async (user: FirebaseAuthUser | null) => {
    if (!user) {
      authDispatch({ type: 'LOGOUT' })
    }
    else {
      const authUser = await getAuthenticatedUser(user.uid);
      if (authUser)
        authDispatch({ type: 'CHANGE', user: authUser, });
    }
    if (initializing) {
      setInitializing(false);
    }
  }, [initializing])

  useEffect(() => {
    // ... 
  }, [])

  return (
    <AuthContext.Provider value={authState}>
      <AuthDispatchContext.Provider value={authDispatch}>
        {!initializing && children}
      </AuthDispatchContext.Provider>
    </AuthContext.Provider>
  )
}

It’s important to note that in the useEffect, we will call the onAuthStateChanged service to update the state. When the app receives the user information, it will call the reducers to update the context:

Add the following to the useEffect:

import { onAuthStateChanged } from "../services/Firebase/users/userManagement";

//...

useEffect(() => {
 return onAuthStateChanged(handleAuthStateChanged);
}, [handleAuthStateChanged])

In the services/Firebase/users/ directory, we will create three files:

userManagement.ts: Contains interfaces to call functions from outside, helping to define types so that other hooks/services can understand them. This is where we declare onAuthStateChanged as mentioned earlier.
userManagement.native.ts and userManagement.web.ts: These files implement onAuthStateChanged for each platform. Since web and app use different libraries, they cannot share the same source code.

Let’s continue:

First, declare the interface for userManagement in the userManagement.ts file. When the user information is updated, Firebase will call this function, returning a callback with the user information for further processing:

interface UserManagement {
  onAuthStateChanged: <T>(callback: (user: T) => void) => () => void;
  // getUserByDevice: () => Promise<User | undefined>;
  // getUserById: (userId: string) => Promise<User | undefined>;
  // updateUser: (userId: string, userData: any) => Promise<void>;
  // subscribeOnUserChanged: (userId: string, callback: (user: User | undefined) => void) => () => void;
  // signOut: () => Promise<void>;
  // getCurrentUser: () => Promise<User | undefined>;
  // signInWithCredential: <T, G>(credential: T) => Promise<G>;
  // signInAnonymously: <T>() => Promise<T>;
}

Next, we need to define where we call the function. In the same userManagement.ts file, add the following:

import { Platform } from "react-native";

const userManagement = Platform.select({
 web: () => require('./userManagement.web'),
 default: () => require('./userManagement.native'),
});

export const {
 onAuthStateChanged,

 // getUserByDevice,
 // getUserById,
 // updateUser,
 // subscribeOnUserChanged,
 // signOut,
 // getCurrentUser,
 // signInWithCredential,
 // signInAnonymously
} = userManagement as UserManagement;

The userManagement.native.ts version uses the package @react-native-firebase/auth, while the web version calls the firebase/auth library to invoke the onAuthStateChanged function.

This function is responsible for:

Listening for changes in the user’s authentication state (logging in and out).
This method returns an unsubscribe function to stop listening to events.
Always ensure you unsubscribe from the listener when it is no longer needed to prevent updates to components that are no longer in use.

userManagement.native.ts

import auth, { FirebaseAuthTypes } from "@react-native-firebase/auth";

export type FirebaseAuthUser = FirebaseAuthTypes.User;
export function onAuthStateChanged(callback: (user: FirebaseAuthUser | null) => void): () => void {
return auth().onAuthStateChanged(callback);
}

The native version requires the configuration of the GoogleService-Info.plist file for the Apple app and/or the google-services.json file for the Android app to function properly.

userManagement.web.ts

import { auth, db } from '../config';
import { User as FirebaseUser } from "firebase/auth";

export type FirebaseAuthUser = FirebaseUser;
export function onAuthStateChanged(
 callback: (user: FirebaseAuthUser | null) => void
): () => void {
 return auth.onAuthStateChanged(callback);
}

Unlike the native version, the web version requires a configuration to call Firebase through the initializeAuth function. Therefore, we need to add a config file to the Firebase service as follows:

Folder Structure Updated:

...
services/
 Firebase/
    config/
     index.ts
     index.native.ts
     index.web.ts
  users/
   index.ts
   userManagement.ts
   userManagement.native.ts
   userManagement.web.ts

Similar to the userManagement.ts file, the index.ts file for Firebase config only needs to export the functions from both web and native versions.

config/index.ts

import { Platform } from "react-native";

const app = Platform.select({
 web: require('./index.web'),
 default: require('./index.native'),
});
export const { auth, firebaseApp } = app;

The files in the config are primarily intended for Firebase on the web; therefore, the content in index.native.ts does not need to return any data.

config/index.native.ts

let firebaseApp
let db
let auth
let analytics

export { analytics, auth, db, firebaseApp };

The index.web.ts file contains the main logic that allows us to access Firebase services on the web. The content of the file is as follows:

config/index.web.ts

import { initializeApp } from 'firebase/app';
import { initializeAuth } from 'firebase/auth';

// Firebase JS SDK work with expo web
// for more information: https://docs.expo.dev/guides/using-firebase/#using-firebase-js-sdk

// Initialize Firebase
const firebaseConfig = {
 apiKey: process.env.EXPO_PUBLIC_FIREBASE_API_KEY,
 authDomain: process.env.EXPO_PUBLIC_FIREBASE_AUTH_DOMAIN,
 // databaseURL: process.env.EXPO_PUBLIC_FIREBASE_DATABASE_URL,
 projectId: process.env.EXPO_PUBLIC_FIREBASE_PROJECT_ID,
 storageBucket: process.env.EXPO_PUBLIC_FIREBASE_STORAGE_BUCKET,
 messagingSenderId: process.env.EXPO_PUBLIC_FIREBASE_MESSAGING_SENDER_ID,
 appId: process.env.EXPO_PUBLIC_FIREBASE_APP_ID,
 measurementId: process.env.EXPO_PUBLIC_FIREBASE_MEASUREMENT_ID,
};

let firebaseApp: ReturnType<typeof initializeApp>;
let auth: ReturnType<typeof initializeAuth>;

try {
 firebaseApp = initializeApp(firebaseConfig);
 auth = initializeAuth(firebaseApp);
 auth.useDeviceLanguage();
} catch (error) {
 console.error("Error initializing Firestore:", (error as any).message);
 console.error("Error Stack:", (error as any).stack);
 console.error("Error Details:", error);
}

export { auth, firebaseApp };

// To apply the default browser preference instead of explicitly setting it.
// For more information on how to access Firebase in your project,
// see the Firebase documentation: https://firebase.google.com/docs/web/setup#access-firebase

firebase/app and firebase/auth are separate releases of the Firebase JS SDK. TODO: Update from the Firebase blog to provide further explanation for this section.

firebase/app and firebase/auth are package dependencies of @react-native-firebase/app. There is no need to install them separately, and they can be called directly.

If you attempt to manually install these packages, you will encounter the following error:

RNFNFirestoreDocumentModule.getDocument got 4 arguments, expected 2 ...

This error occurs due to a version conflict between the Firebase JS SDK and the Firebase JS SDK, which is a dependency of @react-native-firebase.

About this snippet:

const firebaseConfig = {
 apiKey: process.env.EXPO_PUBLIC_FIREBASE_API_KEY,
 authDomain: process.env.EXPO_PUBLIC_FIREBASE_AUTH_DOMAIN,
 // databaseURL: process.env.EXPO_PUBLIC_FIREBASE_DATABASE_URL,
 projectId: process.env.EXPO_PUBLIC_FIREBASE_PROJECT_ID,
 storageBucket: process.env.EXPO_PUBLIC_FIREBASE_STORAGE_BUCKET,
 messagingSenderId: process.env.EXPO_PUBLIC_FIREBASE_MESSAGING_SENDER_ID,
 appId: process.env.EXPO_PUBLIC_FIREBASE_APP_ID,
 measurementId: process.env.EXPO_PUBLIC_FIREBASE_MEASUREMENT_ID,
};

Returning to the Firebase Config in the Google Console, create a new app for the web. Firebase will send you the JS SDK configuration.

Add the configuration to the .env file of your project. In this example, I am using Expo, so the environment variables have the prefix EXPO_PUBLIC_. You can use a library like react-native-dotenv to manage these environment variables.

Thank you for joining me on this comprehensive article. If you found this tutorial helpful, don’t forget to give this post *50 claps👏 **and **follow *🚀 if you enjoyed this post and want to see more. Your enthusiasm and support fuel my passion for sharing knowledge in the tech community.

You can find more such articles on my profile -> https://medium.com/@khuepm
https://github.com/khuepm

Stay tuned for more in-depth tutorials and insights on Javascript and React Native development.

And that’s it! Place a console.log() statement in the callback handleAuthStateChanged within the AuthProvider.tsx file to check the returned data. In the next part (if anyone purpose for this), I will return to the Login section. Happy coding! 🦄
Here the Part 01 of this story: https://dev.to/khuepm/react-native-web-firebase-part-01-why-we-use-react-native-to-develop-both-native-and-web-fdg

React Native + Web + Firebase (Part 01) — Why we use React Native to develop both Native and Web version

Khue Pham — Fri, 20 Jun 2025 18:36:03 +0000

Introduction — Part 01

You are building a cross-platform app using React Native, which will target both mobile (iOS and Android) and web platforms. Leveraging Expo provides an easy and efficient way to set up, develop, and deploy your app while React Native Web allows you to render the same React Native components in the browser.

Key Technologies:

Expo: A framework that helps developers build React Native applications quickly, with many built-in tools for managing the app lifecycle, testing, and deployment.

Benefits:

Managed workflow: Expo handles configurations and simplifies setup.
Quick testing: Easy to test and deploy on devices and simulators.
Universal development: Allows a unified codebase for mobile and web.

2. React Native: The core framework used for building cross-platform mobile apps with a single JavaScript codebase.

Benefits:

Native performance: It provides access to native UI components.
Modular: Huge ecosystem with community-driven libraries.

3. React Native Web: A library that makes React Native components and APIs work on the web. It allows you to reuse your mobile app’s codebase to build a web version with the same UI and functionality.

Benefits:

Code reusability: Most of your code can be shared between web and mobile.
Easier web deployment: Supports popular web technologies like HTML and CSS, while keeping the React Native architecture.

4. React Native Fỉrebase: Combining Firebase with React Native allows for fast, cross-platform development with a fully managed backend solution. You get real-time data sync, secure authentication, push notifications, analytics, and more, without having to worry about managing your own server infrastructure. This combination results in faster development, easier scaling, and a smoother user experience on both iOS and Android platforms.

Create a Project on Firebase

1. Firestore:

Firebase’s Real-Time Database and Firestore provide fast, real-time data synchronization between your app and the cloud. For React Native apps that need live updates (such as messaging apps or live feeds), this is a huge benefit.

2. Authentication:

Firebase’s Authentication service supports multiple sign-in methods like Google, Facebook, email/password, etc. This makes it easy to implement secure user authentication with minimal effort, which integrates smoothly with a React Native front end.

Create an app in Firebase Settings and download the following files:

GoogleService-Info.plist for the Apple app version.
google-services.json for the Android app version.

In this post, we will not dive deep into how to implement React Native Firebase into your app. Please refer to the React Native Firebase documentation for detailed instructions:

https://rnfirebase.io/

Create files following the directory structure below:

App.tsx

.env

context/

  AuthProvider.tsx

hooks/

  useUserCredential.tsx

screens/

  Login.tsx

  Home.tsx

services/

  Firebase/

    users/

      index.ts

      management.ts

      management.native.ts

      management.web.ts

  utils.ts

Explanation for each component in the directory tree:

App.tsx: This is the root component of the app. Here, we will wrap the ContextProvider for the routers, which contain screens like Login, Home, and logic to check if user data exists, loading the corresponding screens accordingly.
AuthProvider.tsx: User information is stored in React Context. This file contains the context and reducers to update user information after receiving data from Firebase.

hooks: For user information that needs to be displayed on the UI or used for logic in components, we have a custom hook useUserCredential.ts, which returns this information.

screens: This folder contains the screens for displaying the UI.

Login.tsx: The login screen with a single button “Login By Apple.” When the user taps this button, the app will initiate login using the Apple account on the iPhone.
Home.tsx: After successful login, the data from Apple is recognized by Firebase Authentication and returned to the app. We will process this data and then display the Home screen.

services: This folder contains the business logic performed in the app, independent of the UI. In addition to displaying data on the native app, we also handle the display on the web. Therefore, there are separate files for each environment:

Files with .web.ts are for the web version.

Files with .native.ts are for both iOS and Android versions.

services/utils.ts: A collection of functions for processing data within the services. These are pure functions and are limited to the service layer of the app.

You can find more such articles on my profile -> https://medium.com/@khuepm
https://github.com/khuepm

Stay tuned for more in-depth tutorials and insights on Javascript and React Native development.

Ok, so in the Part Two, we will continue implement the code. Check this out!
https://dev.to/khuepm/react-native-web-firebase-part-02-implement-react-native-firebase-cross-app-2ike

Environment File (.env) Checker and Syncer for ReactJS / NodeJS Project

Khue Pham — Fri, 20 Jun 2025 18:24:20 +0000

This bash script provides functionality to check and sync environment files in your project.

Features

Checks .env files against a template (.env.template)
Identifies missing variables in .env files
Offers to sync .env files with the template
Skips syncing content for specified files

Usage

Source code in my Github repository here:
Check file here: misc/check_env_files.sh at main · khuepm/misc

Place the script (check_env_files.sh) in your project root directory.
Ensure you have a .env.template file with all required environment variables.
Make the script executable:

chmod +x checkenv.sh
1. Run the script:
./checkenv.sh
1. (optional) Add to package.json to check every start yarn
{
…
scripts: {
"prestart": "sh checkenv.sh",
}
}

What it does

Checking Environment Files:

The script checks all .env* files in the current directory against .env.template.
It displays missing variables in each file.
A summary of errors (if any) is shown for each file.

2. Syncing Environment Files:

If errors are found, the script offers to sync .env files with .env.template.
If you choose to sync (by entering ‘y’), the script will:
Comment out variables not present in the template
Add new variables from the template
keep existing variables: preserving the current value and adding a comment with the template value

Configuration

The script uses .env.template as the reference. Ensure this file contains all required variables for your project.

Note

After syncing, the script cleans the yarn cache. You may want to adjust or remove this step based on your project needs.

Comment out yarn cache clean

How do I created it?

1. Initial Setup:

#!/bin/bash

template=".env.template"

# Check if the template file exists
if [ ! -f "$template" ]; then
  echo "Error: $template not found"
  return 1
fi

This section sets up the script and defines the template file. It also checks if the template file exists.

2. check_env_files() function:

# Use for later step, a flag to notice when we need to sync the .env
errors_found=false

check_env_files() {
  files_not_to_check=(".env.template")
  # Get all .env files in the current directory
  files_to_check=($(find . -maxdepth 1 -type f -name '.env*'))

  # Remove files that are in files_not_to_check
  for file in "${files_not_to_check[@]}"; do
    files_to_check=(${files_to_check[@]/$file})
  done

  # Remove any empty elements
  files_to_check=(${files_to_check[@]})

  # Get terminal height and width
  terminal_height=$(tput lines)
  terminal_width=$(tput cols)

  # Variables to store output and result
  output=""
  result=""

  # Function to update the screen, keep to notice text at the bottom of screen
  update_screen() {
    # Clear the screen
    tput clear

    # Print the output
    echo "$output"

    # Move cursor to the bottom and print the result
    tput cup $((terminal_height - 3)) 0
    printf '%*s\n' "$terminal_width" '' | tr ' ' '-'
    echo "$result"
    printf '%*s\n' "$terminal_width" '' | tr ' ' '-'

    # Move cursor back to the top
    tput cup 0 0
  }

  for file in "${files_to_check[@]}"; do
    if [ -f "$file" ]; then
      output+="\n"
      output+="Checking $file...\n\n"
      error_count=0
      while IFS= read -r line || [[ -n "$line" ]]; do
        key=$(echo "$line" | cut -d'=' -f1)
        if ! grep -q "^$key=" "$file"; then
          output+="\033[31m  💔 Missing in $file: $key\033[0m\n"
          ((error_count++))
          errors_found=true
        fi
        update_screen
      done < "$template"

      # Update final result
      output+="\n\n==========================================\n"

      if [ $error_count -gt 0 ]; then
        result+="\n\033[31m❌ Done checking $file with $error_count error(s)\033[0m\n"
        output+="$result"
      else
        result+="\n\033[32m✅ Done checking $file with no errors\033[0m\n"
        output+="$result"
      fi

      update_screen
      output+="\n"

      # Add a small delay to make the result visible at first check
      # Remove if you want to see the result immediately
      if [ "$file" = "${files_to_check[0]}" ]; then
        sleep 1
      fi

    else
      #output+="\033[33m🟠 Check $file: $file not found, skipping\033[0m\n"
      #result+="\033[33m⚠️ $file not found, skipping\033[0m\n"
      update_screen
    fi

  done

  # Clear the result at the end
  result=""
  update_screen

  # Reset terminal settings
  tput rmcup  # Exit alternate screen buffer
  tput cnorm  # Show cursor
  tput sgr0   # Reset all attributes

  # Clear the screen and move cursor to top-left
  clear
  tput cup 0 0

  # Display final output
  echo "$output"
}

This function is responsible for checking .env files against the template. It does the following:

Finds all .env files in the current directory
Removes files that should not be checked
Sets up a dynamic terminal display
Checks each .env file against the template, highlighting missing keys
Updates the screen with progress and results

The problem when template has an empty line or a comment line, the checker will not work property. So I need to adjust it a little bit:

      ...
      while IFS= read -r line || [[ -n "$line" ]]; do
        # Skip empty lines and comment lines
        if [[ -z "$line" || "$line" =~ ^[[:space:]]*# ]]; then
          continue
        fi
      ...

3. sync_env_files() function:

This function synchronizes .env files with the template. It:

Finds all .env files to sync
For each file:
Comments out lines not in the template
Updates existing keys with new values from the template

Adds new keys from the template

sync_env_files() {
# Get all .env files in the current directory
files_to_sync=($(find . -maxdepth 1 -type f -name '.env*'))

# Exclude .env.template from files to sync
files_to_sync=(${files_to_sync[@]/$template})

# Remove any empty elements
files_to_sync=(${files_to_sync[@]})

# Sync files
for file in "${files_to_sync[@]}"; do
if [ -f "$file" ]; then

  # Check if the file is in the list of files not to sync

  echo "Syncing $file with $template..."

  # Comment lines not in template
  while IFS= read -r line || [[ -n "$line" ]]; do
    if [[ $line =~ ^[[:space:]]*# || -z $line ]]; then
      continue  # Skip comments and empty lines
    fi
    key=$(echo "$line" | cut -d'=' -f1)
    if ! grep -q "^$key=" "$template"; then
      sed -i '' "s|^$key=.*|# $line # Not in template|" "$file"
      echo "\033[31m  Commented: $key (not in template)\033[0m"
    fi
  done < "$file"

  while IFS= read -r line || [[ -n "$line" ]]; do
    if [[ $line =~ ^[[:space:]]*# || -z $line ]]; then
      continue  # Skip comments and empty lines
    fi
    key=$(echo "$line" | cut -d'=' -f1)
    value=$(echo "$line" | cut -d'=' -f2-)

    if grep -q "^$key=" "$file"; then
      # Key exists, check if value is different
      current_value=$(grep "^$key=" "$file" | cut -d'=' -f2-)
      if [ "$current_value" != "$value" ]; then
        # Value is different, update it
        sed -i '' "/# $key=.*# Updated from template/d" "$file"
        sed -i '' "s|^$key=.*|# $key=$value # Updated from template\n$key=$current_value|" "$file"
        echo "\033[33m  Updated: $key\033[0m"
      else
        echo "  Skipped: $key (value unchanged)"
      fi
    else
      # Key doesn't exist, add it
      echo "$key=$value # Added from template" >> "$file"
      echo "\033[32m  Added: $key\033[0m"
    fi

  done < "$template"

  echo "Finished syncing $file"
  echo

fi

done
}

4. Main execution flow:

# Call the function
check_env_files

if [ "$errors_found" = true ]; then
  # Ask user if they want to sync files
  # If yes, call sync_env_files()
    # After sync successfully, do clean the cache
  # If no, cancel the operation
else
  echo "No errors found in .env files. Sync not needed."
fi

This section calls the check_env_files() function and then, based on whether errors were found, either prompts the user to sync the files or informs them that no sync is needed.

Key features of this script:

Dynamic terminal display for real-time progress updates
Color-coded output for easy reading (red for errors, green for success, yellow for warnings)
Careful handling of existing values in .env files during sync
Option to sync files only if errors are found

This script is useful for maintaining consistency across multiple .env files in a project, ensuring that all required environment variables are present and up-to-date.

ReactJS #ReactNative #.env #.env.template #uptodate-env-file