Coder Legion - Recent posts tagged firebase

Telemetry: Shared Analytics and Crash Reporting in Kotlin Multiplatform

Fri, 09 Oct 2026 14:00:00 +0000

In a modern endurance car, every sensor talks to the same box. Tyre pressure, brake temperature, fuel flow, throttle trace. They all end up in one data stream that goes to the pit wall over a single radio link. The engineer on the wall doesn't care which supplier made the brake sensor. He cares that the channel is called BRAKE_TEMP_FL and that the number arrives every 100 milliseconds.

Swap a sensor, the channel name stays. That's the whole point of the standard.

Analytics and crash reporting in a KMP app should work the same way. The sensors are the SDKs, one per platform, made by different teams with different APIs. The channel names are yours.

What I had before

My first KMP app logged analytics twice. Once in Kotlin for Android, once in Swift for iOS. Same events, same names, in theory.

In practice, the Android side sent screen_view with a screen_name parameter. The iOS side sent screenView with screenName. Nobody noticed for six weeks, until I tried to build a funnel in the dashboard and half the users were missing from it. The numbers weren't wrong. They were split across two event names that meant the same thing.

That's the real cost of leaving telemetry in the platform layer. Not the duplicated code, which is small. The drift. Two implementations of the same contract, with no compiler checking that they agree.

If you read Change the Map, this is the same move applied to a different problem: the contract lives in commonMain, the SDKs sit underneath. It also pairs with flags directly, because the first event worth logging is which variant a user was actually shown.

Crash reporting has a quieter version of the same problem. A Kotlin exception that crashes the Android app shows up in Crashlytics with a readable stack trace. The same exception on iOS arrives as a native crash with frames that look like kfun:..., and the Kotlin type is buried in the message. I'll get to that.

The interface lives in commonMain

The fix is to stop treating analytics as a platform feature and start treating it as a domain contract.

// commonMain
interface Analytics {
    fun track(event: AnalyticsEvent)
    fun setUserId(id: String?)
}

sealed interface AnalyticsEvent {
    val name: String
    val params: Map<String, String>

    data class ScreenView(val screen: String) : AnalyticsEvent {
        override val name = "screen_view"
        override val params = mapOf("screen_name" to screen)
    }

    data class Purchase(val sku: String, val amountCents: Long) : AnalyticsEvent {
        override val name = "purchase"
        override val params = mapOf(
            "sku" to sku,
            "amount_cents" to amountCents.toString(),
        )
    }
}

A sealed interface for events is the part that pays for itself. The event name and the parameter keys exist in exactly one place. A new event is a new class, and the compiler tells every when that cares about it. A typo in "screen_name" is no longer possible in two files, because it's only written once.

I keep params as Map<String, String> on purpose. Firebase, Mixpanel, and Amplitude all accept richer types, but they disagree about which ones. Strings are the lowest common denominator, and the conversion cost is trivial.

The crash side is a second, separate interface.

// commonMain
interface CrashReporter {
    fun log(message: String)
    fun recordNonFatal(throwable: Throwable)
    fun setUserId(id: String?)
}

Two interfaces, not one. Analytics is about what users did. Crash reporting is about what broke. They often go to different vendors, and you'll want to swap one without touching the other.

Android: the easy side

On Android the implementation is a thin wrapper. Firebase is the obvious choice, though nothing here is Firebase-specific.

// androidMain
class FirebaseAnalyticsImpl(
    private val firebase: FirebaseAnalytics,
) : Analytics {

    override fun track(event: AnalyticsEvent) {
        val bundle = Bundle().apply {
            event.params.forEach { (k, v) -> putString(k, v) }
        }
        firebase.logEvent(event.name, bundle)
    }

    override fun setUserId(id: String?) {
        firebase.setUserId(id)
    }
}

class CrashlyticsReporter(
    private val crashlytics: FirebaseCrashlytics,
) : CrashReporter {

    override fun log(message: String) = crashlytics.log(message)

    override fun recordNonFatal(throwable: Throwable) =
        crashlytics.recordException(throwable)

    override fun setUserId(id: String?) {
        crashlytics.setUserId(id.orEmpty())
    }
}

Nothing clever. If the Android side is the only one you ever shipped, this is the code you already had.

iOS: the Swift bridge

The simplest iOS implementation doesn't call the Firebase iOS SDK from Kotlin at all. No expect/actual in this layer, no cinterop bindings, no CocoaPods dependency in the shared module.

The shared module defines the interface, and the iOS app passes in a Swift implementation at startup.

// iosApp
final class FirebaseAnalyticsBridge: Analytics {

    func track(event: AnalyticsEvent) {
        FirebaseAnalytics.Analytics.logEvent(event.name, parameters: event.params)
    }

    func setUserId(id: String?) {
        FirebaseAnalytics.Analytics.setUserID(id)
    }
}

Swift sees the Kotlin interface as a protocol, so conforming to it is ordinary Swift. The one snag is the name: Firebase's Swift class is also called Analytics, so inside this file the bare name is ambiguous. I qualify the Firebase one with its module. Renaming the Kotlin interface would also work, but I'd rather not let a vendor pick my names. The app registers it with the DI container before the first screen renders.

// commonMain/Telemetry.kt
fun setUpTelemetry(analytics: Analytics, crashReporter: CrashReporter) {
    // register both in your DI graph of choice
}

// iosApp
@main
struct IosApp: App {
    init() {
        TelemetryKt.setUpTelemetry(
            analytics: FirebaseAnalyticsBridge(),
            crashReporter: CrashlyticsBridge()
        )
    }
    // ...
}

I don't start that function name with init. The Objective-C export reserves init for initializers, so a Kotlin function called initTelemetry shows up in Swift as doInitTelemetry. It works, but it's the kind of thing that costs ten minutes the first time you see it.

The Firebase SDK stays where Xcode manages it. The shared module never learns it exists.

Two other ways to bring the SDK in

That Swift bridge is how I wrote this in my first KMP apps, and it's the version I'd explain to anyone starting out because every moving part is visible. It isn't what I use today.

GitLive's Firebase Kotlin SDK. firebase-kotlin-sdk from GitLive wraps Firebase so you can call it from commonMain. I haven't shipped it myself. If you use it, your Analytics interface still sits in front of it, otherwise you've just moved the vendor lock-in into shared code.

CocoaPods through Gradle, with the call in iosMain. This is what I use now. The Kotlin CocoaPods plugin lets the shared module declare the Firebase pod itself, and Kotlin generates the bindings so iosMain can call the iOS SDK directly.

// build.gradle.kts (shared module)
plugins {
    kotlin("multiplatform")
    kotlin("native.cocoapods")
}

kotlin {
    cocoapods {
        version = "1.0"
        ios.deploymentTarget = "16.0"
        pod("FirebaseAnalytics")
        pod("FirebaseCrashlytics")
    }
}

You can pin a version with pod("FirebaseAnalytics", "~> 12.0"), and linkOnly = true exists for pods you only need to link and not bind. The Kotlin docs cover both.

Then the iOS implementation is Kotlin, in the same module as the interface.

// iosMain
import cocoapods.FirebaseAnalytics.FIRAnalytics
import kotlinx.cinterop.ExperimentalForeignApi

@OptIn(ExperimentalForeignApi::class)
class IosAnalytics : Analytics {

    @Suppress("UNCHECKED_CAST")
    override fun track(event: AnalyticsEvent) {
        FIRAnalytics.logEventWithName(event.name, event.params as Map<Any?, *>)
    }

    override fun setUserId(id: String?) {
        FIRAnalytics.setUserID(id)
    }
}

The bindings come from the Objective-C headers, not the Swift API, so the class is FIRAnalytics and the method is logEventWithName. The parameters dictionary arrives as Map<Any?, *>?. A Map<String, String> doesn't fit that type as-is, because map keys are invariant in Kotlin, hence the cast.

I switched because the Swift bridge had a cost I only noticed over time: two files per interface, in two languages, in two repos' worth of mental context. With the pod declared in Gradle, the iOS implementation sits next to the Android one, in Kotlin, and a new method on Analytics fails the build in the same module.

It has its own cost. Pod dependencies and cinterop bindings are now part of your shared module's build, so Gradle sync and iOS builds feel it, and a Firebase SDK bump can break the generated bindings. It's also the option with an expiry date: the Kotlin docs now carry a CocoaPods-to-SwiftPM migration guide, and the new swiftPMDependencies { } block replaces cocoapods { }. The docs I read put the minimum Kotlin Gradle plugin at 2.4.20-RC3 for it, so check your version before planning the move. That's the trade I accept for keeping everything telemetry-related in one language.

I'm showing three options on purpose, and Firebase is only the example. A KMP project has more than one way to bring a native dependency in: a bridge the app injects, a KMP wrapper library, or a native dependency declared in Gradle. Which one fits depends on how much of the native SDK surface you need, and who maintains the glue.

Kotlin exceptions on iOS are not Kotlin exceptions

This is the part nobody mentions until you're staring at a dashboard.

When an uncaught Kotlin exception terminates the app on iOS, the crash is reported by the native crash handler. The stack trace is the native one. The Kotlin frames are there, but unsymbolicated Kotlin frames read as noise, and the exception type is flattened. Touchlab's CrashKiOS exists for exactly this: it sends symbolicated Kotlin crashes and handled exceptions to Crashlytics, with breadcrumbs and custom keys. Its docs page was last updated in January 2024, so check the repo for recent activity before you rely on it.

For non-fatal errors you have a better option. Catch the exception at a boundary you control, and hand it to recordNonFatal. On iOS that means converting it to an NSError, and that's where it gets fiddly.

Swift can't get much out of a KotlinThrowable by itself. The Kotlin stack trace accessor on Native, getStackTrace(), is a stdlib extension marked @ExperimentalNativeApi, so I don't count on it being reachable from Swift. I let Kotlin do the work instead, with two small extensions in iosMain.

// iosMain
fun Throwable.kotlinTypeName(): String =
    this::class.qualifiedName ?: "UnknownKotlinThrowable"

fun Throwable.kotlinStackTrace(): String = stackTraceToString()

They extend a Kotlin class, so the export turns them into methods on KotlinThrowable and Swift calls them like any other method.

// iosApp
final class CrashlyticsBridge: CrashReporter {

    func recordNonFatal(throwable: KotlinThrowable) {
        let error = NSError(
            domain: throwable.kotlinTypeName(),
            code: 0,
            userInfo: [
                NSLocalizedDescriptionKey: throwable.message ?? "unknown",
                "kotlin_stacktrace": throwable.kotlinStackTrace(),
            ]
        )
        Crashlytics.crashlytics().record(error: error)
    }

    func log(message: String) {
        Crashlytics.crashlytics().log(message)
    }

    func setUserId(id: String?) {
        Crashlytics.crashlytics().setUserID(id ?? "")
    }
}

Crashlytics turns userInfo into key-value pairs in the keys section of the issue, so the full Kotlin trace sits right there. I put it there on purpose rather than hoping the dashboard parses the message, because it won't.

The domain choice matters more than it looks. For fatal crashes Crashlytics groups by stack trace, but the Firebase docs say logged errors are grouped by domain and code. A fixed domain like "kotlin" with code 0 would collapse every non-fatal into one issue. With the Kotlin type there, an IllegalStateException and a network timeout stay separate. Keep unique values like user IDs or timestamps out of both fields, or you'll fragment the dashboard the other way. Crashlytics also only stores the most recent eight exceptions in a session, so recordNonFatal is not a log.

Where the calls go

The interface is only worth having if people use it in the same place. I let ViewModels own analytics events and nothing else.

// commonMain
class CheckoutViewModel(
    private val analytics: Analytics,
    private val crashReporter: CrashReporter,
    private val repository: CheckoutRepository,
) : ViewModel() {

    fun onPay(sku: String, amountCents: Long) {
        viewModelScope.launch {
            runCatching { repository.pay(sku, amountCents) }
                .onSuccess {
                    analytics.track(AnalyticsEvent.Purchase(sku, amountCents))
                }
                .onFailure {
                    if (it is CancellationException) throw it
                    crashReporter.recordNonFatal(it)
                }
        }
    }
}

The CancellationException check is there because runCatching catches it too. Without it, every user who leaves the screen mid-payment becomes a non-fatal in Crashlytics.

Composables and SwiftUI views don't call track. Screen views are the exception, and I fire them from a single navigation observer, so there's one line of code that produces every screen_view in the app.

The other benefit shows up in tests. A FakeAnalytics that stores events in a list takes ten lines, and asserting on it in commonTest is trivial. I used to skip testing analytics because it meant mocking an SDK. Now I assert that tapping Pay produces exactly one Purchase with the right amount, and it runs on every target.

Gotchas

Don't init the SDKs inside commonMain, whichever option you pick. Firebase on Android wants a Context. On iOS it wants FirebaseApp.configure() before anything else touches it. Those calls belong in Application.onCreate and the iOS App.init, not behind an abstraction that pretends the platforms are the same.

User IDs are a privacy decision, not a plumbing one. setUserId is easy to wire and easy to get wrong. I pass an internal opaque ID and never an email. Deciding that once, in the interface docs, beats hoping every caller remembers.

Consent has to be a gate, not a flag. If your users can opt out, wrap the implementation, not the call sites. A ConsentAwareAnalytics decorator that drops events when consent is off keeps the rule in one class. Crash reporting is different. setCrashlyticsCollectionEnabled can be called at runtime, but the Firebase docs say the override applies from the next launch, so a user who opts out mid-session is still reporting until the app restarts. Say that in your consent screen.

A debug build should not talk to production. I give the debug variant a LoggingAnalytics that prints to the console. It's another implementation of the same interface, which is the quiet argument for having the interface at all.

Wrapping up

Treat telemetry as a contract you own and a set of sensors you rent. The event names, the parameter keys, and the rule for what counts as a non-fatal live in commonMain, in code your compiler can check. The SDKs sit underneath, one per platform, and nobody outside the platform layer should know which ones.

I would still start with the interface even if the app only ships on one platform today. Adding iOS later then costs one Swift file instead of an audit of every event.

Same channel names, whatever the sensor. 🏁

The KMP Bits app is available on App Store and Google Play — built entirely with KMP.

How to Fix Firebase `PERMISSION_DENIED` Errors in React Native

Tue, 22 Sep 2026 12:05:03 +0000

If you are using Firebase with a React Native app, sooner or later you will probably run into something like this:

FirebaseError: [code=permission-denied]: Missing or insufficient permissions.

Or:

Error: PERMISSION_DENIED: Permission denied

And the annoying part is that the error does not tell you much.

It does not say:

Your Firestore rule on this collection is blocking the request.

It just tells you that Firebase rejected it.

That can happen for several different reasons. Your Firestore rules might be doing exactly what you told them to do, your user might not actually be authenticated, App Check might be involved, or your app might be connected to a different Firebase project than you think.

So before changing random rules until the error disappears, it is better to figure out why Firebase is rejecting the request.

First, find out which Firebase service is rejecting the request

PERMISSION_DENIED is not limited to Firestore.

You can see permission-related errors with services such as:

Cloud Firestore
Realtime Database
Firebase Storage
Firebase App Check
Firebase Authentication-related operations

So start by looking at the full error.

For example:

FirebaseError: [code=permission-denied]: Missing or insufficient permissions.

If the stack trace shows a Firestore operation such as:

firestore()
  .collection("users")
  .doc(userId)
  .get();

then your first place to look is Firestore security rules.

If the error happens while uploading a file, Storage rules are more relevant.

This sounds obvious, but a long React Native stack trace can make it easy to focus on the wrong part.

Check your Firestore security rules

If the error comes from Firestore, check your rules first.

For example, you might have:

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {

    match /users/{userId} {
      allow read, write: if request.auth != null;
    }
  }
}

This rule only allows authenticated users to access documents under:

/users/{userId}

If your app makes the request before the user has signed in, Firebase will reject it.

That can produce:

permission-denied

The important part is that Firebase is not necessarily malfunctioning here.

Your rule may simply be doing exactly what it was written to do.

Check whether the user is actually authenticated

One of the easiest mistakes is assuming that the user is signed in when the request runs.

For example:

const user = auth().currentUser;

console.log(user);

If that prints:

null

then there is no authenticated Firebase user at that moment.

A rule such as:

allow read, write: if request.auth != null;

will reject the request.

This can happen when your app starts up and immediately tries to read Firestore before Firebase Authentication has restored the user's session.

For example, you might have code that effectively does this:

const user = auth().currentUser;

firestore()
  .collection("users")
  .doc(user.uid)
  .get();

If user is not available yet, the request can fail.

Instead, make sure your application waits for the authentication state before making requests that require authentication.

With React Native Firebase, you can listen for authentication changes:

useEffect(() => {
  const unsubscribe = auth().onAuthStateChanged(user => {
    if (user) {
      // Safe to make requests that require authentication
    }
  });

  return unsubscribe;
}, []);

The exact structure depends on your app, but the idea is the same:

Do not assume authentication has finished restoring just because the app has started.

Check that the rule matches the path you are actually using

This is another very common one.

Imagine your rules contain:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

But your app actually accesses:

/profiles/123

That rule does not apply to /profiles/123.

You need a matching rule for the path being accessed.

This becomes especially confusing when you have nested collections.

For example:

/users/123/settings/theme

is not the same path as:

/users/123

Your rules need to match the actual document path.

If you are getting PERMISSION_DENIED, look at the exact collection and document your code is trying to access.

Do not assume the rule you are looking at is the one Firebase is evaluating.

Be careful with nested Firestore documents

Suppose you have:

users/{userId}/settings/{settingId}

You might write:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

and expect that to cover everything underneath the user.

It does not automatically mean that every nested document is covered.

You may need a recursive wildcard depending on the structure and rules you want.

For example:

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null;
}

Be careful with this kind of rule, though.

It can give access to much more data than you intended.

Do not add a broad wildcard just because it makes the error disappear.

Do not use `allow read, write: if true` as the final fix

You will sometimes see people recommend this while debugging:

allow read, write: if true;

Yes, it can make the permission error disappear.

It also allows anyone who can access your Firebase project from the client to read and write the matching data.

That is not a real fix.

If you temporarily use an open rule to confirm that the rules are the cause, put the secure rule back immediately afterward.

For example, if the app should only allow authenticated users:

allow read, write: if request.auth != null;

is very different from:

allow read, write: if true;

The goal is not simply to make Firebase stop complaining.

The goal is to make the rule match what your application is actually supposed to allow.

Check whether you are using the correct Firebase project

This one can waste a lot of time.

Your React Native app might be connected to a different Firebase project than the one you are looking at in the Firebase Console.

You think you are checking the rules for:

my-production-project

but the app is actually connected to:

my-development-project

Now you change rules in the console and nothing happens.

The app keeps returning:

permission-denied

because you are fixing the wrong project.

Check your Firebase configuration and make sure the project ID matches the Firebase project you are inspecting.

For Android, check the Firebase configuration used by your Android app.

For iOS, check the corresponding iOS Firebase configuration.

If you have development, staging, and production projects, this becomes especially important.

Check your Android and iOS Firebase configuration

If the problem only happens on one platform, compare the Firebase configuration between them.

For Android, make sure the correct Firebase configuration is being used.

For iOS, make sure the correct configuration is being used there as well.

A situation like this is possible:

Android → Firebase project A
iOS     → Firebase project B

You can then spend hours changing Firestore rules in project A while testing an iOS build that is actually talking to project B.

If the error happens only on Android or only on iOS, platform-specific Firebase configuration should be on your checklist.

Check Firebase App Check

App Check can also be involved when Firebase rejects requests.

App Check is designed to help verify that requests are coming from your legitimate app rather than an unauthorized client.

If you recently enabled App Check or changed its configuration, check whether the failing request is related to App Check.

This becomes especially important if:

the app worked before enabling App Check
requests work in one environment but not another
you are testing a development build
you changed App Check enforcement settings
you changed the app's Android or iOS configuration

Do not immediately disable App Check just because it is involved.

First determine whether the request is failing because of App Check configuration or because of your Firestore/Storage rules.

Those are different problems.

Development and production can behave differently

A common source of confusion is:

"It works in development, but my production build gets PERMISSION_DENIED."

That does not necessarily mean the Firebase rules randomly changed.

Your development and production builds may be using different:

Firebase projects
application IDs
bundle identifiers
configuration files
App Check settings
authentication settings
environment variables

If the problem only happens in a release build, compare the Firebase configuration between the working and failing builds.

This is usually more useful than changing your Firestore rules blindly.

Check the exact user ID being used

Suppose your rule is intended to allow users to access their own documents:

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
}

That means this request:

/users/123

will only work if:

request.auth.uid == "123"

If your application accidentally requests:

/users/456

while the logged-in user is actually 123, Firebase will reject it.

So log the values you are using while debugging:

console.log("Current user:", auth().currentUser?.uid);
console.log("Requested user:", userId);

If they do not match, you have found the problem.

This is much more useful than changing the security rule to allow everyone.

Check your Storage rules if the error happens during uploads

If the problem happens while uploading an image, PDF, or another file, you may actually be dealing with Firebase Storage rather than Firestore.

For example:

FirebaseError: [storage/unauthorized] User is not authorized to perform the desired action.

Storage has its own security rules.

A Firestore rule like:

allow read, write: if request.auth != null;

does not control Firebase Storage.

If the error happens during:

storage()
  .ref("profile-images/avatar.jpg")
  .putFile(filePath);

look at your Storage rules instead.

The service producing the error matters.

Check Realtime Database rules separately

The same idea applies to Realtime Database.

Realtime Database has its own rules structure, for example:

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

Changing Firestore rules will not fix a Realtime Database permission problem.

If your application uses several Firebase services, make sure you know which one is rejecting the request before changing anything.

Use the Firebase Emulator when appropriate

If you are working on complicated security rules, the Firebase Emulator Suite can make debugging much easier.

Instead of repeatedly testing rules against production data, you can test your rules locally.

This is especially useful when your rules depend on things like:

request.auth
request.auth.uid
request.resource.data
resource.data

For example, a rule might look correct at first glance but fail because the incoming document does not contain the field your rule expects.

Testing the rule with known authentication and data values makes these problems much easier to see.

Look at what changed right before the error

This is one of the most useful debugging habits for Firebase errors.

Ask:

What changed immediately before PERMISSION_DENIED appeared?

Maybe you:

changed Firestore rules
added authentication
changed the user document structure
switched Firebase projects
enabled App Check
changed an Android package name
changed an iOS bundle identifier
updated a Firebase dependency
moved a Firestore collection
changed the document ID
created a new production build

The timing does not prove what caused the error, but it gives you a very good place to start.

A simple debugging order

When I get a Firebase PERMISSION_DENIED error, I usually go through these checks:

1. Identify the Firebase service

Is it:

Firestore?
Storage?
Realtime Database?
App Check?
something else?

2. Read the exact path

What collection, document, or storage path is the app trying to access?

3. Check authentication

console.log(auth().currentUser?.uid);

Is there actually a logged-in user?

4. Check the security rule

Does the rule actually match the path being accessed?

5. Check the values used by the rule

If the rule compares user IDs, roles, or document fields, verify those values.

6. Check the Firebase project

Make sure the app and Firebase Console are using the same project.

7. Check App Check

Especially if the problem started after enabling or enforcing it.

8. Check platform-specific configuration

If only Android or iOS is affected, compare the configuration for that platform.

9. Reproduce the problem again

After making one change, test again.

This gives you a much clearer debugging trail.

Example: finding a simple rules mistake

Imagine your Firestore rule says:

match /users/{userId} {
  allow read: if request.auth != null
               && request.auth.uid == userId;
}

Your app is logged in as:

abc123

but your code requests:

/users/undefined

Firebase sees:

request.auth.uid == "abc123"

and:

userId == "undefined"

The condition is false.

So Firebase returns:

permission-denied

The problem is not Firebase.

The problem is that your application generated the wrong document path.

This is why checking the exact request is so important.

Final thoughts

PERMISSION_DENIED can be frustrating because the error itself is often very short while the number of possible causes is not.

The important thing is to avoid treating it as simply:

"Firebase permissions are broken."

Start by finding out which Firebase service rejected the request, then check the exact path, authentication state, security rules, and Firebase project.

If the error appeared after a recent change, use that as a clue.

And avoid the temptation to solve everything with:

allow read, write: if true;

That only hides the real problem and can leave your data exposed.

If your error is buried inside a much larger React Native/Firebase log and it is difficult to tell whether the problem is authentication, rules, App Check, configuration, or something else, you can paste the full error into FixMyError and use it to narrow down what is actually going wrong.

Try it at https://www.fixmyerrorapp.com.

The Firebase Auth bug that took me 3 days to find (it wasn't Firebase's fault)

Sat, 19 Sep 2026 08:24:54 +0000

The symptom

signInWithRedirect would fire fine — the Google popup flow completed, the redirect came back, and then... nothing. auth.currentUser was null. No error in the console. No failed network request. The user object had just vanished somewhere between the redirect and my app reading it.

The frustrating part: it worked perfectly on localhost. It only broke in production.

The wrong turns

First guess: async timing bug. I wrapped the auth-state check in every useEffect variation I could think of, added loading states, tried onAuthStateChanged instead of reading currentUser directly. No change.

Second guess: a config mismatch. I diffed my Firebase config between local and prod character by character. Identical.

Third guess: CORS. Checked network tab, no CORS errors, no failed requests at all — which in hindsight should have been the clue. A CORS problem fails loudly. This was failing silently.

What was actually happening

Firebase's redirect-based auth flow works by briefly using an iframe on your authDomain (typically your-project.firebaseapp.com) to relay the session back to your app. That relay depends on third-party storage being accessible inside that iframe — cookies/localStorage set on firebaseapp.com, read while your actual site is on a different domain.

Browsers have been steadily tightening third-party storage partitioning (Safari's been strict about this for years, Chrome's been catching up). Production was on my real custom domain. Local dev was hitting localhost, which a lot of browsers still treat more permissively. That's why it "worked" locally and silently died in prod — the iframe's storage access was just being partitioned away, and Firebase had no clean way to surface that as an error since, from its perspective, the browser just... didn't return anything.

The fix

Switch to signInWithPopup instead of signInWithRedirect. Popup-based auth doesn't rely on that same cross-domain iframe storage relay — the popup and the opener communicate directly, sidestepping the whole partitioning problem.

// Before: silently broke in production
await signInWithRedirect(auth, provider);

// After: works consistently across browsers
await signInWithPopup(auth, provider);

Trade-off: popups get blocked more aggressively on mobile and by some ad blockers, so it's not a strictly-better default — just a better fit for what was actually failing here.

The lesson

When something works locally and silently fails in production with zero error output, my new first suspect is cross-origin storage behavior, not application logic. Silent failure is often the browser deciding not to tell you it blocked something, rather than your code doing something wrong.

Anyone else hit this exact wall with Firebase (or any auth provider using a similar iframe-relay pattern)? Curious if others landed on popup, or found a way to keep redirect working reliably.

How I Structured My Firestore Data Model for an Anti-Proxy Attendance System

Thu, 03 Sep 2026 04:12:28 +0000

The database architecture behind students, meetings, attendance, authentication, and controlling unnecessary Firestore reads.*

How I Structured My Firestore Data Model for an Anti-Proxy Attendance System

When I began building my attendance system, database architecture wasn't really my first concern.

I had one straightforward objective:

Make the MVP work.

I needed a place to store students.

I needed a way to create meetings.

I needed to save attendance records.

So I started creating Firestore data structures based on whatever the application needed at that moment.

Initially, that approach worked.

Then the application started expanding.

Authentication was introduced.

Dynamic QR authentication was introduced.

Device verification was introduced.

Attendance history was introduced.

Offline synchronization was introduced.

And suddenly, Firestore was doing much more than simply holding attendance records.

It was turning into the foundation that the rest of the application depended on.

That's when an important realization hit me:

A schema that is perfectly fine for an MVP may not remain suitable once the application starts growing.

The First Question: What Really Needs to Live in the Database?

An attendance system sounds straightforward until you actually list everything it needs to keep track of.

For every attendance event, I may need details such as:

The student
The meeting
The attendance status
The time the attendance was recorded
Authentication information
Device information
Synchronization state
Administrative information

The difficult part wasn't simply finding a place to store all of these things.

The harder problem was determining how all of these pieces should connect with one another.

I started looking at the database through the entities that actually existed inside the system.

Student
   │
   ├── Identity
   ├── Device
   └── Attendance
          │
          ▼
        Meeting
          │
          ├── QR Session
          └── Attendance Records

The database needed to represent these relationships without making the application repeatedly retrieve the same information.

Firestore Forces a Different Way of Thinking

Firestore doesn't work like a traditional relational database.

There are no conventional SQL joins where I can simply write something like:

SELECT ...
FROM students
JOIN attendance ...
JOIN meetings ...

Instead, I need to think about a different question:

Which pieces of data does the application need to access together?

That question became one of the most important considerations while designing the schema.

In Firestore, the structure of your data directly influences how much information the application has to retrieve.

And I had already experienced the consequences of getting that wrong.

I Still Remember the 50,000 Read Problem

Earlier during development, I accidentally burned through my Firestore free-tier reads while testing and debugging the application.

That experience completely changed the way I looked at database operations.

Before that happened, my thinking was basically:

"It's just one additional read."

Afterwards, my question became:

"Does the application actually need this read?"

That shift in mindset started influencing the database architecture as the project continued to evolve.

Designing Around Actual Access Patterns

Rather than beginning with:

"Which collections should I create?"

I started approaching the problem from the opposite direction:

"What information does the application actually need to retrieve?"

For example, when an attendance session is running, the system needs enough information to validate the request and then record the attendance correctly.

So the database has to support operations such as:

Create Meeting
      ↓
Generate Attendance Session
      ↓
Validate Student
      ↓
Validate Device
      ↓
Validate QR
      ↓
Record Attendance

The database should not become the thing slowing down every stage of the process.

Keeping Attendance as a Separate Record

One of the key decisions I made was to treat attendance as its own record rather than repeatedly changing a student's profile whenever they attend a meeting.

Conceptually, the relationship looks like this:

Student
   │
   └──────────────┐
                  │
                  ▼
              Attendance
                  │
                  ▼
                Meeting

This allows attendance history to exist separately from the student's core profile.

Instead of only asking:

"Is this student present?"

the system can answer a much more useful question:

"Was this student present for this particular meeting, and when exactly was that attendance recorded?"

That distinction is important.

Attendance represents an event, rather than simply being a permanent property attached to a student.

More Data Does Not Automatically Mean a Better Database

A common trap during database design is duplicating information everywhere because it makes individual queries feel easier.

At first, that can seem convenient.

The problem appears later when those duplicated values need to stay consistent.

For example, copying the same information into several documents may simplify one specific query, but now the application has to maintain multiple versions of the same data.

So I constantly found myself balancing:

Fast reads

against

Data duplication

against

Write complexity

against

Firestore usage

There isn't one universal answer that solves all of these concerns.

The right decision depends on how the application actually reads and writes the data.

What an Attendance Request Actually Contains

At a high level, an attendance request now carries several different pieces of context.

Attendance Request
       │
       ├── Student Identity
       │
       ├── Meeting
       │
       ├── QR Validation
       │
       ├── Device Verification
       │
       └── Attendance Record

So attendance isn't really just:

student → present

It's closer to:

student
   +
meeting
   +
valid session
   +
trusted device
   +
validated request
   =
attendance

That means the database is not merely a storage layer.

It becomes part of the security architecture as well.

Thinking Carefully About Reads and Writes

After experiencing the 50,000-read issue, I started paying much more attention to the difference between reads and writes.

A system can function correctly and still perform far more database operations than it actually needs.

For example:

Page Load
   ↓
Read Student
   ↓
Read Meeting
   ↓
Read Configuration
   ↓
Read Student Again
   ↓
Read Meeting Again

Nothing is technically failing here.

But the application is doing unnecessary work.

So I started looking for ways to:

Reuse information that the application already has
Eliminate repeated reads
Cache frequently accessed information
Minimize unnecessary writes
Fetch only the data that is actually required

This eventually became part of the larger optimization work I covered in Part 3.

Firestore Security Goes Beyond Security Rules

Another lesson from the project was that database security cannot be reduced to Firestore Security Rules alone.

Rules are important.

But they represent only one layer of the overall security model.

In my attendance system, validation happens across several stages:

User Authentication
        ↓
Dynamic QR Validation
        ↓
Device Verification
        ↓
Backend Validation
        ↓
Firestore
        ↓
Attendance Record

The database should never blindly trust whatever information the frontend submits.

The backend needs to validate the request before writing sensitive attendance information.

This separation became even more important as more anti-proxy mechanisms were introduced into the system.

Offline Support Changes the Data Lifecycle

Then another challenge appeared.

Offline support.

Once the system could record attendance without immediately communicating with Firestore, the data model needed to distinguish between two different states:

Attendance created locally

and

Attendance successfully synchronized

Conceptually, the lifecycle became:

Student
   ↓
Attendance Event
   ↓
Local Storage
   ↓
Pending Sync
   ↓
Firestore
   ↓
Synchronized

That meant the lifecycle of an attendance record was no longer simply:

Create → Save

It became:

Create
  ↓
Store locally
  ↓
Wait
  ↓
Synchronize
  ↓
Confirm

That changed the way I thought about reliability as well.

What I Would Avoid Doing

One of the clearest lessons from this project is that Firestore schemas should not be designed by blindly copying relational database patterns.

Firestore has its own strengths, limitations, and way of handling data.

Instead of asking:

"How would I structure this in MySQL?"

I found it much more useful to ask:

"What are the operations my application performs most often?"

Then I could design the data model around those access patterns.

That single shift in perspective made the database design much easier to reason about.

The Bigger Lesson From the Data Model

At the beginning, the database felt like infrastructure.

Something beneath the actual application.

But as the system became more complex, I realized that the data model affects almost every major part of the application:

Performance
Cost
Security
Offline synchronization
Backend architecture
Query complexity
Scalability

A poor data model doesn't necessarily cause an obvious failure on day one.

Sometimes the problem is much quieter.

It simply makes every new feature a little harder to build.

And that can become a much bigger problem over time.

What I Would Change Today

If I were starting this system again today, I would spend considerably more time thinking about the data model before implementing features.

I'd define:

Entities
   ↓
Relationships
   ↓
Access Patterns
   ↓
Read / Write Frequency
   ↓
Caching Strategy
   ↓
Security Boundaries

before writing the first database query.

I learned this lesson after the system was already functioning.

Building first showed me what the application genuinely needed.

But if I rebuilt it from scratch, I'd bring those lessons into the design phase much earlier.

Final Thoughts

The original requirement sounded simple:

"I just need somewhere to store attendance."

Over time, that requirement evolved into something much larger:

"I need a data architecture that can support authentication, dynamic QR validation, device verification, offline synchronization, and efficient reads and writes."

Those are two completely different problems.

And probably one of the biggest lessons this project gave me is that database design isn't simply about deciding where data should be stored.

It's about defining how the entire application communicates with that data.

The database isn't simply sitting underneath the architecture.

It is part of the architecture.

What's Next?

The database was only one part of the overall system.

The next challenge was infrastructure.

My backend was running on a free-tier service, and that introduced another constraint that became difficult to ignore:

cold starts.

Which raised another question:

How do you make a slow backend feel fast from the user's perspective?

That's the problem I'll explore next.

🔗 Project

GitHub:

https://github.com/siddarthpatelkama/UBA-veltech-attendance-system

💬 Your turn

If you've built a Firestore application before, what's one database decision you made early that later saved you from dealing with a much bigger problem?

I'd love to hear about it.

Supabase Auth vs Firebase Auth: Which One Should You Choose in 2026?

Thu, 20 Aug 2026 10:26:22 +0000

You're starting a new Next.js project, and before you write a single feature, you have to answer one boring but critical question: who's going to handle login?

Two names keep showing up at the top of every list — Supabase Auth and Firebase Auth. Both are free to start, both support Google/GitHub/email login, and both promise to save you from writing your own password-hashing logic. But they're built on completely different foundations, and picking the wrong one can mean months of awkward workarounds later — like discovering you need SQL joins for a permissions system, but you're stuck with Firestore's document model.

This guide breaks down exactly how Supabase Auth and Firebase Auth differ in 2026 — architecture, pricing, security, and real Next.js 16 App Router code for both — so you can pick the right one before you've built half your app on top of it.

Why This Comparison Is Tricky

Most "Supabase vs Firebase" posts compare marketing pages, not real implementation experience. The truth is these two products solve authentication very differently under the hood:

Supabase Auth is a layer on top of PostgreSQL — every user lives in a real SQL table (auth.users), and permissions are enforced with Row Level Security (RLS) policies written in SQL.
Firebase Auth is a layer on top of Firestore/Google Cloud — users live in Google's own auth system, and permissions are enforced with Firestore Security Rules, a completely different (non-SQL) rules language.

That single architectural difference is what actually decides which one fits your project — not the login form UI, which looks nearly identical on both.

Quick Answer

Choose Supabase Auth if you want a real Postgres database, SQL-based permissions (RLS), open-source flexibility, and the option to self-host later.
Choose Firebase Auth if you're already invested in Firebase or Google Cloud services, or if Firebase's managed identity infrastructure fits your application's architecture.

Now let's get into the details.

Supabase Auth vs Firebase Auth: Which Is Better for Next.js?

If you're building a Next.js SaaS application with PostgreSQL, Supabase Auth is usually the more natural choice because authentication, database access, and authorization can be designed around the same Postgres/RLS model.

Firebase Auth is a better fit when your application already uses Firebase/Google Cloud services or your data model naturally fits Firestore.

Supabase Auth vs Firebase Auth: Feature Comparison

Feature	Supabase Auth	Firebase Auth
Authentication architecture	Integrated with Supabase/PostgreSQL ecosystem	Managed identity service
Common database pairing	PostgreSQL	Firestore (NoSQL)
Free/no-cost auth tier	50,000 monthly active users (MAU)	Depends on Firebase Auth / Identity Platform configuration
Paid pricing	Included in Supabase plan quota; $0.00325/MAU over Pro quota	Identity Platform: 50,000 MAU no-cost tier on Blaze, then usage-based pricing
Email/password	✅	✅
Magic links	✅	✅ (email link sign-in)
Social OAuth (Google, GitHub, etc.)	✅	✅
Phone/SMS OTP	✅	✅
Permissions model	Row Level Security (SQL policies)	Firestore Security Rules (custom rules language)
Self-hosting	✅ Yes (fully open source)	❌ No
Open source	✅ Yes	❌ No
Next.js SSR package	`@supabase/ssr`	Firebase JS SDK + `initializeServerApp`
Best paired with	Postgres-based SaaS apps	Google Cloud / Firestore apps

💡 Tip: Both platforms' free tiers are generous enough to cover most side projects and early-stage SaaS apps completely — pricing usually isn't the deciding factor until you're well past MVP stage.

Architecture: The Real Difference

This is the part most comparison articles skip, and it's the one that actually matters.

Supabase Auth Runs on Postgres

When someone signs up with Supabase Auth, a row gets created in a special auth.users table inside your actual Postgres database. Every other table you create — profiles, posts, orders — can have a foreign key pointing straight at auth.users.id.

That means your permissions logic is just SQL:

-- Only let a user see their own orders
create policy "Users can view own orders"
on orders
for select
using (auth.uid() = user_id);

Why this matters: if your app has relational data — a user has many orders, an order has many line items, a team has many members — Postgres joins handle that naturally. You're not fighting the database to model relationships.

Firebase Auth And Firestore

Firebase Auth manages identity separately from your application data. When paired with Firestore, authorization is commonly enforced using Firestore Security Rules — a rules language, not SQL:

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /orders/{orderId} {
      allow read: if request.auth != null && request.auth.uid == resource.data.userId;
    }
  }
}

Why this matters: Firestore is a document database. There's no native JOIN. If your data is deeply relational (think: multi-tenant SaaS with teams, roles, and shared resources), you'll end up duplicating data across documents or running multiple round-trip queries to stitch things together client-side.

💡 Tip: Neither model is "wrong" — Firestore's document model is genuinely great for chat apps, real-time feeds, and simple per-user data. Postgres shines once your data has real relationships between tables.

Setting Up Supabase Auth in Next.js 16

This guide assumes Next.js 16 with the App Router, TypeScript in strict mode, and Tailwind CSS — the current defaults for any new Next.js project.

Step 1: Install Dependencies

npm install @supabase/supabase-js @supabase/ssr

What's happening here: @supabase/supabase-js is the core client library. @supabase/ssr is the package built specifically for frameworks like Next.js — it handles the tricky part of syncing auth cookies between the browser and the server so your session works correctly in Server Components, Server Actions, and the browser alike.

Step 2: Add Environment Variables

# .env.local
NEXT_PUBLIC_SUPABASE_URL=https://yourproject.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your_publishable_key

⚠️ Never expose a Supabase secret key (sb_secret_...) or legacy service_role key in client-side code. Both bypass RLS.

💡 Tip: For new Supabase projects, use the publishable key rather than the legacy anon key. Supabase is transitioning away from the legacy API keys during 2026.

Step 3: Create the Browser Client

// lib/supabase/client.ts
import { createBrowserClient } from "@supabase/ssr";

export function createClient() {
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );
}

Use this inside Client Components — anywhere you need "use client".

Step 4: Create the Server Client

// lib/supabase/server.ts
import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Safe to ignore when called from a Server Component
          }
        },
      },
    }
  );
}

What's happening here: this client reads and writes auth cookies through Next.js's cookies() API, so a session created during login is visible to Server Components and Server Actions immediately — no manual token passing needed.

Step 5: Add the Auth Proxy (Middleware)

// utils/supabase/proxy.ts
import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet, headers) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          );
          supabaseResponse = NextResponse.next({ request });
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );
          Object.entries(headers).forEach(([key, value]) =>
            supabaseResponse.headers.set(key, value)
          );
        },
      },
    }
  );

  await supabase.auth.getClaims();

  return supabaseResponse;
}

// proxy.ts (root of project)
import { type NextRequest } from "next/server";
import { updateSession } from "@/utils/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

⚠️ Common Mistake: Skipping this proxy file. Without it, Supabase's refresh token doesn't get renewed on every request, and users get randomly logged out mid-session — one of the most common Supabase Auth bugs beginners hit.

// actions/auth.ts
"use server";

import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";

export async function login(prev: unknown, formData: FormData) {
  const supabase = await createClient();

  const { error } = await supabase.auth.signInWithPassword({
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  });

  if (error) {
    return { error: error.message };
  }

  redirect("/dashboard");
}

Step 7: Protect Data with Row Level Security

This is Supabase Auth's biggest advantage — security lives at the database level, not just in your app code:

alter table profiles enable row level security;

create policy "Users can view own profile"
on profiles for select
using ((select auth.uid()) = id);

create policy "Users can update own profile"
on profiles for update
using ((select auth.uid()) = id)
with check ((select auth.uid()) = id);

Why this matters: even if someone bypasses your Next.js app entirely and hits the Supabase API directly, RLS still blocks them from seeing data that isn't theirs. Your frontend code stops being the only line of defense.

💡 If you're using Supabase Auth with multiple tables, writing RLS policies manually can become repetitive. DevStacked's Supabase RLS Policy Generator can generate strict policies based on your access pattern.

Setting Up Firebase Auth in Next.js 16

Step 1: Install Dependencies

npm install firebase firebase-admin

What's happening here: firebase is the client SDK (runs in the browser and in Server Components via Firebase's newer server app support). firebase-admin is for privileged, server-only operations like verifying tokens.

Step 2: Add Environment Variables

# .env.local
NEXT_PUBLIC_FIREBASE_API_KEY=your_api_key
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=yourproject.firebaseapp.com
NEXT_PUBLIC_FIREBASE_PROJECT_ID=yourproject

Step 3: Initialize Firebase (Client Side)

// lib/firebase/client.ts
import { initializeApp, getApps, getApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
};

const app = getApps().length ? getApp() : initializeApp(firebaseConfig);

export const auth = getAuth(app);

What's happening here: getApps().length ? getApp() : initializeApp(...) prevents Firebase from being re-initialized on every hot reload in development — a classic Firebase + Next.js gotcha if you skip this check.

// components/login-form.tsx
"use client";

import { signInWithEmailAndPassword } from "firebase/auth";
import { auth } from "@/lib/firebase/client";
import { useRouter } from "next/navigation";
import { useState } from "react";

export function LoginForm() {
  const router = useRouter();
  const [error, setError] = useState("");

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const form = new FormData(e.currentTarget);

    try {
      await signInWithEmailAndPassword(
        auth,
        form.get("email") as string,
        form.get("password") as string
      );
      router.push("/dashboard");
    } catch (err) {
      setError(err instanceof Error ? err.message : "Login failed");
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="email" type="email" required />
      <input name="password" type="password" required />
      <button type="submit">Sign in</button>
      {error && <p>{error}</p>}
    </form>
  );
}

⚠️ Common Mistake: Doing all your auth logic client-side and assuming that's enough for SSR. Firebase's client SDK doesn't automatically make the logged-in user visible to your Next.js Server Components — you need a separate step to bridge that gap (next).

Step 5: Bridge the Session to the Server

Firebase's newer Firebase Server App feature lets you read the authenticated user inside Server Components:

// lib/firebase/server.ts
import { cookies } from "next/headers";
import { initializeApp, initializeServerApp } from "firebase/app";
import { getAuth } from "firebase/auth";

export async function getAuthenticatedAppForUser() {
  const authIdToken = (await cookies()).get("__session")?.value;

  const firebaseServerApp = initializeServerApp(initializeApp(), {
    authIdToken,
  });

  const auth = getAuth(firebaseServerApp);
  await auth.authStateReady();

  return { firebaseServerApp, currentUser: auth.currentUser };
}

Learn more Firebase Server App here

What's happening here: the client sets a __session cookie containing the Firebase ID token after login (you write this cookie yourself, typically via a small API route or onIdTokenChanged listener). The server then rebuilds an authenticated Firebase app instance from that cookie — this is meaningfully more manual than Supabase's @supabase/ssr package, which handles cookie syncing for you out of the box.

Note: This example demonstrates the server-side bridge rather than a complete production session-cookie implementation. In production, use a secure HTTP-only session cookie and validate it server-side.

⚠️ Common Mistake: Assuming Firebase Auth "just works" with Server Components the way it works with a client-only SPA. The App Router's server/client split means you need this extra bridging step — it's the single biggest source of Firebase + Next.js App Router complaints online.

Step 6: Protect Data with Firestore Security Rules

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /profiles/{userId} {
      allow read, update: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Firestore rules are enforced server-side by Google's infrastructure, similar in spirit to RLS — but written in a proprietary rules language instead of SQL, so there's a real learning curve if your team already knows SQL but not Firestore's rule syntax.

Pricing Comparison

	Supabase Auth	Firebase Auth
Free tier	50,000 MAU	Depends on Firebase Auth / Identity Platform configuration
Paid tier	Included in Supabase plan quota; additional MAU billed after quota	Usage-based pricing with Identity Platform
Self-hosting	✅ Available	❌ Not available

Both platforms offer generous options for early-stage projects, although the exact limits and pricing depend on the plan and services you use. The real cost difference shows up later: Supabase gives you a self-hosting escape hatch if you ever want to leave the MAU pricing model entirely; Firebase does not.

Security Considerations for Both

Regardless of which you choose, keep these in mind for Next.js 16:

Never trust client-side auth checks alone. Whether you're using Supabase or Firebase, always re-verify the session inside Server Actions and Route Handlers — a hidden button in the UI doesn't stop a direct API call.
proxy.ts (formerly middleware.ts) is a UX nicety, not your security boundary. Both Supabase's session refresh and any Firebase token check you add there can be bypassed by calling your backend directly — the real gate is the check inside your Server Action or database rule.
Default new users to the lowest-privilege role. Never let a signup form set its own role or is_admin field — assign it server-side.

When Should You Use Supabase Auth?

You want a real relational database (Postgres) under your app, not just auth.
Your app has complex relationships — teams, roles, shared resources, multi-tenancy.
You want the option to self-host later, or you like knowing you could.
You're already comfortable with SQL, or want to learn it.

When Should You Use Firebase Auth?

You're already using Firestore, Cloud Functions, Firebase Cloud Messaging, or Google Analytics.
Your data model is simple and document-shaped (a user has a profile, a handful of settings — no deep relational joins).
You want Google's massive scale and long production track record specifically for mobile + web apps together.
Your team already knows Firestore Security Rules.

Decision Table

If you need...	Better choice
Next.js + PostgreSQL	🟢 Supabase
SQL + relational data	🟢 Supabase
RLS-based authorization	🟢 Supabase
Self-hosting	🟢 Supabase
Firestore	🟢 Firebase
Firebase ecosystem	🟢 Firebase
Google Cloud integration	🟢 Firebase
Mobile + web Firebase stack	🟢 Firebase
Complex relational SaaS	🟢 Supabase
Document-oriented data	🟢 Firebase

Frequently Asked Questions

Can I switch from Firebase Auth to Supabase Auth later?

Yes, but it's real migration work. You'll need to migrate users and identities, account for password-hash compatibility and provider configuration, and rebuild authorization rules from your Firebase/Security Rules model into Supabase RLS.

Which one is easier for a complete beginner?

Firebase Auth's client-only setup (no SSR bridging) is slightly faster to get a basic login working. But Supabase Auth's @supabase/ssr package makes Next.js App Router integration smoother once you add server-side checks, which almost every real app eventually needs.

Yes — Supabase Auth supports Google, GitHub, Apple, Discord, and dozens of other OAuth providers, configured directly from the Supabase dashboard with no extra backend code required.

Is Firebase Auth open source?

No. Firebase Auth is a fully managed Google Cloud service — you can't self-host it or inspect its internals. Supabase Auth (part of the broader Supabase platform, built on the open-source GoTrue project) is open source and can be self-hosted.

Do I need Row Level Security if I'm already checking auth in my Next.js code?

RLS protects your database from application-level mistakes and direct client access, but it does not protect against misuse of a secret/service-role key because those elevated keys bypass RLS.

Wrapping Up

Supabase Auth and Firebase Auth both get you a working login system fast — the real decision comes down to what's underneath: a relational Postgres database with SQL-based security, or Firestore's document model with Google's rules language. If your app has real relationships between users, teams, and data, Supabase's Postgres foundation will save you pain down the road. If you're already deep in the Google Cloud ecosystem, Firebase Auth keeps everything under one roof.

Whichever you pick, remember the same rule applies to both: UI checks are for user experience, and server-side/database-level checks are your actual security boundary.

Continue Learning

Helpful Free Tools

Supabase RLS Policy Generator — generate strict, pattern-specific Row Level Security policies in seconds instead of hand-writing SQL.
Zod Schema Generator — generate validated schemas for your auth forms straight from JSON or TypeScript, including a ready-to-use Server Action.

When 50,000 Firestore Reads Forced Me to Rethink My Attendance System

Fri, 24 Jul 2026 18:32:03 +0000

How an unexpected database limit led me to build an offline-first anti-proxy attendance system.

Introduction

When I started building an attendance system for my university's UBA (Unnat Bharat Abhiyan) club, I had one clear instruction from our coordinator:

"Build an MVP as soon as possible."

So I did what most student developers would do. I focused on shipping features instead of watching dashboards.

Every new feature meant refreshing pages, testing authentication, creating meetings, scanning QR codes, fixing bugs, and repeating the same workflow again and again.

I was so focused on making the system work that I never noticed something else happening in the background.

Every debug session was consuming Firestore reads.

The Day Everything Stopped Working

After several hours of development, it was finally time to demonstrate the MVP.

Everything looked ready.

The QR authentication worked.

Meetings could be created.

Students could scan codes.

Then the application suddenly stopped communicating with Firestore.

At first, I thought I had introduced a bug.

I checked my code.

Nothing seemed wrong.

A few minutes later, I found the real culprit.

I had unknowingly exhausted Firestore's free-tier quota of 50,000 document reads.

Not because of production traffic.

Not because thousands of students were using it.

Simply because I had been debugging the application so much.

That moment completely changed how I thought about the project.

Waiting Wasn't an Option

The easiest solution would have been to wait for the quota to reset.

But this wasn't just another side project.

The attendance system had to work during meetings.

If the database became unavailable, attendance couldn't simply stop.

So instead of asking:

"How do I reduce Firestore reads?"

I asked a different question.

"How can the application continue working even if Firestore becomes unavailable?"

That single question changed the architecture of the project.

Building an Offline-First Attendance System

The obvious answer was offline support.

But attendance systems aren't ordinary CRUD applications.

They also have to prevent proxy attendance.

Moving offline couldn't mean compromising security.

So the offline mode had to preserve the same guarantees as the online system.

The application needed to:

Continue recording attendance without Firestore.
Prevent duplicate submissions.
Maintain anti-proxy validation.
Store attendance securely until synchronization.
Upload records once connectivity or database access returned.

Instead of treating offline mode as a backup feature, it became a core part of the system's architecture.

Solving One Problem Revealed Another

The offline architecture solved the immediate issue.

But I still wasn't happy.

The original problem hadn't really been "no internet."

It was inefficient database usage.

So I started reviewing every interaction with Firestore.

Questions I hadn't asked before suddenly became important.

Do I really need this read?
Can this data be cached?
Can multiple requests be combined?
Why am I fetching the same document repeatedly?

I realized that improving resilience wasn't enough.

The system also needed to become more efficient.

Reducing Firestore Reads

Once the MVP was stable again, I began optimizing the backend.

Some of the improvements included:

Reducing unnecessary document reads.
Avoiding repeated requests for unchanged data.
Caching frequently accessed information using Render's free cache.
Optimizing database queries.
Reducing redundant writes wherever possible.

None of these optimizations changed the features users saw.

But together, they significantly reduced the load on Firestore and made the application far more sustainable on the free tier.

What This Experience Taught Me

Looking back, exhausting Firestore's free-tier quota was frustrating.

But it also forced me to think like a software engineer rather than just a programmer.

I stopped asking:

"How do I make this feature work?"

and started asking:

"How do I make this system keep working when one of its dependencies fails?"

That shift in mindset led to a better architecture than the one I originally planned.

Sometimes the best engineering decisions aren't made during planning.

They're made when reality breaks your assumptions.

Final Thoughts

The attendance system I set out to build was meant to prevent proxy attendance.

The system I ended up building also learned how to survive database limits, continue operating offline, and make smarter use of backend resources.

Running out of Firestore reads became one of the most valuable debugging sessions of the entire project.

💬 I'd love to hear your thoughts.

Have you ever hit a free-tier limit or an unexpected infrastructure constraint that completely changed your system design? Share your experience in the comments.

Demystifying the Ghost Failure in Firebase Hosting GitHub Actions

Thu, 02 Jul 2026 05:48:04 +0000

Imagine your pipeline throwing a red error badge, yet your production application reflects fresh updates perfectly. This exact scenario confuses countless developers utilizing the official Firebase Extended GitHub Action. The workflow crashes with a cryptic warning message stating that the supplied version is the current active version, casting doubt on your continuous deployment pipeline reliability.

Redundant Release Triggers:

The pipeline triggers file hashing and bundles content assets accurately, uploading them to Firebase storage infrastructure seamlessly.
Idempotent State Conflicts: When consecutive builds contain zero file modifications, Firebase optimization logic flags the release bundle as structurally identical to the live production build.
Aggressive Exit Code Flags: The deployment utility interprets this identical state as an operational failure, returning a non-zero exit status that forcefully breaks your workflow chain.

🛠️ The Modern Implementation Strategy:

Conditional Deployment Guards: Introduce a dynamic file change detection mechanism directly inside your continuous integration step definitions.
Idempotent Workflow Controls: Implement custom workflow scripts leveraging the core Firebase CLI directly instead of using abstract, rigid pre-built actions.
Graceful Exit Optimization: Append standard bash execution overrides to capture identical version notices and rewrite exit statuses cleanly to neutral status levels.

🔗 visit our official site: www.nextbigcreative.com

How to Fix FCM "MismatchSenderId" in Multi-Environment Expo (EAS) Builds

Sat, 27 Jun 2026 09:03:38 +0000

How to Fix `MismatchSenderId` in Expo EAS Push Notifications Across Multiple Environments

If you are managing multiple environments (Staging, Preview, Production) in a React Native Expo app, setting up Firebase Cloud Messaging (FCM) can quickly turn into a credential nightmare.

You set up separate Firebase projects for each environment, download your config files, and configure your service accounts. Everything looks right. But when you test push notifications on your staging build, you hit a wall:

Error: MismatchSenderId

This error doesn't mean your code is broken. It means you've hit a structural limitation in how Expo EAS handles push credentials.

Here is exactly why this happens and how to architect a clean solution.

Why the Mismatch Happens

The MismatchSenderId error occurs because of a strict identity mismatch:

The device token was generated by Firebase Project A, but the notification payload was dispatched using credentials from Firebase Project B.

In a standard web or backend setup, this is easy to manage. But in the Expo ecosystem, you run into the EAS Project Limit:

Expo maps push notification service accounts per EAS Project, not per EAS Build Profile (development, preview, production).

When you run eas credentials or use the automated CLI prompts, EAS expects one default push notification Service Account (SA) key for the entire project.

If you try to reuse or attach the same service account across different Google Cloud/Firebase projects via IAM permissions, FCM will reject the cross-project token request, throwing MismatchSenderId.

Solution 1: Split Your EAS Projects (Recommended for Clean Automation)

If you want to rely on Expo's automated push notification infrastructure without overriding credentials constantly, the cleanest architectural fix is to separate your environments at the EAS project level.

Instead of one EAS project with multiple build profiles, initialize separate EAS projects in your ecosystem:

your-app-staging
your-app-production

Implementation Steps

In your app.json, dynamically switch the expo.projectId and expo.slug based on an environment variable during your build step:

{
  "expo": {
    "name": "Your App",
    "slug": "your-app-production",
    "extra": {
      "eas": {
        "projectId": "YOUR-PROD-PROJECT-ID"
      }
    }
  }
}

Link your staging build profile to your staging EAS project.

Run eas credentials for each project separately. This allows you to upload the staging FCM Service Account to your staging EAS project, and the production FCM Service Account to your production EAS project.

Solution 2: Bypass EAS and Route Tokens on Your Backend

If separating your EAS projects isn't an option and you need to keep everything under a single Expo App ID, you have to stop relying on Expo's unified push notification server and handle routing downstream.

Implementation Steps

Tag Tokens by Environment

When your app requests a push notification token using Expo.getExpoPushTokenAsync(), append the current build environment metadata before sending it to your database:

const token = await Expo.getExpoPushTokenAsync();

// Save to backend alongside the environment flag
await saveTokenToBackend({
  token: token.data,
  environment: process.env.EXPO_PUBLIC_APP_ENV // 'staging' or 'production'
});

Handle Routing on Your Server

On your backend infrastructure, do not use a single global Firebase initialization instance.

Initialize multiple Firebase Admin SDK instances using the respective service account JSON keys for each environment.

When triggering a notification, check the token's environment tag and dispatch it explicitly through the matching Firebase Admin instance.

Verification Checklist Before Your Next Build

Before you trigger your next EAS build, double-check that your native configuration files aren't bleeding into each other:

Config Plugins: Ensure your app.json or app.config.js uses a dynamic config plugin to load google-services.json (Android) and GoogleService-Info.plist (iOS) based on the target build profile. If your staging build accidentally bundles the production google-services.json, your token identities will instantly mismatch.
Sender IDs: Verify that the sender ID inside your bundled client-side Firebase config explicitly matches the project ID of the service account used by your notification server.

I actually built a quick web tool called Fix My Error to automate troubleshooting these kinds of React Native, Expo, and Gradle build traps. If you're stuck on a cryptic error log, feel free to drop it in there to grab the configuration fix.

The Weekend I Finally Finished 17 Projects

Fri, 12 Jun 2026 00:14:34 +0000

You know that feeling when you open a folder you haven't touched in months and find... yourself?

Not metaphorically. I mean literally — old projects you don't even remember writing, with code that's somehow good? And you're sitting there like, "wait, I wrote this?"

That was my Saturday.

The Mess

I decided it was time. My portfolio was a ghost town. My GitHub was full of half-finished dreams. You know the drill, you start a project, get 80% there, then a shinier thing comes along and suddenly it's gathering dust for a year.

I had 17 of those.

LIS — An AI tutoring app for Cameroonian students. Works offline. Has a Learning DNA that adapts to how you study. I literally submitted this for a social impact prize and then... just left it there.
Mbende Stay — A booking platform with mobile money payments. Fully functional. Zero visitors.
"418 I'm a Teapot" — A game where you play as a teapot that can never win and an AI roasts you every time you fail. I'm not kidding.
elementTouch — A JavaScript library I built from scratch. Drag and drop. Typewriter effects. A whole code editor. Just... sitting there.

And I'm looking at all of this thinking: bro, you really just built things and then forgot to tell anyone?

So I made a decision: polish them all, put them in my portfolio, and actually show the work.

First step: build an admin import tool. One click, seed 17 projects into Firestore. Felt like a genius.

Then the Universe Laughed

npm run build

ReferenceError: location is not defined
    at v (.next/server/app/admin/blog/new/page.js:1:11128)
    at y (.next/server/app/admin/projects/import/page.js:1:16875)
    at y (.next/server/app/admin/projects/new/page.js:1:8262)
    at j (.next/server/app/admin/resumes/new/page.js:1:4056)

Four pages. Dead. And I have no idea where location is coming from.

You ever debug a Firebase + Next.js app and feel like you're chasing a ghost? Because I was definitely chasing a ghost.

Turns out, Firebase's SDK references location (as in window.location) at the module level. Not inside a function you call. At import time. So when Next.js tries to server-render your admin page, Node.js is like "what's location? never heard of her."

The fix?

import dynamic from "next/dynamic"
export default dynamic(() => import("./page.client"), { ssr: false })

I wrapped each page in next/dynamic with ssr: false. Basically told Next.js: "Don't even look at this page on the server. Not once. Not ever. Just send the JS and let the browser figure it out."

Moved all the actual code to page.client.tsx. Build passed. I felt like a god for approximately 12 minutes.

The Betrayal

Then I looked at my blog.

You see, my blog posts are stored in Firestore as HTML. And somewhere along the way, I'd written them with beautiful Tailwind dark mode classes:

<div class="not-dark:bg-white dark:bg-gray-900 dark:shadow-lg">

Here's the problem: Tailwind v4's JIT compiler has never heard of your database.

It scans your source files — your app/, your components/, your lib/. It does NOT make a Firebase query to find class names.

So dark:bg-gray-900 in a blog post? Never compiled. It renders as plain text with zero styles. My "beautiful blog content" was just... floating in the void. No background. No shadow. Nothing.

I sat there staring at the screen feeling personally betrayed by a CSS framework.

But hey, I fixed it:

function prepareHtml(html: string): string {
  return html.replace(/\b(?:not-)?dark:[^\s"'>]+/g, "").trim()
}

Strip the prefixes. Then override everything with CSS variables:

.blog-content .text-gray-900 { color: inherit !important; }
.blog-content .bg-white, .blog-content .bg-gray-900 { background: transparent !important; }
.blog-content .shadow-md, .blog-content .shadow-lg { box-shadow: none !important; }

Now every hardcoded class respects the theme. Dark mode, light mode, it just works. The blog content is finally alive.

Then There Were 17

So now I've got 17 projects in my portfolio. On one page. One. Grid. Screen. You see the problem.

I needed pagination. Not the boring kind — something that actually looks good:

Chevrons that bounce when you hover
Page numbers with the accent color on active
Ellipsis that only show when there's actually a gap
A quiet little "Page X of Y · N projects" at the bottom

The button logic nearly broke me. You try handling "first page, last page, exactly 5 pages, exactly 6 pages, ellipsis-or-no-ellipsis" without your brain melting:

const pages = useMemo(() => {
  const p: (number | "...")[] = []
  if (totalPages <= 5) {
    for (let i = 0; i < totalPages; i++) p.push(i)
  } else {
    p.push(0)
    if (safePage > 2) p.push("...")
    // ... more edge cases
  }
  return p
}, [safePage, totalPages])

It works. It's clean. I'm proud of it.

What I Actually Learned

1. You probably have better code than you think

Open that old project. The one you're embarrassed about. I bet it's not as bad as you remember. We're all way too hard on ourselves.

2. Admin pages don't need SSR

If your page is behind a login wall, there's zero SEO value in server-rendering it. Just use ssr: false and save yourself the headache. Your admin panel will survive without being indexed by Google.

3. Tailwind v4 JIT is amazing until your content is dynamic

If your HTML lives in a database, plan ahead. CSS variables are your escape hatch. Hardcoded utility classes in data strings will come back to haunt you.

4. A portfolio is never done

Every time I thought "okay this is final," I found another project, another bug, another thing to improve. That's not failure. That's just what building in public looks like.

What's Left

elementTouch still has 2 unfinished tasks out of 7. I'll get to them.

And there's a missing admin/blog/edit/[id] page that keeps crashing the build. One day.

Anyway, that's my weekend. What's the most embarrassing bug you've fought with Next.js + Firebase? Drop it below so I don't feel alone.
Here's my portfolio btw: Portfolio

I Built an AI-Powered Agricultural Logistics Platform for Farmers Worldwide — Here's How

Mon, 01 Jun 2026 06:04:51 +0000

16% of agricultural produce globally is lost every year before it reaches the buyer. Not because the crops are bad. Because the supply chain is broken.
Farmers have no digital way to list surplus crops. Buyers can't discover what's available nearby. Drivers get no coordination layer. Everyone loses.
I built Micro-Harvest to fix all three — at the same time — using a single AI conversation.

What Is Micro-Harvest?
Micro-Harvest is a three-sided agricultural logistics platform built for the Google Cloud Rapid Agent Hackathon 2026 (Elastic Track). It connects:

Farmers (Growers) — who list surplus crops via an AI chat agent
Buyers (Producers) — who discover listings through smart geo-search
Drivers (Transporters) — who get auto-assigned hauls and handle delivery

One conversation from the farmer triggers the entire chain — AI reasoning, buyer matching, driver dispatch, and Stripe payment settlement. All automated.
Watch the full demo: https://youtu.be/0ZdplkglDBo

The Core Idea: One Message Does Everything
Here's what happens when a farmer speaks or types:

"I have 20 macro bins of Merlot ready to go today, asking $4000 per ton"

Under the hood, in under 30 seconds:

Gemini 3.1 Flash extracts → crop type, quantity, price, urgency
AI Reasoning Engine scores → urgency level, weather risk, vehicle recommendation
Elastic MCP (24 tools) → geo-matches nearest available buyer + transporter
FCM push notification → driver gets haul assignment
Driver completes → Gate 1 pickup + Gate 2 delivery confirmation
Stripe → 80% to farmer, 15% to driver, 5% platform fee. Same day.
No phone calls. No middlemen. No 3-day delays.

The Tech Stack-
AI Agent - Google Agent Platform, LLM - Gemini 3.1 Flash Lite Preview, Search - Elastic MCP — 24 tools, Backend - Firebase (Firestore, Auth, Cloud Functions) Payments - Stripe, Mobile - Flutter (3 Android apps) Admin - Flutter Web

The Elastic MCP server is the heart of the matching layer. It exposes 24 tools covering semantic crop search, geo-distance queries, transporter availability matching, index health monitoring, and BigQuery analytics. Every search the buyer runs fires a real geo-distance query against the listings index in real time — you can watch it in the Elastic search profiler.

The Feature I'm Most Proud Of: Offline-First Listing
Farmers often operate in areas with poor connectivity. Someone out in a field with no signal shouldn't lose their listing.
So I built the Harvest Agent to be offline-first:

Farmer speaks or types their crop details — no internet detected
App shows an offline badge and queues the message locally
The moment connectivity returns — listing syncs and goes live automatically
Zero farmer action needed

This was the hardest part to get right. The local queue needed to survive app restarts, handle partial sync failures, and not create duplicate listings on reconnect. It took more debugging than the entire AI integration.

Three Apps, One Platform
All three apps are built in Flutter and share the same Firebase project:
Farmer App (Grower)

Voice + text AI listing creation
Offline message queue with auto-sync
Real-time listing status tracking
Earnings dashboard

Buyer App (Producer)

Natural language surplus search
Geo-filtered results with radius control
Claim and reserve listings
Live transport tracking

Driver App (Transporter)

FCM haul notifications
GPS route guidance to farm
Gate 1 + Gate 2 photo capture
Instant payment on delivery confirmation

You can download and install all three APKs from the GitHub release and walk through the complete end-to-end flow yourself. APK links are in the Links section at the bottom.
(Enable "Install from unknown sources" in Android settings first)

What I'd Build Next
A few things I want to add after the hackathon:

Price intelligence — Gemini currently recommends a price band but doesn't pull live commodity market rates; integrating real-time agri pricing APIs would make this genuinely powerful
iOS builds — currently Android only; the Flutter code is cross-platform but Apple provisioning didn't make the deadline
Multi-language AI agent — supporting regional languages so the Harvest Agent works natively for farmers regardless of where they are in the world

Links
Demo Video
https://youtu.be/0ZdplkglDBo
Landing Page
https://micro-harvest-landing.web.app
️ Admin Panel
https://micro-harvest.web.app
GitHub
https://github.com/ssurekumar01111-hue/micro-harvest
Farmer APK
https://github.com/ssurekumar01111-hue/micro-harvest/releases/download/v1.0.0/grower-release.apk
Buyer APK
https://github.com/ssurekumar01111-hue/micro-harvest/releases/download/v1.0.0/producer-release.apk
Driver APK
https://github.com/ssurekumar01111-hue/micro-harvest/releases/download/v1.0.0/transporter-release.apk

Building this solo in Flutter + Firebase was genuinely fun — the Google Agent Platform + Elastic MCP combination is seriously powerful for this kind of multi-party matching problem. Happy to answer questions about any part of the architecture in the comments.

Building a Modern Real-Time Collaborative Document Editor — Full Stack Engineering Journey

Fri, 29 May 2026 05:56:02 +0000

In today’s digital world, real-time collaboration platforms have become one of the most important categories of modern web applications. From team collaboration tools to cloud-based editors, users now expect instant synchronization, secure authentication, responsive interfaces and seamless teamwork experiences.

To strengthen my full-stack engineering skills and gain deeper practical experience in scalable real-time systems, I started working on a Modern Real-Time Collaborative Document Editor during my internship journey at TEYZIX CORE.

This project was designed as a modern collaborative platform where multiple users can work together on documents in real time while maintaining synchronization, authentication, responsiveness and structured backend architecture.

Project Overview

The main goal of this project was to build a scalable and modern collaborative editing platform using a complete full-stack architecture.

The application allows users to:

Create and manage documents
Collaborate with multiple users simultaneously
Experience real-time synchronization
Use secure authentication systems
Access a responsive and modern UI/UX
Work with live socket communication
Handle scalable backend APIs
Maintain structured project architecture

Rather than creating a beginner-level CRUD application, this project focused more on solving real-world engineering challenges such as real-time communication, state synchronization, authentication workflows, API structuring, socket event management and scalable architecture planning.

This project falls between an intermediate and advanced level full-stack engineering system.

Technologies Used

Frontend Technologies

The frontend of the application was developed using:

React.js
Vite
Tailwind CSS
Context API
Custom Hooks
Socket.IO Client

React.js was used to create reusable and scalable UI components, while Vite provided a fast and optimized development environment.

Tailwind CSS helped in building a modern responsive interface with clean layouts and consistent styling.

Backend Technologies

The backend architecture was built using:

Node.js
Express.js
REST APIs
Socket.IO
Middleware Architecture

Express.js handled routing, middleware management, API handling and backend scalability.

Socket.IO played a major role in enabling real-time communication between users connected to the same document.

Database & Authentication

For backend services and cloud storage integration, Firebase services were used:

Firebase Authentication
Firestore Database
Firebase Admin SDK

Firestore was selected because of its real-time capabilities, flexibility, scalability and easy integration with modern JavaScript applications.

Real-Time Collaboration System

One of the most important parts of this project was implementing real-time synchronization.

When multiple users edit the same document simultaneously, the system must instantly sync updates between connected clients without refreshing the page.

This functionality was implemented using:

Socket.IO event communication
Real-time listeners
Shared document state management
Live synchronization handling

The application was designed to handle:

Real-time document updates
Live user presence
Connection/disconnection events
Collaborative editing workflows
Sync reliability between multiple users

Project Architecture

The project followed a structured full-stack architecture with separate client and server environments.

Frontend Structure

The frontend included:

Reusable components
Route protection
Context management
Socket services
Authentication services
API service layer
Custom hooks
Theme management

Backend Structure

The backend included:

Controllers
Services
Middleware
Routes
Socket handlers
Validators
Utilities
Firebase configuration
Authentication handling

The project structure was designed to remain scalable, maintainable, and production-ready.

Major Challenges Faced During Development

Every real-world project comes with technical challenges and this project was no exception.

Although most parts of the system worked smoothly two major technical issues became the biggest learning experiences during development.

1. Firebase API & Backend Configuration

The first major challenge was configuring the Firebase Admin SDK correctly with the backend environment.

At first, the backend was running successfully but Firebase services were not connecting properly because the required environment variables and service account credentials were missing or incorrectly formatted.

The main issues included:

Firebase private key formatting
Environment variable handling
Admin SDK initialization
Secure credential management

After debugging the configuration and properly connecting the Firebase service account credentials the backend started communicating successfully with Firebase services.

This experience helped me understand how important environment configuration and secure credential handling are in production-level applications.

2. Authentication Data Not Appearing in Fire store

The second major issue involved authentication data storage.

Users were able to sign up and log in successfully using:

Google Authentication
Email & Password Authentication

However, the user information was not appearing inside Firestore collections as expected.

Initially, this created confusion because authentication itself was working correctly.

Later I understood that:

Firebase Authentication and Fire store Database are separate systems.

Authentication stores user accounts inside the Firebase Authentication panel, while Fire store stores custom database documents separately.

To save user information in Fire store, additional database logic must be written manually using:

addDoc()
setDoc()
collection()
updateDoc()

This debugging process improved my understanding of how authentication systems and NoSQL databases work together in modern cloud applications.

Technical Engineering Considerations

While developing this system, several important software engineering practices were considered.

Real-Time Reliability

The synchronization system needed to remain stable and responsive between multiple connected users.

Scalable Code Structure

The project was organized using a modular architecture for maintainability and scalability.

Clean API Naming

REST APIs and socket events followed structured naming conventions for readability and debugging.

Environment Security

Sensitive Firebase credentials and environment variables were managed securely through .env configuration files.

Deployment Readiness

The architecture was designed in a way that the project could later be deployed without major restructuring.

Deliverables & Documentation

The project also included proper engineering documentation and structured deliverables such as:

Source code repository
README documentation
API documentation
Architecture overview
Environment setup guides
Screenshots & walkthroughs
Socket event documentation
Deployment preparation
Database structure planning
Real-time collaboration explanation

What I Learned From This Project

This project became a major practical learning experience for me.

Instead of only building frontend interfaces, I learned how modern full-stack systems work internally.

Some of the biggest learning outcomes included:

Real-time application architecture
Socket communication workflows
Firebase integration
Authentication systems
Backend structuring
Environment management
API handling
Debugging real-world issues
Scalable project organization

Most importantly, this project improved my confidence in working with modern full-stack technologies, develop a SaaS project and solving practical engineering challenges.

Repository Link: https://github.com/YasirAwan4831/rt-collaborative-doc-editor-fs3

Final Thoughts

Building this Modern Real-Time Collaborative Document Editor was an exciting and valuable experience.

The project helped me understand how modern collaboration platforms function behind the scenes and how full-stack technologies interact together to create scalable web applications.

Although the system still has room for future improvements such as advanced permissions, document version recovery and conflict resolution enhancements, the current implementation successfully demonstrates real-world collaboration workflows and modern engineering practices.

Projects like this are not only about writing code — they are about understanding architecture, debugging systems, solving engineering problems and continuously learning throughout the development journey.

And honestly, that is what makes software engineering exciting.

— Muhammad Yasir
Full Stack Developer

#FullStackDevelopment #ReactJS #NodeJS #Firebase #SocketIO #WebDevelopment #RealtimeApps #JavaScript #OpenSource #SoftwareEngineering #FrontendDevelopment #BackendDevelopment #Firestore #TailwindCSS #Vite #CollaborativeEditor #TEYZIXCORE #LinkedInTech #Developers #CodingJourney #MuhammadYasir #yasirTech #YasirAwan4831

Persistence Honesty: Guests, Firebase, Cache, and User-Owned Sync

Thu, 28 May 2026 08:00:00 +0000

Persistence Honesty: Guests, Firebase, Cache, and User-Owned Sync

“Local-first” in our prose means interaction and ingestion default to the device — not “no server for signed-in users.” This part is the mode matrix every writer and growth campaign must internalise. Deeper guest/auth detail also lives in content/coderlegion-sovereign-engineering-serial/05-local-first-browser-vault.md; here we align with the 2026 calibration ledger.

Ground truth table

User mode	Authoritative trades	Code touchpoints
Guest	Browser `localStorage` (namespaced keys, quota handling)	`localPortfolioStore` patterns
Authenticated	Firebase cloud — authoritative history	`useTrades` → `TradeService.getTrades`
UI preferences	Zustand `persist` with `partialize` — chart/filters only	`portfolioStore`
IndexedDB	Primarily Firestore client SDK cache; cleared on logout where implemented	`useAuth` teardown
Google Drive	User-owned file (`pocket_portfolio_db.json`) — dumb sync lane	Sovereign Sync docs / architecture page

Why “IndexedDB is our database” is wrong

Guests do not use IndexedDB as the primary trade vault — they use localStorage. Authenticated users’ authority is Firebase, with IndexedDB as offline/cache for the SDK. Claiming IndexedDB is “the portfolio vault for everyone” fails procurement diligence in one grep.

Local-first ≠ no cloud

Approved phrases (from docs/command/claims-vs-codebase-calibration.md):

Client-side aggregation by construction for LLM context.
Stateless inference handler for portfolio text on /api/ai/chat.

Prohibited without sign-off:

“Zero server footprint” / “fully local portfolio” for auth workflows.
“No cloud” — Firebase, Vercel, LLM APIs, optional Redis/KV are all cloud-adjacent.

Google Drive: sovereign sync, not app logic

Drive holds a user-owned JSON file. The app does not execute portfolio business rules on Google’s servers — it treats Drive as dumb storage for export/sync. That is a credible “user-owned lane” story without claiming we eliminated Firebase for signed-in users.

Engineering takeaway for Part 12

Honest persistence makes the inference boundary (Parts 2–3) believable: we are not pretending the full ledger never existed; we are proving the LLM hop does not require re-uploading it row-by-row.

Part 4 of Sovereign Ingestion & Stateless Inference.

Read the full Sovereign Intelligence book, explore Open Portfolio, or try Pocket Portfolio.

What's the most annoying problem in your daily life that doesn't have a good mobile app yet?

Thu, 14 May 2026 13:33:13 +0000

Hey CoderLegion community
I'm a Flutter & Firebase developer currently looking for my next build idea — and instead of guessing, I want to ask the people who actually feel the pain.
What's a real problem you face regularly that you wish had a better mobile app solution?
Could be anything:

Something at work that still runs on WhatsApp groups or spreadsheets
A local service that has no app (booking, delivery, scheduling)
A tool you use daily that feels clunky or outdated
Something you've thought "why doesn't this app exist yet?"

I build full-stack mobile apps using Flutter + Firebase — so I'm looking for ideas that involve real-time data, multi-user roles, bookings, payments, or location tracking. But drop anything — I want to hear what actually frustrates people.
Drop your pain point in the comments Even half-formed ideas are welcome. If enough people share the same problem, that's a signal worth building for.
Let's see what's missing out there.

Building a Zero-Cost AI Feature in Flutter with Gemma 4 + Firebase

Mon, 11 May 2026 16:39:31 +0000

How to combine on-device inference with cloud sync — without paying a cent in API fees

The Unspoken Reality of AI API Costs

Here’s the moment every indie developer dreads. You’ve shipped your AI feature. Users love it. It’s working. Then you open your billing dashboard.

Every question your users ask costs you money. Every summary generated, every classification run, you’re paying for it. You have created a successful product, but its popularity is now draining your resources.

What if there was a way to run powerful AI in your Flutter app with zero ongoing API costs? No per-request charges. No server bills. No privacy risk from data leaving the device.

That’s exactly what the combination of Gemma 4 and Firebase unlocks. Gemma does the thinking, entirely on the user’s phone. Firebase handles persistence and sync. The result is an AI-powered app that scales to thousands of users at near-zero marginal cost.

I’m building my own product on this exact stack. Here’s how it works.

Why cloud AI is a trap for indie developers

Cloud AI APIs are seductive. You make one API call, get a response, ship the feature. But the cost model is brutal for bootstrapped products:

Costs scale directly with usage — success punishes you
User data leaves the device — a privacy and trust problem
No connection means broken features — poor offline experience
You’re dependent on a third-party API that can change pricing or availability

On-device AI solves all four of these problems at once. The model runs locally, the user’s data never hits a network, it works offline, and you own the stack.

The stack: Gemma 4 + flutter_gemma + Firebase

Three components, each with a clear job:

Gemma 4 (the brain)
Gemma 4 is Google’s latest edge-optimized open model, built on the same research as Gemini but designed to run efficiently on mobile hardware. The E2B variant (Effective 2B parameters) runs in under 2GB of RAM thanks to 4-bit quantization. It’s practical for real devices, not just flagship phones. Critically, Gemma 4 supports native function calling, which means you can wire it directly into your app’s logic without any prompt engineering hacks.

flutter_gemma (the bridge)
The flutter_gemma package wraps the native LiteRT-LM inference engine in a clean Dart API. You get GPU acceleration, streaming responses, multimodal vision support, and function calling, all from Flutter. It supports Android, iOS, Web, and Desktop from a single codebase.

Firebase (the backbone)
Firebase handles everything that needs to live in the cloud: Firestore for storing and syncing AI outputs across devices, Firebase Auth for user identity, and optionally Firebase Storage if you need to persist larger assets. The key insight is that your AI inference never touches Firebase; only the results do.

The architecture: who does what

Here’s the principle that makes this work: AI never touches the network. Only the output does.

The flow looks like this:

User creates content in the app (a note, a photo, a voice memo)
Gemma processes it on-device — tagging, summarizing, classifying
The AI output (not the raw input) is written to Firestore
Firebase syncs the output to the user’s other devices

The user’s raw thoughts, photos, or voice never leave their phone. The model never makes a network call. But their data is still available everywhere they need it, because Firebase syncs the processed result.

Building it: a private AI notes app

Let’s make this concrete. We’ll build a simple notes app where Gemma automatically tags and summarizes each note on-device, then Firebase syncs the result across the user’s devices. Here’s the step-by-step.

Step 1: Set up flutter_gemma
Add the dependency to your pubspec.yaml:

dependencies: flutter_gemma: ^0.13.1 cloud_firestore: ^5.0.0 firebase_auth: ^5.0.0

Download the Gemma 4 E2B model from Hugging Face (you’ll need to accept the license terms). Store your HuggingFace token securely; never hardcode it. On first launch, the app downloads the model to local storage. This is a one-time operation of around 1.5GB.

Step 2: Run on-device inference
Initialize the model and run a simple summarization:

final model = await FlutterGemma.getActiveModel( maxTokens: 512, preferredBackend: PreferredBackend.gpu,); final chat = await model.createChat(); await chat.addQueryChunk( Message.text( text: ‘Summarize this note in one sentence and suggest 2-3 tags: $noteContent’, isUser: true, ),); final response = await chat.generateChatResponse();

That’s it. The inference runs entirely on-device. No API key, no network call, no cost. The response gives you a summary and tags you can parse and store.

Step 3: Write the output to Firestore
Take the AI output and persist it to Firestore:

`await FirebaseFirestore.instance
.collection(’notes’)
.doc(noteId)
.set({‘originalContent’: noteContent, // stays on-device or stored per your preference

‘summary’: parsedSummary,    
‘tags’: parsedTags,    
‘userId’: FirebaseAuth.instance.currentUser!.uid,    
‘createdAt’: FieldValue.serverTimestamp(),});`

Notice what goes to Firestore: the AI-generated summary and tags, not necessarily the raw note. You can store the original too if your app requires it — but the point is you’re in control of what leaves the device.

Step 4: Read it back and sync
Firestore’s real-time listeners handle the sync automatically. Open the app on a second device and your tagged, summarized notes appear instantly — without any polling logic on your part. Firebase does the heavy lifting.

Real talk: the gotchas

I won’t sell you a perfect picture. Here’s what you’ll actually run into:

Model download size
The Gemma 4 E2B model is ~1.5GB. This is a one-time download, but you need to handle it gracefully. Show a clear progress indicator on first launch. Consider letting users choose to download over WiFi only. The flutter_gemma package provides download progress callbacks — use them.

Cold start time
Loading the model into memory takes a few seconds on the first inference of a session. Show a loading state. After the model is warm, subsequent responses are fast. Set user expectations early — frame it as the app ‘preparing your AI’ rather than ‘loading.’

Know when to use cloud AI instead
On-device Gemma 4 is excellent for targeted tasks: summarization, classification, short generation, tagging. It’s not the right tool for complex multi-step reasoning, very long context windows, or tasks where you need GPT-4-level capability. Design your AI features to scope appropriately — use Gemma on-device for the 80% of tasks it handles well, and route complex queries to a cloud model if needed.

The payoff

Here’s what you get with this architecture:

Zero ongoing AI cost. No per-request charges, ever. The model is on the user’s device.
Full privacy. User data is processed locally. You can credibly promise your users their data stays on their phone.
Works offline. AI features work without a connection. Firebase syncs when connectivity returns.
Scales for free. Your 1,000th user costs you no more in AI inference than your first.

Firebase gives you the sync and persistence layer without building a backend. Gemma gives you the AI without paying per token. Together, they let you ship an AI-powered product that’s genuinely sustainable for an indie developer.

What I’m building with this

This is the exact architecture I’m using for my own product — built on Flutter, Gemma, and Firebase. I’ll be writing more about specific implementation decisions as I go, including how I’m using Gemma’s multimodal vision support and how I structure Firestore for AI-generated data.

If you’re building something similar — or thinking about it — hit reply. I’d love to hear what you’re working on.

Next up: Adding multimodal vision to your Flutter + Gemma app — letting the model read images directly, entirely on-device.

I Built a Complete Zomato-Style Food Delivery Platform in Flutter — Here's What I Learned

Sun, 10 May 2026 10:40:13 +0000

Just shipped Zesto — a full food delivery ecosystem with 4 Flutter
apps and a Firebase backend. Here's what the build taught me.

What's in the project

Customer App — OTP login, restaurant discovery, cart,
Razorpay payments, live driver tracking on Google Maps
Driver App — auto job assignment, step-by-step delivery
slider, background GPS foreground service
️ Restaurant App — real-time order dashboard, menu management
️ Admin Panel — Flutter Web, multi-city management

Backend: 20+Firebase Cloud Functions (Node.js 18)

3 Things That Bit Me Hard

Never trust client-side prices
My original placeOrder Cloud Function accepted grand_total from
the app. Anyone could send grand_total: 1 and get free food.
Fixed by recalculating everything server-side from Firestore menu
prices — never touching the client value.
Status string consistency across 4 apps
Flutter enums use camelCase by default (arrivedAtRestaurant).
Firestore stored snake_case (arrived_at_restaurant). Silent
mismatches everywhere. Lesson: standardize from day one and use
a safe parser that never throws on unknown values.
MobX reactions fire on every change — not just the first one
My HomeScreen reaction was pushing a new delivery screen every time
activeJob updated — including status changes while the driver was
already on the delivery screen. Three screens deep by the time the
order was delivered. A single boolean guard fixed it.

Tech Stack
Flutter 3.11+ · Dart · Firebase · Razorpay
Google Maps · MobX · Node.js 18 · GeoFlutterFire

The source code is available
If you're building something similar or want a real production
Flutter/Firebase codebase to learn from:
https://morningstar47jb.gumroad.com/l/tnevss
Demo video: https://youtube.com/shorts/rL2M5O5Tk50
Happy to answer any architecture questions in the comments.

Measuring Loop Velocity Without Portfolio Rows

Mon, 04 May 2026 11:29:00 +0000

Measuring Loop Velocity Without Portfolio Rows

/admin/analytics is an operator console—revenue, referrals, npm packages, viral email blast stats, Pocket Analyst usage metadata. It is not a SQL console into user holdings.

API surface: `GET /api/admin/analytics`

app/api/admin/analytics/route.ts aggregates many subsystems in one response (time range via ?range=). Notable bundles:

Stripe — subscription / checkout signals keyed by price IDs (SPONSOR_PRICE_IDS, FOUNDERS_CLUB_PRICE_IDS).
Referrals — getReferralData(startDate) over referralEvents (clicks, conversions, by campaign, by source).
Viral moment — getViralMomentBlastMetrics + viralMomentEmailBlast object including viral_moment_v1 conversion rollups when campaign data exists.
NPM — download signals for scoped packages (NPM_PACKAGES array).
Pocket Analyst — events come from toolUsage writes (see Part 1) — flags like hadAttachment, not prompt text.

The UI is app/admin/analytics/page.tsx — tables and cards for humans, not raw Firestore dumps.

What “zero-PII analytics” actually means here

We minimize sensitive fields in product telemetry:

Referral events carry codes and campaign tags, not tickers.
Analyst logs carry uid/tier/booleans, not context strings.

We do not claim zero identifiers: UIDs exist wherever Firebase auth does.

GA4 vs admin

GA4 answers marketing acquisition (active users, sources). Admin API answers product operations (paid tiers, referral funnel, blast performance). Use both; never conflate without labels (Part 4).

Part 9 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.

Building a Zomato-Like Multi-City Food Delivery App with Flutter & Firebase

Tue, 28 Apr 2026 05:29:56 +0000

Hey everyone, Surendra Kumar here —Flutter/Firebase developer from Banda, India. I've been building production apps under Gfood Delivery Private Limited, and today I want to share the architecture behind my most ambitious project yet: Zesto, a multi-city food delivery platform built entirely with Flutter and Firebase.
Zesto isn't a tutorial project. It's a real, working platform — 4 Flutter apps, a complete Firebase backend, and architecture decisions modeled after how production platforms like Zomato actually work.
Want to try it before reading? Download the customer app APK and test it yourself:
Download Zesto Customer App https://github.com/ssurekumar01111-hue/zesto-demo/releases/download/v1.0-beta/app-release.apk
I'd love your feedback and improvement ideas after reading.

The 4-App Ecosystem
Zesto consists of four interconnected Flutter applications:

Customer App — Multi-city restaurant discovery, cart, Razorpay + wallet payments, live GPS tracking, reviews
Restaurant Partner App — Order management, menu CRUD, earnings dashboard, FCM order alerts
Driver App — Order accept/reject, live delivery tracking, earnings, payout requests
Flutter Web Admin Panel — 14 screens covering cities, zones, restaurants, drivers, orders, analytics, reviews, ads, config, and audit logs

The Core Architecture Decision: City + Zone Scoping
This is the most important architectural decision in Zesto — and the one that separates it from basic food delivery tutorials.
Every single Firestore document has two fields:
dart{
"city_id": "banda_up",
"zone_id": "banda_zone_1",
// ... rest of document
}
Every query filters by city_id first:
dartFirebaseFirestore.instance
.collection('restaurants')
.where('city_id', isEqualTo: currentCityId)
.where('is_active', isEqualTo: true)
.snapshots();
Why does this matter? Without city scoping, as you add cities your queries return restaurants from everywhere. Firestore has no built-in geographic filtering — you have to design it in from day one. Retrofitting this later would require rewriting every query and migrating every document.
Zones sit inside cities and control driver assignment. When an order is placed, the Cloud Function assigns it to available drivers in the same zone first, then expands to the full city if no zone drivers are available.

Firebase Custom Claims for RBAC
Zesto has 5 user roles: customer, restaurant_owner, driver, admin, super_admin. Managing this with Firestore documents alone creates security holes — a user could theoretically write to their own document and escalate their role.
The solution is Firebase custom claims set via Cloud Functions:
javascript// functions/src/admin/setUserRole.js
exports.setUserRole = functions.https.onCall(async (data, context) => {
if (!context.auth.token.super_admin) {

throw new functions.https.HttpsError('permission-denied', 'Not authorized');

}
await admin.auth().setCustomUserClaims(data.uid, {

role: data.role,
city_id: data.cityId,

});
});
On the Flutter side, the role is read from the ID token directly:
dartfinal token = await FirebaseAuth.instance.currentUser?.getIdTokenResult();
final role = token?.claims?['role'] as String?;
This means even if someone modifies their Firestore document, the custom claim on the token is what gates access. Firestore rules enforce this:
javascript// firestore.rules
match /orders/{orderId} {
allow read: if request.auth.token.role == 'admin'

|| request.auth.token.role == 'restaurant_owner'
|| request.auth.uid == resource.data.customer_id;

}

MobX for State Management
Zesto uses MobX across all 4 apps. Here's why I chose it over Riverpod or GetX for this project:
MobX's reactive observables map perfectly to Firestore streams. When a Firestore stream emits a new value, MobX automatically rebuilds only the widgets that consume that observable — no manual setState, no context.watch boilerplate.
dart// core/stores/order_store.dart
class OrderStore = OrderStore with $OrderStore;

abstract class _OrderStore with Store {
@observable
ObservableList activeOrders = ObservableList();

@observable
OrderStatus currentStatus = OrderStatus.placed;

@action
void updateOrderStatus(String orderId, OrderStatus status) {

final idx = activeOrders.indexWhere((o) => o.id == orderId);
if (idx != -1) {
  activeOrders[idx] = activeOrders[idx].copyWith(status: status);
}
currentStatus = status;

}
}
The store subscribes to a Firestore stream once and updates observables. Every widget that reads activeOrders rebuilds automatically. Clean, testable, no rebuild storms.

Dual Payment Path: Razorpay + In-App Wallet
Zesto supports two payment methods and they interact with each other in interesting ways.
Razorpay handles card/UPI payments. The flow is standard — create an order via Cloud Functions, open Razorpay checkout, handle the webhook callback.
The wallet is more interesting. Each customer has a wallet_balance field on their user document. When they pay via wallet:
javascript// functions/src/payments/walletPayment.js
exports.processWalletPayment = functions.https.onCall(async (data, context) => {
const uid = context.auth.uid;

return admin.firestore().runTransaction(async (transaction) => {

const userRef = admin.firestore().collection('users').doc(uid);
const userDoc = await transaction.get(userRef);

const currentBalance = userDoc.data().wallet_balance;
if (currentBalance < data.amount) {
  throw new functions.https.HttpsError('failed-precondition', 'Insufficient balance');
}

transaction.update(userRef, {
  wallet_balance: admin.firestore.FieldValue.increment(-data.amount)
});

transaction.set(admin.firestore().collection('wallet_txns').doc(), {
  uid,
  amount: -data.amount,
  type: 'debit',
  order_id: data.orderId,
  created_at: admin.firestore.FieldValue.serverTimestamp(),
});

});
});
The Firestore transaction ensures the balance check and deduction happen atomically — no race condition where two simultaneous orders drain the wallet below zero.

Cloud Functions: Domain-Split Architecture
Instead of one massive index.js, Zesto's Cloud Functions are split by domain:
functions/src/
├── orders/
│ ├── placeOrder.js # Create order, notify restaurant
│ ├── assignDriver.js # Zone-based driver assignment
│ └── onOrderDelivered.js # Earnings calculation, wallet credit
├── payments/
│ ├── razorpayWebhook.js # Payment confirmation
│ └── walletPayment.js # Wallet debit/credit
└── admin/

├── approveRestaurant.js
└── setUserRole.js

Each function is independently deployable. When I fix a bug in assignDriver.js, I deploy only that function — not the entire backend.

The Driver Assignment Problem
When an order is placed, the platform needs to assign a driver. Here's the simplified logic:
javascriptexports.assignDriver = functions.firestore
.document('orders/{orderId}')
.onCreate(async (snap, context) => {

const order = snap.data();

// 1. Find online drivers in the same zone
const driversSnap = await admin.firestore()
  .collection('drivers')
  .where('city_id', isEqualTo: order.city_id)
  .where('zone_id', isEqualTo: order.zone_id)
  .where('is_online', isEqualTo: true)
  .where('current_order_id', isEqualTo: null)
  .limit(5)
  .get();

if (driversSnap.empty) {
  // Expand to full city
  // ... same query without zone_id filter
}

// 2. Send FCM notification to available drivers
// First driver to accept wins (handled by transaction in Driver app)
const tokens = driversSnap.docs.map(d => d.data().fcm_token);
await admin.messaging().sendMulticast({
  tokens,
  data: { type: 'NEW_ORDER', order_id: context.params.orderId }
});

});
On the driver side, accepting an order uses a Firestore transaction with three guards to prevent race conditions — only one driver can claim the order even if multiple tap Accept simultaneously.

What's Coming
Zesto is launching soon on Gumroad and Codester as commercial source code — complete, ready-to-customize. It includes all 4 Flutter apps, the complete Cloud Functions backend, Firestore security rules, and developer documentation.
Try the customer app right now:
https://github.com/ssurekumar01111-hue/zesto-demo/releases/download/v1.0-beta/app-release.apk
I'd genuinely love your feedback — what works well, what feels off, what you'd build differently. Drop a comment or reach me at Emails are not allowed.

Surendra Kumar — Flutter/Firebase developer, Banda, India
Portfolio: portfolio.gfood.in | GitHub: ssurekumar01111-hue

How I Built a Complete On-Demand Home Services App (ServeNow) with Flutter & Firebase

Tue, 28 Apr 2026 04:39:08 +0000

Hey everyone, Surendra Kumar here, a self-taught Flutter developer from Banda, India. I've spent a good chunk of my time building and shipping production apps, like those I worked on for Gfood Delivery Private Limited. Today, I want to share the story behind one of my most ambitious projects: ServeNow.

As an indie developer, I've always been driven to build real solutions—apps that don't just look pretty in a tutorial but actually work robustly in the wild. That's exactly the philosophy I brought to ServeNow.

What is ServeNow? Crafting a Full-Fledged Marketplace

ServeNow isn't just another demo app. It's a complete, production-ready on-demand home services marketplace built from the ground up with Flutter and Firebase. My goal was to create a comprehensive system that could handle everything from booking a beautician to fixing a leaky faucet, all while providing a smooth experience for customers, service providers, and administrators.

To achieve this, I engineered ServeNow as a suite of four interconnected applications, each designed for a specific user role:

Customer App: This is where users come to life. They can browse various services (beauty, cleaning, plumbing, electrical, etc.), book appointments, track their service provider in real-time, chat with them, make secure payments via Razorpay, and leave reviews.
Provider App: For the businesses offering services. They can accept new bookings, manage their schedule and service offerings, track their real-time earnings, and request payouts.
Handyman App: This is for the actual service professionals. It's a multi-service pro app featuring a broadcast job matching system, allowing handymen to pick up nearby jobs. It also includes an onboarding and approval flow for new pros.
Flutter Web Admin Panel: The control center. This robust web panel gives administrators full control over users, bookings, categories, service providers, payout requests, and provides crucial analytics to keep the marketplace running efficiently.

Why Flutter & Firebase? My Tech Stack Decisions

When embarking on ServeNow, the choice of technology was critical. I needed a stack that offered rapid development, scalability, real-time capabilities, and robust performance without requiring a massive infrastructure investment.

Flutter (Dart) for the Frontend

Flutter was a no-brainer for the mobile applications and the web admin panel.

Single Codebase: Building four distinct applications (Customer, Provider, Handyman, and Admin Panel) from a single Flutter codebase drastically cut down development time and ensured UI/UX consistency across platforms.
Performance: Flutter's native compilation and widget-based architecture deliver smooth, high-performance applications that feel truly native.
Developer Experience: Hot Reload and a rich widget catalog accelerated my development cycles, allowing for quick iterations and bug fixes.

Firebase for the Backend (My Go-To for Indie Development)

Firebase has been my backend of choice for many projects, and ServeNow was no exception. It offered the complete suite of tools I needed.

Firestore: This is the heart of ServeNow's data. I chose Firestore for its real-time capabilities, strong querying, and scalability.
- Architecture Decision: I structured collections like users, services, providers, handymen, bookings, and chats. For bookings, I leaned into denormalization by embedding critical but static details (like customer name, service price) directly within the bookings document. This minimizes expensive cross-collection reads for common operations and ensures faster data retrieval, especially for lists of bookings. Subcollections were used for highly related, nested data, like messages within a chat document.
Firebase Authentication: For secure and easy user management across all apps, supporting email/password and potentially Google Sign-In for future expansion.
Cloud Functions (JavaScript): This was indispensable for server-side logic without managing actual servers.
- Architecture Decision: Cloud Functions handle critical backend tasks:
  - Razorpay Webhooks: Securely processing payment callbacks and updating booking statuses post-payment.
  - FCM Triggers: Sending real-time push notifications for booking updates, new job broadcasts (to handymen), and chat messages.
  - Data Aggregation: Calculating real-time earnings for providers and handymen, and managing payout requests.
  - Background Tasks: Handling approval flows for new handymen and providers.
Firebase Storage: For storing user profile pictures, service images, and any other media files securely.
Firebase Cloud Messaging (FCM): Essential for real-time communication between the apps – from notifying handymen about new jobs in their area to letting customers know their service provider is on the way.

Other Key Technologies:

Razorpay: Integrated as the primary payment gateway, crucial for handling transactions securely within the Indian market. Cloud Functions were vital here for handling payment success/failure callbacks.
rxdart: I leveraged rxdart for reactive programming, especially for managing complex streams of data and state within the apps, ensuring a smooth and responsive user experience.
Google Maps: Integrated for live tracking of handymen, defining service areas, and visualizing job locations.

Architectural Decisions & Overcoming Challenges

Building ServeNow meant tackling typical marketplace complexities.

Real-time Synchronization: A core requirement. Firestore's real-time listeners were used extensively. For example, when a handyman accepts a job, the customer's app updates instantly, and the provider's app reflects the booking status change. This required careful management of data updates and notification triggers via Cloud Functions.
Scalability: Thinking beyond just a few users. Firestore's inherent scalability and Cloud Functions' serverless architecture meant the platform could grow without significant re-engineering of the backend.
Job Broadcasting & Matching: This was an interesting challenge for the Handyman app. When a new service request comes in, I use Firestore queries based on service type and location, combined with FCM, to broadcast the job to eligible handymen. The first to accept gets the job, with race conditions handled by Firestore transactions in Cloud Functions.
Secure Payouts: The provider and handyman apps needed a robust payout request system. This involves tracking earnings in Firestore, initiating payout requests, and then an admin manually (or via a future integration) processing these, all managed through the Admin Panel and Cloud Functions.
Developer Documentation: Knowing that this was a complex system, I invested significant time in creating a comprehensive 16-page developer documentation (v2.0). It covers everything from project setup to API details, making it easy for anyone to get started.

The Indie Developer Ethos: Production-Grade from Day One

What makes ServeNow different is that it's built with a "production-grade" mindset. This isn't a collection of loosely connected tutorials; it's a fully integrated, tested system designed to be deployed and used in a real business environment. Every feature, every line of code, was written with stability, scalability, and maintainability in mind. It comes complete with signed APKs and a thorough setup guide, so you can literally launch it.

Building ServeNow was a journey of applying everything I've learned about Flutter, Firebase, and shipping real products. It's proof that with dedication and the right tools, indie developers can build incredibly powerful, complete solutions.

Ready to Launch Your Own Home Services Marketplace?

If you're looking for a robust, ready-to-launch foundation for an on-demand home services marketplace, ServeNow is designed to be exactly that. It handles the complexities, so you can focus on your business.

You can learn more about my work and projects like ServeNow by checking out my GitHub profile or reaching out via email.

My GitHub Profile: ssurekumar01111-hue
Email: ssure.kumar01111@gmail.com
https://morningstar47jb.gumroad.com/l/viqos

Thanks for reading! I hope this deep dive into ServeNow gives you some insights into building complex applications as an indie developer.

Engineering the Viral Loop

Mon, 27 Apr 2026 11:19:00 +0000

Engineering the Viral Loop

We measure referral codes and events, not holdings. K-factor style thinking applies to clicks → conversions, instrumented in Firestore, without reading the user’s portfolio.

Ingest: `POST /api/referral-event`

app/api/referral-event/route.ts validates:

action: click | conversion
referralCode: required
optional source, campaign, metadata

Metadata is sanitized and bounded (sanitizeMetadata: max keys, max string lengths) so events stay small and predictable.

Firestore write:

await db.collection('referralEvents').add({
  action,
  referralCode: String(referralCode).slice(0, 64),
  source: source || 'unknown',
  ...(campaignStr ? { campaign: campaignStr } : {}),
  ...(meta ? { metadata: meta } : {}),
  timestamp: Timestamp.now(),
});

No portfolio fields appear in this schema.

Reward: `POST /api/referral/complete`

app/api/referral/complete/route.ts is authenticated (Bearer Firebase ID token). It:

Validates REF-* referral code shape (isValidReferralCode)
Resolves referralIndex doc
Enforces new-account window (REFEREE_MAX_ACCOUNT_AGE_MS)
Uses idempotent claim keys per (campaign, referee uid) (sanitizeCampaignId)

Default campaign constant comes from VIRAL_REFERRAL_CAMPAIGN_DEFAULT in app/lib/viral/referralCodeServer.ts — align with viral_moment_v1 in analytics UI.

Attribution plumbing

Middleware forces apex → www so ?ref= survives and referral cookies stay on one origin (pp_referral_code, landing capture).

Precision on “privacy”

We still store Firebase UIDs for auth and referral codes for growth. Claim: loop velocity does not require portfolio PII — not “we store nothing.”

Part 7 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.

Growth Truth: Handling the Referral Spike

Wed, 15 Apr 2026 12:04:00 +0000

Growth Truth: Handling the Referral Spike

When traffic spikes, what breaks first — routing, LLM quotas, or database write paths? Here is how we framed a real referral window against a stateless chat surface.

Headline traffic (GA4)

Figures below are from Google Analytics 4 (Marketing performance) for a fixed 28-day window. GA4 can revise counts slightly as sessions reconcile; we cite the exported values for this slice.

Field	Value
Date range	2026-03-06 → 2026-04-02 (28 days)
Active users	4,669
New users	4,500

Two different dials: GA4 answers “how many people touched the property in this window.” Product-side analytics (referral events, campaign attribution, Stripe-adjacent rollups) answer “how did growth mechanics behave?” They are complementary, not interchangeable — and GA4 active users are not the same thing as Firebase Auth sign-in counts unless you say so explicitly.

Stateless inference and where burst load lands

The app’s chat path is stateless for portfolio payloads (/api/ai/chat — see Part 1). Under spike load, stress concentrates on:

Edge / routing — session affinity is not the model; referral survival is. We 307 apex → www so ?ref= and cookies stay coherent:

// middleware.ts — canonical host: apex → www
if (host === 'pocketportfolio.app') {
  url.hostname = 'www.pocketportfolio.app';
  return NextResponse.redirect(url, 307);
}

Serverless limits — maxDuration = 30 on the chat route; streaming responses; provider rate limits.
Firestore — quota counters (aiUsage), analytics metadata (toolUsage), referralEvents — hot writes, not giant prompt logs.

Takeaway: stateless inference keeps the heaviest sensitive payload off disk; growth still needs solid indexes and realistic capacity planning for referrals and quotas.

What tends to fail first

Referral attribution (middleware, cookies) — if this slips, growth looks “direct only.”
LLM provider throttling or streaming failures.
Firestore write contention on high-frequency collections during campaigns.

Part 4 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.

React Native Android build failed: what I would check first

Mon, 06 Apr 2026 16:47:53 +0000

If a React Native Android build suddenly fails, the error message is often much less helpful than it looks.

Sometimes it points to Gradle, sometimes to a plugin, sometimes to a dependency, and sometimes it just fails deep inside the Android build process without making the real cause obvious.

I’ve run into this kind of problem enough times to stop treating “build failed” as one issue.

It is usually a category of issues.

This is the checklist I would go through first before changing random files or reinstalling everything.

First: treat build failures as clues, not conclusions

A React Native Android build can fail because of:

Gradle configuration issues
plugin resolution problems
dependency/version mismatches
Kotlin or AGP incompatibility
corrupted caches
autolinking problems
native module integration issues
environment/setup problems on the machine

That means the text BUILD FAILED is not the diagnosis. It is just the start of the diagnosis.

What I would check first

1. Read the first meaningful error, not the last line

One of the easiest mistakes is focusing on the bottom of the terminal output.

The last line usually just says the build failed. The useful part is often earlier:

the first missing plugin
the first unresolved dependency
the first incompatible version
the first task that actually broke

If I see a huge wall of Gradle output, I try to find the first message that clearly indicates what could not be found, resolved, or configured.

That usually narrows the problem much faster.

2. Check React Native / Gradle / AGP / Kotlin compatibility

A lot of Android build failures are really version alignment problems.

I would check whether these pieces actually make sense together:

React Native version
Gradle wrapper version
Android Gradle Plugin version
Kotlin version
installed JDK version

A mismatch here can break the build even when your app code is fine.

This is especially common after:

upgrading React Native
adding or updating native libraries
copying build config from another project
mixing Expo/native config changes

3. Look at `settings.gradle` and plugin resolution first

If the error mentions plugins not being found, configuration failing, or included builds not resolving correctly, I would go straight to:

android/settings.gradle
root build.gradle
plugin management / includeBuild setup

In newer React Native setups, especially around the Gradle plugin and autolinking, small mistakes there can break the entire build.

This is one of the first places I would inspect if the error looks structural instead of library-specific.

4. Check whether this is really a cache problem

Sometimes it is. Sometimes it is not.

I would only treat it as a cache issue when the error actually suggests things like:

temp workspace move failures
corrupted transforms
unexpected stale build behavior
dependency artifacts behaving inconsistently

In that case, I would think about:

Gradle daemon state
.gradle cache corruption
android/.gradle
android/build
whether Android Studio or another process is holding locks

But I would not start by deleting everything automatically unless the error really points that way.

5. Check native dependencies and recently added packages

If the build worked before and stopped working after adding or updating something, that is one of the strongest signals you have.

I would ask:

what changed last?
did I add a native dependency?
did I update Firebase packages?
did I change Expo/native modules?
did I update React Native or Gradle-related files?

That often gives a faster answer than staring at logs in isolation.

6. Watch for autolinking and native module issues

React Native Android builds often fail because a native module was not linked/configured the way the project expects.

This gets more likely when:

mixing Expo modules with bare React Native config
using libraries with native setup steps
upgrading React Native without updating supporting config
relying on autolinking that did not actually complete properly

If the error mentions package resolution, missing generated files, or native tasks around module setup, I would treat autolinking as a serious suspect.

7. Distinguish machine/setup problems from project problems

Sometimes the project is broken.

Sometimes the machine is.

That is an important difference.

I would think about machine/environment issues when the error points toward:

JDK problems
missing Android SDK components
PATH / environment variable issues
SSL / certificate / dependency download failures
local file locking or permissions

That is why a build issue can appear “random” even when the project itself has not changed much.

8. If Firebase is involved, do not assume it is only a Firebase issue

Firebase-related packages can surface as Android build failures even when the deeper cause is one of these:

dependency mismatch
outdated native setup
plugin/version conflict
Gradle packaging issue
release/debug configuration difference

So if the failure starts after adding Firebase or changing Firebase setup, I would still inspect the Android build chain broadly instead of narrowing too fast.

A practical mental model

When I see “React Native Android build failed,” I usually sort the possibilities into these buckets:

Bucket 1: Build system

Gradle
AGP
Kotlin
plugin management
wrapper version

Bucket 2: Native integration

autolinking
native modules
Expo/native mix
Firebase native setup

Bucket 3: Local environment

JDK
SDK
PATH
cache corruption
SSL/certificate/download issues

That mental model helps me avoid random debugging.

What I would not do first

I would not immediately:

reinstall the whole machine setup
randomly edit multiple Gradle files
downgrade several libraries at once
clear every cache without understanding the error
assume the last line in the terminal is the root cause

That usually creates more noise.

My practical order of checks

If a React Native Android build fails, this is the order I would usually go through:

find the first meaningful error in the output
check version compatibility across RN / Gradle / AGP / Kotlin / JDK
inspect settings.gradle and plugin resolution
review the most recent package or config change
check native module/autolinking issues
only then treat it as cache/environment cleanup if the error points there

That order tends to save time.

Final takeaway

“React Native Android build failed” is not one problem.

It is usually one of a few repeated categories:

version mismatch
plugin/config problem
native integration issue
cache/environment issue

The faster you identify which category you are in, the faster the build becomes fixable.

[DISCUSS] The “Never 0.00” Challenge — design a resilient price pipeline (client → edge) together

Mon, 29 Sep 2025 12:26:24 +0000

[DISCUSS] The “Never 0.00” Challenge — design a resilient price pipeline (client → edge) together

New group, first thread. Let’s start with a problem every finance app faces: your quotes flicker to 0.00 right when users need truth. How do we design a pipeline that never panics, stays fast, and makes the UI explainable?

I’m 22s from Pocket Portfolio (OSS dashboard: CSV → live P/L → Mock-Trade Lab). We’ve been hardening our price path and want to compare notes with you — architects, frontenders, edge-folk, crypto quants, and a11y pros.

The story (2 mins)

You’re rendering a positions grid. Provider “A” hiccups for 900 ms, “B” is slow in one region, and “C” returns a weird NaN. Your UI shows 0.00 or a spinner graveyard. Users lose trust.

We flipped the rule: it’s better to show a clearly tagged stale-but-true quote than a shiny 0.00. The UX stays calm, and the system buys enough time to recover.

The pattern (client → edge)

Client
  └── fetch quote(sym) with 1.4s budget
      └── Edge function (region-local)
          ├─ Try P1 (timeout 1.4s) -> OK? return
          ├─ Try P2 (1.4s) -> OK? return
          ├─ Try P3 (1.6s) -> OK? return
          └─ else: return last-known-good (stale:true) + tiny error summary
Cache
  └── KV: sym -> { price, ts, src }  // updated on successful hits

Key properties:

Short, brutal timeouts per provider (fail fast).
Rotation and backoff to avoid “thundering herd”.
Last-known-good as final fallback (with a stale flag).
Zero logs spam — count errors, sample detail, keep it cheap.

Tiny TypeScript example (edge)

// /edge/quote.ts (simplified)
const providers = [
  { name: 'p1', url: env.P1_URL, timeoutMs: 1400 },
  { name: 'p2', url: env.P2_URL, timeoutMs: 1400 },
  { name: 'p3', url: env.P3_URL, timeoutMs: 1600 },
];

export async function getQuote(sym: string) {
  for (const p of providers) {
    try {
      const ctl = new AbortController();
      const t = setTimeout(() => ctl.abort(), p.timeoutMs);
      const r = await fetch(`${p.url}/q?symbol=${sym}`, { signal: ctl.signal, cf:{ cacheTtl: 10 }});
      clearTimeout(t);
      if (!r.ok) continue;
      const { price } = await r.json();
      if (Number.isFinite(price)) {
        await KV.put(`q:${sym}`, JSON.stringify({ price, ts: Date.now(), src: p.name }), { expirationTtl: 120 });
        return { price, src: p.name, stale: false };
      }
    } catch {}
  }
  const last = await KV.get(`q:${sym}`);
  const cached = last ? JSON.parse(last) : null;
  return { price: cached?.price ?? null, src: cached?.src ?? 'none', stale: true };
}

UX that earns trust (copy/paste checklist)

✅ Never show 0.00 unless a symbol truly trades at zero (rare).
✅ If stale, show a subtle chip: Last update 28s • p2 with tooltip “Provider fallback active”.
✅ Keyboard-first: when a value changes, announce to SRs (aria-live="polite") and use diff-highlights that fade in <1s.
✅ Explain the why: on hover, show “Switched p1→p2 (timeout)”.
✅ Error CSV for failed imports; same spirit: explain, don’t mystify.

Mini-spec template (fill in and post as a reply)

policy:
  ttl_cache_seconds: 10
  providers:
    - name: p1
      timeout_ms: 1400
    - name: p2
      timeout_ms: 1400
    - name: p3
      timeout_ms: 1600
  final_fallback: last_known_good
  stale_badge_after_ms: 15000
  count_telemetry: true   # no PII, just counters
ui:
  show_stale_chip: true
  announce_changes: polite
  hover_explain: provider_switch
observability:
  per_region_counters: true
  sample_errors: 0.05

Post your filled YAML + any trade-offs (e.g., mobile vs desktop, crypto vs equities). We’ll review and suggest tweaks.

One-hour build (join in)

If you’ve got an hour and want something concrete:

Add the stale chip to your quote component (text + tooltip).
Implement the second provider with timeouts (even a mock server).
Store last-known-good in a tiny KV/local cache.
Paste a 10s GIF here. We’ll give quick notes.

What you get back

Peer review on your policy & code snippet
A reusable fallback policy you can ship this week
A shout-out in our next Pocket Portfolio dev post (and we’ll link your repo)

Why this group exists (and where we’re going)

We care about open finance, DeFi, cryptography, and accessible design. We’ll run Spec Clinics, Paper Club, and Ship Fridays. Next threads will cover:

Broker CSV normalization (share one redacted row)
Keyboard-first dashboards (a11y = speed)
Wallet UX & security (MPC/AA, seedless recovery)

Introduce yourself below (stack, timezone, what you’re building). Then drop your fallback policy reply. Let’s make “never 0.00” the default. ️✨

— 22s (Pocket Portfolio)
App: pocketportfolio.app/app • Repo: github.com/PocketPortfolio/Financialprofilenetwork

Welcome to CoderLegion 22s

Sun, 28 Sep 2025 20:07:11 +0000

Building finance tools people actually trust: a practical playbook (from the Pocket Portfolio trenches)

I’m 22s, one of the folks behind Pocket Portfolio — an open-source, no-paywall investing dashboard where you can import a CSV -> get clean live P/L, and model trades in a Mock-Trade & Scenario Lab without touching real totals.

I’ve shipped and broken my fair share of features. This post is the short list of things that made a night-and-day difference for us — equal parts tech, product, and what’s next.

Use anything here in your own project. If you want to kick the tires, the app + repo are at the end.

1) Technical: design for “no 0.00s” (fallbacks that fail gracefully)

Finance UI dies when prices flicker to 0.00. Our rule: client -> edge fallbacks with light telemetry and circuit-breakers.

// edge/fallbackQuote.ts (pseudo)
const providers = [
  { name: 'p1', url: env.P1_URL, timeoutMs: 1400 },
  { name: 'p2', url: env.P2_URL, timeoutMs: 1400 },
  { name: 'p3', url: env.P3_URL, timeoutMs: 1600 },
];

export async function getQuote(sym: string) {
  const errors: string[] = [];
  for (const p of providers) {
    try {
      const ctl = new AbortController();
      const t = setTimeout(() => ctl.abort(), p.timeoutMs);
      const r = await fetch(`${p.url}/q?symbol=${sym}`, { signal: ctl.signal, cf: { cacheTtl: 10 }});
      clearTimeout(t);
      if (!r.ok) throw new Error(`${p.name}:${r.status}`);
      const { price } = await r.json();
      if (!isFinite(price)) throw new Error(`${p.name}:NaN`);
      return { price, src: p.name };
    } catch (e: any) {
      errors.push(String(e.message));
      // soft failover: keep trying; never return 0
    }
  }
  // last resort: return "stale but not zero"
  const cached = await KV.get(`q:${sym}`); // store last good
  return { price: cached?.price ?? null, stale: true, errors };
}

Why it works

Fast happy path from provider 1 with short TTL.
Soft failover and never-zero fallback (last known good).
Errors are counted, not logged to death.

2) Technical: CSV imports that don’t make people rage-quit

You will never have every broker format. Make it survivable:

type ImportRow = {
  raw: Record<string, string>;  // source columns intact
  norm?: { sym: string; qty: number; price: number; ts: string };
  err?: { code: 'PARSE'|'SCHEMA'|'MISSING'; hint: string };
};

UX rules that helped immediately

Always show a sample file (eToro/Coinbase/Generic) and a Download error CSV when something fails.
Ask users to paste one redacted row in an issue; ship the mapping the same day.
Keep the import stateless — users can re-run safely.

3) Product: ship the “Are we sure?” layer

If you build tools that move money, people need a rehearsal. Our answer: a Mock-Trade & Scenario Lab that is:

Instant: Add TSLA +2 @ 260 with zero setup.
Isolated: Mock totals never touch real P/L.
Obvious: A big "mock trades active" chip, and a reset.

This one feature cut buyer’s remorse reports to near zero. Whatever you’re building, ask: What’s the one safe preview my user needs before a hard commit?

4) Business: one metric that punches above its weight

Time-to-first-insight (TTFI)
From first page load -> the moment a user sees something true about their portfolio. We track it like performance.

Things that reduce TTFI:

Sample CSVs in the modal
Default scenario ("add 1 share") with undo
Fallback quotes (the “no 0.00s” rule)

If your TTFI is < 60 seconds, activation will feel different.

5) Next frontier (where we’re headed)

Keyboard-first dashboards: a11y that doubles as speed. Arrow/Home/End for the grid; M opens Mock-Trade; ? shows shortcuts.
Explainers, not black boxes: when totals change, show why ("+2 TSLA @ 260 changed delta P/L +$48"). Debuggable numbers build trust.
Local-first where it matters: scenarios and recent quotes cached on device; sensitive bits never have to round-trip.

If you’re exploring the same things, I’d love to swap notes.

What we’re building (and where to try it)

Pocket Portfolio is open-source and free to use:

Good first issues right now

CSV mapping for a new broker format (drop one redacted row)
Playwright test for the error-CSV -> fix -> success loop
Light UI polish on the Mock-Trade modal

If you have thoughts on price fallbacks, import UX, or keyboard nav, hit me. I’ll review your project back — README, a11y, or a small PR.

— 22s
Founder, Pocket Portfolio

Using Firebase and Stripe for Modern Web Applications

Mon, 18 Aug 2025 20:25:55 +0000

Using Firebase and Stripe for Modern Web Applications

Building secure, scalable, and efficient applications often requires integrating authentication, databases, and payment systems. Two popular tools that developers rely on are Firebase and Stripe. Together, they provide a seamless backend + payment infrastructure that accelerates development without heavy server management.

In this tutorial, we’ll walk through how to integrate Firebase and Stripe in your project, with best practices for performance, serverless deployment, and real-world scenarios.

Why Use Firebase + Stripe?

Firebase handles:

Authentication (Google, GitHub, Email, Phone, etc.)
Realtime database & Firestore
Hosting & serverless functions
Notifications and cloud messaging

2.Stripe provides:

Secure and compliant payments
Subscriptions and billing
Global payment methods
Scalable APIs

When combined, Firebase + Stripe lets you build production-ready SaaS, e-commerce, or subscription apps with minimal backend code.

Setting Up Firebase

Go to the Firebase Console and create a new project
Add Firebase Authentication → enable Email/Password or OAuth
providers.
Set up Cloud Firestore for storing user data and transactions.
Deploy backend logic using Firebase Cloud Functions (powered by
serverless framework).

Setting Up Stripe

Create a free account on Stripe.
From the dashboard, copy your API keys.
Install the Stripe SDK:

npm install stripe firebase-admin firebase-functions
Create a test product or subscription plan in your Stripe Dashboard.

Integrating Firebase Cloud Functions with Stripe

Example function for creating a checkout session:

const functions = require("firebase-functions");
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

exports.createCheckoutSession = functions.https.onCall(async (data, context) => {
  const session = await stripe.checkout.sessions.create({
    payment_method_types: ["card"],
    line_items: [
      {
        price: data.priceId,
        quantity: 1,
      },
    ],
    mode: "subscription",
    success_url: "https://yourapp.com/success",
    cancel_url: "https://yourapp.com/cancel",
  });
  return { id: session.id };
});

This function can be called from your frontend using Firebase SDK.

Best Practices for Performance & Security

Use a bastion server or secure environment for sensitive API
operations.
Deploy in serverless containers for scalability.
Ensure PCI compliance via Stripe’s hosted checkout.
Use Firebase Authentication to link payments with user accounts.
Optimize billing operations with server optimization techniques.

Advanced Use Cases

SaaS Apps → Manage serverless ML workflows, bill users per usage.
Gaming Platforms → Use lambda GPUs or serverless GPU for compute
while charging via Stripe.
Virtual Desktops → Combine with non-persistent VDI and AWS AppStream
vs Workspaces billing.
Hybrid Architectures → Deploy with on premises servers + Firebase
Cloud Functions.
Frontend Hosting → Integrate with Vercel Serverless or similar
providers.

Conclusion

By combining Firebase and Stripe, you eliminate the need for managing on prem servers, payment gateways, or complex authentication stacks. This integration is ideal for startups, SaaS projects, and enterprise systems looking for top-rated serverless hosting for frontend developers.

Learn how to integrate Firebase AI Logic into your iOS app.

Sun, 08 Jun 2025 20:36:07 +0000

Implementing Firebase AI Logic in Your iOS App with Swift

Google Firebase has introduced AI Logic, a new way to build intelligent, dynamic behavior into your mobile apps using natural language prompts and structured logic—without needing to build or fine-tune your own models.

In this guide, we’ll walk through how to integrate Firebase AI Logic into your iOS app using Swift, from setup to implementation.

What Is Firebase AI Logic?

Firebase AI Logic is a managed service that allows you to define, test, and run AI-powered logic blocks using a mix of prompts and structured configuration. Think of it as serverless AI functions that take inputs, apply logic, and return structured outputs.

With AI Logic, you can:

Create logic using natural language prompts.
Call this logic from your iOS app using the Firebase AI SDK.
Use AI-generated decisions to personalize your UI, make recommendations, and more.

Requirements

Xcode 16.2+
iOS 15+ or macOS 12+
Firebase SDK v11.13.0+
A Firebase-connected app

Firebase Console Setup

Go to your project in the Firebase Console.
Under AI, select AI Logic.
Tap Start, then under Gemini Developer API, tap Start using this API.
In the dialog that appears, tap Enable. Wait until the API is enabled.
Click Continue to complete activation.

Enable App Check (Recommended)

To restrict API calls to authorized devices:

In the AI Logic panel, click Register on App Check.
In the App Check dashboard, click Start, then Register for the app you want to secure.
If your app supports only iOS 14+, you can register App Attest only. Otherwise, also register Device Check.
Complete all required fields and finish registration.

In the AI Logic dashboard, go to the APIs section.
Select Firebase AI Logic APIs, then click Apply to enforce App Check.

Enabling enforcement can take up to 30 minutes to propagate.

Enable App Transport Security Exception

In my case, I also needed to enable App Transport Security Exception.
To do this, go to Project → Signing & Capabilities → Add Capability → App Transport Security Exception.
Inside the capability, tap the + button and add googleapis.com.

Code Implementation

App Check

Add the Firebase App Check library to your project.
Create a file named AppCheckManager.swift:

import Firebase
import FirebaseAppCheck
 
final class AppCheckManager: NSObject, AppCheckProviderFactory {
 
public static let shared = AppCheckManager()
 
func createProvider(with app: FirebaseApp) -> AppCheckProvider? {
return AppAttestProvider(app: app)
}
 
public func setProviderFactory() {
#if DEBUG
 AppCheck.setAppCheckProviderFactory(AppCheckDebugProviderFactory())
#else
AppCheck.setAppCheckProviderFactory(self)
#endif
}
}

In your AppDelegate or main app file, before FirebaseApp.configure(), add:

AppCheckManager.shared.setProviderFactory()

In your Signing & Capabilities, add the App Attest entitlement.
In the generated .entitlements file, change the App Attest mode from development to production
To enable Firebase debug logging:
- Go to Product > Scheme > Edit Scheme…
- Select Run > Arguments
- Add a new argument: -FIRDebugEnabled

Run the app. You should see a log like this:

<Warning> [AppCheckCore][I-GAC004001] App Check debug token: '1E04B27F-15CD-46FA-862B-ED8E67841C9D'.

Copy this token, go to App Check > Apps in the Firebase Console, click the three dots next to your iOS app, choose Manage debug tokens, then add and save the token.

You're done setting up App Check.

Using Firebase AI Logic

Add the FirebaseAI package:

Go to General > Frameworks, Libraries, and Embedded Content
Tap the + button and add FirebaseAI

Simple Response

To generate a text response from a prompt:

import FirebaseAI
 
func callAI() async {
do {
let prompt = "Your prompt here..."
let ai = FirebaseAI.firebaseAI(backend: .googleAI())
let model = ai.generativeModel(modelName: "gemini-2.0-flash")
let response = try await model.generateContent(prompt)
 
if let answer = response.text {
print("FirebaseAI response:", answer)
}
} catch {
print("FirebaseAI error:", error)
}
}

Streamed Response

For a more responsive UI, stream partial results as they’re generated:

func aiStrem() async {
do {
let prompt = "Your prompt here..."
let ai = FirebaseAI.firebaseAI(backend: .googleAI())
let model = ai.generativeModel(modelName: "gemini-2.0-flash")
let response = try model.generateContentStream(prompt)
 
for try await chunk in response {
if let text = chunk.text {
print("FirebaseAI text:", text)
}
}
} catch {
print("FirebaseAI error:", error)
}
}

Troubleshooting

HTTP 403 Errors

If you see a 403 error:

Go to the Google Cloud Console
Select your Firebase project
Navigate to APIs & Services > Credentials
Find your iOS key, click it
Ensure Firebase AI Logic API is enabled under API Restrictions. If not:
- Select it
- Click Save
- Wait up to 30 minutes before retrying

If the error persists:

Temporarily switch to “Don’t restrict key” mode to test.
You may also try disabling and re-enabling App Check for Firebase AI Logic.

Conclusion

Firebase AI Logic allows iOS developers to integrate intelligent logic blocks into apps without the need to manage ML models or infrastructure. With App Check, you can keep API access secure, and with just a few lines of Swift, you can call or stream AI responses to build truly dynamic user experiences.

Thanks for reading! If you have questions or want a complete sample project, feel free to reach out or leave a comment.

DevLog 20250523: Firebase Auth

Fri, 23 May 2025 19:06:57 +0000

The Authentication Problem

Let's face it: develop a custom authentication service is conceptually straightforward but practically troublesome. You either allow user registration or not, then authenticate by taking a look at username and password (likely hashed) against database, then provide user profile results for authorized users. Throughout the process you might set browser cache, deal with (generated) API keys for app usages (so password need not be sent every time). It's a handful of steps, and lots of work to code everything piece by piece. Worse, there is a whole database to worry about. One would naturally expect, such a thing should just exist as a service. Yes, there is.

Quick Comparison

|Platform|What it is|Free tier|Pros|Cons|
|-|-|-|-|-|
|AWS Cognito | Amazon’s identity and user‑management service for web and mobile apps, integrating natively with API Gateway/Lambda and Amplify JS. | 10,000 MAUs for direct/social sign‑in + 50 MAUs for SAML/OIDC federation; Identity Pools are free | No extra vendor to learn; pay only for MAUs above free tier; built‑in social and SAML/OIDC support; AWS‑managed hosted UI. | Learning curve around User Pools vs Identity Pools and IAM policies.|
|Auth0 | Popular identity platform with SDKs for nearly every framework. | 25,000 MAUs; unlimited social & Okta connections; 5 organizations; 5 actions/forms; passwordless & custom domain | Intuitive, developer‑friendly dashboard; extensible via Rules (JavaScript); excellent documentation. | Pricing increases sharply above free tier.|
|Firebase Authentication | Google’s auth service, part of Firebase/GCP. | Unlimited email/password, anonymous, and most social sign‑ins; pay only for phone‑SMS verification | Fastest setup for web/mobile; pre‑built UI widgets; seamless integration with other Firebase services. | SMS‑based authentication incurs per‑message cost.|
|Supabase Auth | Open‑source Firebase alternative built on PostgreSQL. | Unlimited API requests; 50,000 MAUs; 500 MB database; 5 GB bandwidth; 1 GB file storage; community support | True SQL under the hood; you own your data; robust JS client. | Free projects pause after 1 week of inactivity; limited to 2 active projects.|
|Netlify Identity | Netlify’s built‑in auth service powered by GoTrue. | Up to 1,000 registered users per site | Seamless drop‑in for Netlify‑hosted. | Limited to Netlify sites; basic compared to full‑blown IDaaS; deprecated as of Feb 28, 2025 .|
|Okta Developer Edition | Enterprise‑grade identity platform in a developer sandbox. | 100 MAUs | Enterprise features: OpenID Connect federation, SCIM provisioning, lifecycle hooks, universal directory | Console can feel heavy for hobby projects.|

Recommendations:

Full AWS: Use AWS Cognito (with Amplify libraries) to stay within the AWS ecosystem and enjoy a free tier up to 10 K direct/social MAUs and 50 MAUs for SAML/OIDC.
Rapid prototyping: Firebase Authentication for the fastest setup (unlimited email/password/social; pay only for SMS).
SQL‑power & control: Supabase Auth if you need open‑source Postgres‑based auth with a 50 K MAU free tier and 500 MB of built‑in storage.

For reasons I would not disclose, we picked Firebase for Divooka and other Methodox services.

The Setup

For Firebase Auth, the "API Key" just identifies the application and can totally be shown on the client side script.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8"/>
  <title>Custom Email/Password Auth</title>
  <script type="module">
    import { initializeApp } from "https://www.gstatic.com/firebasejs/11.8.1/firebase-app.js";
    import {
      getAuth,
      createUserWithEmailAndPassword,
      updateProfile,
      signInWithEmailAndPassword,
      signOut
    } from "https://www.gstatic.com/firebasejs/11.8.1/firebase-auth.js";

    // Firebase web config
    // For Firebase JS SDK v7.20.0 and later, measurementId is optional
    const firebaseConfig = {
        apiKey: "*********************",
        authDomain: "*********************",
        projectId: "*********************",
        storageBucket: "*********************",
        messagingSenderId: "*********************",
        appId: "*********************",
        measurementId: "*********************"
    };
    // Initialize Firebase
    const app = initializeApp(firebaseConfig);
    const auth = getAuth(app);

    // Register a new user
    async function registerUser() {
      const email = document.getElementById("regEmail").value;
      const password = document.getElementById("regPass").value;
      const username = document.getElementById("regName").value;
      try {
        const cred = await createUserWithEmailAndPassword(auth, email, password);
        // Set a displayName on the Firebase user record
        await updateProfile(cred.user, { displayName: username });
        alert("Registration successful! You can now log in.");
      } catch (e) {
        console.error(e);
        alert("Registration error: " + e.message);
      }
    }

    // Login existing user
    async function loginUser() {
      const email = document.getElementById("loginEmail").value;
      const password = document.getElementById("loginPass").value;
      try {
        const cred = await signInWithEmailAndPassword(auth, email, password);
        const idToken = await cred.user.getIdToken();

        // Call your API
        const resp = await fetch("https://myapi.com/profile", {
          headers: { "Authorization": "Bearer " + idToken }
        });
        if (!resp.ok) throw new Error(await resp.text());
        const profile = await resp.json();
        document.getElementById("output").textContent = JSON.stringify(profile, null, 2);
      } catch (e) {
        console.error(e);
        alert("Login error: " + e.message);
      }
    }

    // Logout
    function logoutUser() {
      signOut(auth);
      document.getElementById("output").textContent = "";
      alert("Signed out");
    }

    window.onload = () => {
      document.getElementById("btnRegister").onclick = registerUser;
      document.getElementById("btnLogin").onclick    = loginUser;
      document.getElementById("btnLogout").onclick   = logoutUser;
    };
  </script>
</head>
<body>
  <h2>Register</h2>
  <input id="regName"  type="text"     placeholder="Username"/><br/>
  <input id="regEmail" type="email"    placeholder="Email"/><br/>
  <input id="regPass"  type="password" placeholder="Password"/><br/>
  <button id="btnRegister">Register</button>

  <hr/>

  <h2>Login</h2>
  <input id="loginEmail" type="email"    placeholder="Email"/><br/>
  <input id="loginPass"  type="password" placeholder="Password"/><br/>
  <button id="btnLogin">Log In</button>
  <button id="btnLogout">Log Out</button>

  <h3>Profile:</h3>
  <pre id="output"></pre>
</body>
</html>

Create API Key

To create API key, navigate to the project then find "Add App" in Project Settings, which is a hidden menu.

References

Official doc on API key, which is not very clear without pictures: here

Coder Legion - Recent posts tagged firebase

Telemetry: Shared Analytics and Crash Reporting in Kotlin Multiplatform

What I had before

The interface lives in commonMain

Android: the easy side

iOS: the Swift bridge

Two other ways to bring the SDK in

Kotlin exceptions on iOS are not Kotlin exceptions

Where the calls go

Gotchas

Wrapping up

How to Fix Firebase `PERMISSION_DENIED` Errors in React Native

First, find out which Firebase service is rejecting the request

Check your Firestore security rules

Check whether the user is actually authenticated

Check that the rule matches the path you are actually using

Be careful with nested Firestore documents

Do not use allow read, write: if true as the final fix

Check whether you are using the correct Firebase project

Check your Android and iOS Firebase configuration

Check Firebase App Check

Development and production can behave differently

Check the exact user ID being used

Check your Storage rules if the error happens during uploads

Check Realtime Database rules separately

Use the Firebase Emulator when appropriate

Look at what changed right before the error

A simple debugging order

1. Identify the Firebase service

2. Read the exact path

3. Check authentication

4. Check the security rule

5. Check the values used by the rule

6. Check the Firebase project

7. Check App Check

8. Check platform-specific configuration

9. Reproduce the problem again

Example: finding a simple rules mistake

Final thoughts

The Firebase Auth bug that took me 3 days to find (it wasn't Firebase's fault)

How I Structured My Firestore Data Model for an Anti-Proxy Attendance System

How I Structured My Firestore Data Model for an Anti-Proxy Attendance System

The First Question: What Really Needs to Live in the Database?

Firestore Forces a Different Way of Thinking

I Still Remember the 50,000 Read Problem

Designing Around Actual Access Patterns

Keeping Attendance as a Separate Record

More Data Does Not Automatically Mean a Better Database

What an Attendance Request Actually Contains

Thinking Carefully About Reads and Writes

Firestore Security Goes Beyond Security Rules

Offline Support Changes the Data Lifecycle

What I Would Avoid Doing

The Bigger Lesson From the Data Model

What I Would Change Today

Final Thoughts

What's Next?

🔗 Project

💬 Your turn

Supabase Auth vs Firebase Auth: Which One Should You Choose in 2026?

Why This Comparison Is Tricky

Quick Answer

Supabase Auth vs Firebase Auth: Which Is Better for Next.js?

Supabase Auth vs Firebase Auth: Feature Comparison

Architecture: The Real Difference

Supabase Auth Runs on Postgres

Firebase Auth And Firestore

Setting Up Supabase Auth in Next.js 16

Step 1: Install Dependencies

Step 2: Add Environment Variables

Step 3: Create the Browser Client

Step 4: Create the Server Client

Step 5: Add the Auth Proxy (Middleware)

Step 6: Sign In With Email and Password

Step 7: Protect Data with Row Level Security

Setting Up Firebase Auth in Next.js 16

Step 1: Install Dependencies

Step 2: Add Environment Variables

Step 3: Initialize Firebase (Client Side)

Step 4: Sign In With Email and Password

Do not use `allow read, write: if true` as the final fix

How to Fix `MismatchSenderId` in Expo EAS Push Notifications Across Multiple Environments