DEV Community: Andy Staudinger

Two production apps, one framework: what React Native taught us in 2026

Andy Staudinger — Wed, 07 Oct 2026 13:02:23 +0000

Most "React Native vs. Flutter" posts compare benchmarks. This one doesn't.

In 2026 I shipped two React Native apps for real businesses. People use them to run their working day, not to try out a demo. Here is what actually mattered, including two mistakes that cost us time.

TL;DR

Treat the app as a second door into your backend, not a second system.

Start with Expo. Go bare only when Expo starts slowing you down.

Build roles and permissions in week one.

"Done" means tested on real devices, with real data, over time.

Store requirements are engineering work. Plan them early.

The two apps
Lesson 1: the app is a second door, not a second system
Lesson 2: Expo or bare? We used both
Lesson 3: permissions belong in week one
Lesson 4: the bug 204 tests didn't catch
Lesson 5: the store is part of the build
So, React Native or Flutter?

The two apps

myNextDays is an app for holiday-rental hosts and small hotels. It puts bookings, the occupancy calendar, guest messages and cleaning tasks on the phone. It is live on Google Play.

Windhunde is a monitoring app for a company that operates and services wind turbines. It shows live values and alarms, and lets authorised staff control turbines remotely. It runs on iPhone, iPad and Android.

Two very different industries. Same framework. Two different setups.

	myNextDays	Windhunde
Industry	Holiday rentals	Wind energy
Setup	Bare React Native	Expo + Expo Router
Runtime	New Architecture, Hermes	New Architecture, Hermes
Backend	FastAPI + self-hosted Supabase	FastAPI + PostgreSQL/TimescaleDB
Hosting	Hetzner, EU	Hetzner, Germany
Size	21 screens, 204 tests	10 screens, 200 commits

Lesson 1: the app is a second door, not a second system

The most important decision in both projects had nothing to do with React Native.

Neither app has business logic of its own. Both call the same API as the web dashboard and work on the same data. Prices, permissions and status changes are always decided by the server.

It sounds boring. But it prevents the most common problem with business apps: web and app slowly drifting apart until they show different numbers.

With one source of truth, they can't contradict each other. And a new feature on the web can be brought to the app without re-implementing rules.

What this means for you: before you pick a framework, decide where the rules live. If the answer is "in the app", stop and rethink.

Lesson 2: Expo or bare? We used both

myNextDays is a bare React Native project. Windhunde uses Expo with Expo Router. Both work. They just fit different situations.

You need…	Our pick	Why
iOS, iPadOS and Android from day one	Expo	Secure storage and biometric login come ready-made
File-based routing that mirrors a Next.js web app	Expo Router	Same route structure on web and mobile
Full control over native projects and push setup	Bare	Deep integration with existing workflows and FCM

Expo Router turned out to be a quiet win for Windhunde. Its file-based routes mirror the Next.js app directory of the web dashboard. That keeps both codebases easy to navigate. It also gives every screen its own deep link, which is exactly what you need when a push notification should open one specific alarm.

Our rule of thumb: start with Expo unless something speaks against it. Switch to bare once you spend more time working around Expo than building with it.

Lesson 3: permissions belong in week one

myNextDays has six roles, from admin down to cleaning staff.

Exactly one place in the code decides what someone sees. It uses the permissions the server returns, not the role name. If an unknown role shows up, the app signs the user out instead of falling back to the manager dashboard.

Here's the idea in simplified form:

// One place decides what a user sees, driven by server permissions.
type Me = { permissions: string[] };

const TABS = [
  { key: "dashboard", needs: "dashboard.view" },
  { key: "calendar", needs: "calendar.view" },
  { key: "bookings", needs: "bookings.view" },
  { key: "tasks", needs: "tasks.view" },
] as const;

export function tabsFor(me: Me | null) {
  if (!me) return null; // not signed in
  const tabs = TABS.filter((t) => me.permissions.includes(t.needs));
  // Unknown or empty permission set: sign out instead of guessing.
  return tabs.length > 0 ? tabs : "sign-out";
}

Amounts and full guest names are masked by the backend. The app never fills them in.

Had we added permissions at the end, we would have touched every screen twice. It's not a React Native problem. But it's where app budgets regularly tip over.

Lesson 4: the bug 204 tests didn't catch

myNextDays has 22 test suites with 204 tests. They cover token storage and refresh, inbox access rules, time zones, status chains and account deletion.

Beta testers still found a bug none of them showed.

The app crashed in the morning. The reason: the auth token's expiry time only lived in memory. When the OS killed the app overnight, that value was gone. On fresh test devices this never happened, because nobody left them alone for a night.

The fix was small. Simplified:

import * as SecureStore from "expo-secure-store";

// Before: expiresAt lived only in memory and was lost
// when the OS killed the app overnight.
// After: persist it next to the token and read it back on cold start.
export async function saveSession(token: string, expiresAt: number) {
  await SecureStore.setItemAsync("token", token);
  await SecureStore.setItemAsync("expiresAt", String(expiresAt));
}

export async function needsRefresh(): Promise<boolean> {
  const raw = await SecureStore.getItemAsync("expiresAt");
  return !raw || Date.now() > Number(raw) - 60_000; // refresh 1 min early
}

(Expo's secure store keeps the snippet short. In the bare project the same idea runs on the platform keychain and keystore.)

Windhunde took the same lesson further. There, a task only counts as done after a verification loop on real devices with real data:

App and web show the same live value in the same second, proven by two screenshots side by side.
After returning from the background, the app fetches a fresh snapshot.
After toggling airplane mode, it reconnects without a restart.
It runs for 30 minutes without a single error in the server log or the app console.

Those checks produced features nobody had specified, like a visible connection-status bar.

Lesson 5: the store is part of the build

In-app account deletion, privacy details, the privacy manifest, Google's Data safety form. None of this is paperwork for launch day.

For myNextDays we checked the data-safety answers line by line against the final build. We found three things missing: photos, device IDs and crash data.

Then the screenshots. Ours were taken on an iPhone with an aspect ratio of 2.17:1. Google Play only accepts up to 2:1. We had to retake all of them.

Two things paid off in the end:

A read-only demo tenant with eight fictional properties. Store reviewers and sales demos use it, and no real guest data ever shows up in a screenshot. One lesson from production: users read the write-block as a bug. So now a permanent banner says "Demo: view yes, save no".
Data minimalism. The app has no analytics, ad or tracking SDK. On Android it requests only internet, notifications and camera. For hosts who handle guest data, that's a real sales argument. It only exists if you treat it as a requirement from day one.

So, React Native or Flutter?

Flutter is an excellent framework, especially when the design must look pixel-identical everywhere.

For us one thing tipped the scale: the existing web. Windhunde's dashboard is written in Next.js and React. With React Native we share the display and calculation logic as a TypeScript package between web and app. That saved more time than any benchmark lead could have.

So the honest answer is usually: it depends less on the framework and more on what you already have.

What's the one thing you wish you had known before shipping your first business app? I'd love to read your stories in the comments.

I'm Andy Staudinger, a freelance developer in Germany building websites and mobile apps for iOS and Android. The full case studies (in German): myNextDays · Windhunde. Next in this series: how the Windhunde app streams live data without polling.

Live data in React Native without polling: SSE, background handling and an honest status bar

Andy Staudinger — Wed, 07 Oct 2026 12:58:12 +0000

A wind turbine dashboard showed a value that looked perfectly fresh. It wasn't. The connection had dropped, the display had frozen, and nobody could tell.

In monitoring, that's the worst kind of bug. It doesn't crash. It just quietly lies.

This post shows how we built the live layer of the Windhunde app so that can't happen again: no polling, Server-Sent Events (SSE) end to end, and a status bar that always tells the truth.

TL;DR

Send a full snapshot first, then only deltas. Reconnecting becomes trivial.

In a native app, SSE is nicer than in the browser: you can send auth headers.

Keep the live logic in a platform-free TypeScript package and inject the transport.

When the app goes to the background, close the stream yourself. On return, show loading, never the last value.

Make freshness visible. A green dot says nothing about how old a value is.

The snippets are simplified to show the patterns. They are not copied from the production code.

The setup
The pipeline: from turbine to phone
Why SSE fits a native app better than the browser
Share the hard part between web and app
The OS kills your connection and won't tell you
An honest status bar
Charts that don't lie
What we left off the stream

The setup

Windhunde operates and services wind turbines. The platform has a web dashboard and a React Native app (Expo, Expo Router, Hermes, New Architecture) for iPhone, iPad and Android.

The brief was "1:1 with the web". Wrapping the dashboard in a WebView was ruled out. So was rewriting every formula for mobile, because that produces two versions of the truth within months.

The pipeline: from turbine to phone

The turbine controllers are old. They don't have a modern API. Each one exposes a ~600-byte XML file that mirrors its four-line text display.

Here's the flow:

A poller asks each controller for its state every two seconds. It sends a conditional GET with the last ETag. If nothing changed, the controller answers 304 with no body, and nothing is written.
On a real change, the importer writes a row to PostgreSQL (with TimescaleDB) and fires a NOTIFY.
A stream service LISTENs for that signal.
Every connected client gets a full snapshot of all turbines when it connects, then only deltas.

There is no polling in the web dashboard, and none in the app.

That snapshot-then-deltas contract is the backbone of everything that follows. It makes reconnecting trivial: you just connect again and start from a fresh snapshot.

Why SSE fits a native app better than the browser

In the browser, EventSource can't send custom headers. So you can't pass a bearer token, and the web dashboard has to use cookies.

A native app doesn't have that limitation. With react-native-sse, the app sends its token and tenant as normal headers:

import EventSource from "react-native-sse";

export function openStream(token: string, tenantId: string) {
  return new EventSource(`${API_URL}/stream/live`, {
    headers: {
      Authorization: `Bearer ${token}`,
      "X-Tenant": tenantId,
    },
  });
}

Same endpoint as the web. Cleaner transport.

Share the hard part between web and app

We moved the shared logic into one TypeScript package that both clients import:

number and unit formatting
freshness rules
mapping turbine states to colours
API schemas and the API client with retry logic
the core of the live connection: merging snapshot and deltas, reconnect rules, stall detection

The package has one strict rule: no browser globals and no hard-coded network calls. No window, no document, no localStorage. Anything that depends on the device is passed in from outside.

// shared/live.ts: runs in the browser and in React Native
export interface StreamTransport {
  // opens the stream and returns a function that closes it
  open(onEvent: (type: string, data: string) => void): () => void;
}

export function createLiveStore(transport: StreamTransport, notify: (s: State) => void) {
  let state: State = {};
  let close: (() => void) | null = null;

  function handle(type: string, data: string) {
    const payload = JSON.parse(data);
    if (type === "snapshot") state = indexById(payload.turbines);
    if (type === "delta") state = { ...state, [payload.id]: { ...state[payload.id], ...payload } };
    notify(state);
  }

  return {
    connect() { close?.(); close = transport.open(handle); },
    disconnect() { close?.(); close = null; },
  };
}

The web passes in a wrapper around the browser's EventSource. The app passes in react-native-sse.

One test loads the package under plain Node, with no DOM at all. If it's green, the code runs in both worlds. The extraction only counted as done once the web dashboard ran unchanged afterwards, without a single new warning.

The same idea applies to design. The web defines around a hundred design tokens. A script generates a TypeScript file from the web stylesheet, and the app reads its colours from there through NativeWind. Change a colour on the web, run the script, and the app follows.

The OS kills your connection and won't tell you

This is the part the browser hides from you.

iOS and Android drop network connections when an app goes to the background. They don't ask, and they don't send an error. If you ignore that, the app comes back showing frozen values that look exactly like live ones.

So the app handles it explicitly:

import { AppState } from "react-native";
import NetInfo from "@react-native-community/netinfo";

useEffect(() => {
  live.connect();

  const appSub = AppState.addEventListener("change", (s) => {
    if (s === "active") {
      markLoading();   // show loading, NOT the last known value
      live.connect();  // fresh snapshot, then deltas
    } else {
      live.disconnect(); // close it ourselves before the OS does
    }
  });

  // Wi-Fi <-> cellular: reconnect right away
  const netSub = NetInfo.addEventListener((s) => {
    if (s.isConnected) live.connect();
  });

  return () => { appSub.remove(); netSub(); live.disconnect(); };
}, []);

The key line is markLoading(). Until the new snapshot arrives, the screen shows a loading state. It never shows the last known value as if it were current.

An honest status bar

Every live screen has a bar at the top, for example "Live · updated 1 s ago".

A one-second tick updates the age of each value. After 60 seconds without new data, the value counts as stale and the bar says so.

const STALE_AFTER_MS = 60_000;

export function freshness(lastUpdate: number, now = Date.now()) {
  const age = now - lastUpdate;
  return { ageSeconds: Math.floor(age / 1000), stale: age > STALE_AFTER_MS };
}

This bar isn't decoration. It exists because of the incident at the top of this post. Since then one rule applies across the whole project: no silently swallowed errors, not on the server and not in the UI. If something is wrong, you can see it.

The turbine list follows the same idea. Each card shows "last contact 0 s ago" prominently, because a green marker alone tells you nothing about whether the value is one second or one hour old.

Charts that don't lie

The power chart starts with real history and then keeps growing from the live stream. Three rules keep it honest:

Gaps stay gaps. If measurements are missing, the line is not drawn across the hole. An outage must not look like a smooth curve.
The time axis ends at the last real data point, not at the device clock. Otherwise a stalled connection would look like a drop in power.
"Server error" and "no data in this range" are two different states, because they mean two different things.

What we left off the stream

Alarms deliberately don't hang off the live stream.

They are discrete events, not a continuous signal. And an alarm you can only see while the app is open in the foreground is useless for a control room. So alarms are fetched like normal data, and push delivery for them is already built into the backend.

How we knew it was done

A feature only counted as done after a verification loop on real devices against the production instance:

App and web show the same live value in the same second (two screenshots side by side).
After returning from the background, the app fetches a fresh snapshot.
After airplane mode on and off, it reconnects without a restart.
It runs for 30 minutes without a single error in the server log or the app console.

These checks are what produced the status bar and the clean background disconnect in the first place.

How do you handle stale data in your realtime apps? Polling, WebSockets, SSE, something else? Tell me in the comments, I'm curious what works for you.

I'm Andy Staudinger, a freelance developer in Germany building websites and mobile apps for iOS and Android. The full Windhunde case study (in German) is here. Previous post in this series: what two production React Native apps taught us in 2026.

Von 0 auf Production: Wie ich eine komplette Service-Plattform mit Next.js 15 + Firebase baute

Andy Staudinger — Tue, 27 Jan 2026 13:08:21 +0000

TL;DR

Ich habe Taskilo gebaut - eine komplette Service-Plattform, die Kunden mit verifizierten Dienstleistern verbindet. Von Handwerk über Reinigung bis Gartenpflege - alles auf einer Plattform.

In diesem ausführlichen Artikel teile ich:

🏗️ Architektur-Entscheidungen und warum ich sie getroffen habe
⚡ Performance-Optimierungen: Von 3.5s LCP auf unter 1.5s
🔐 Firebase Auth in Next.js Server Components
📦 Component-Architektur mit über 150 wiederverwendbaren Komponenten
🗺️ Google Maps Integration mit Performance-Optimierung
📅 Kalender- und Buchungssystem
💡 6 Monate Entwicklung: Was ich anders machen würde

Live Demo: taskilo.de

Source Code: GitHub

Die Ausgangslage: Das Problem

Jeder kennt es: Du brauchst einen Handwerker, Reinigungsservice oder Gärtner. Aber:

Vertrauen: Woher weißt du, ob der Anbieter seriös ist?
Verfügbarkeit: Endlose Telefonate um einen Termin zu finden
Preise: Keine Transparenz, böse Überraschungen auf der Rechnung
Kommunikation: WhatsApp-Chaos mit 5 verschiedenen Anbietern

Nach 3 No-Shows und 2 überteuerten Angeboten dachte ich: Das muss besser gehen!

Der Tech Stack im Detail

Nach Jahren Erfahrung mit verschiedenen Stacks habe ich mich für diese Kombination entschieden:

Frontend

Technologie	Version	Einsatz
Next.js	15.4	Framework mit App Router
React	19.2	UI Library
TypeScript	5.9	Type Safety
Tailwind CSS	4.0	Styling
shadcn/ui	Latest	UI Components
Framer Motion	12.x	Animationen
Zustand	5.0	State Management

Backend & Infrastruktur

Technologie	Einsatz
Firebase Firestore	NoSQL Datenbank
Firebase Auth	Authentifizierung
Firebase Functions	Serverless Backend
Firebase Storage	Datei-Upload
Vercel	Hosting & Edge Functions
Google Maps API	Karten & Geocoding

Dev Tools

Tool	Zweck
pnpm	Package Manager (schneller als npm)
Turbopack	Dev Server (10x schneller als Webpack)
Husky	Git Hooks
ESLint + Prettier	Code Quality
TypeScript strict mode	Keine `any` erlaubt

Projekt-Struktur: Skalierbare Architektur

Nach mehreren Refactorings bin ich bei dieser Struktur gelandet:

src/
├── app/                    # Next.js App Router
│   ├── (public)/          # Öffentliche Seiten
│   │   ├── page.tsx       # Landing Page
│   │   ├── services/      # Service-Kategorien
│   │   └── providers/     # Anbieter-Profile
│   ├── (auth)/            # Auth-Seiten
│   │   ├── login/
│   │   ├── register/
│   │   └── forgot-password/
│   ├── (dashboard)/       # Geschützter Bereich
│   │   ├── customer/      # Kunden-Dashboard
│   │   └── provider/      # Anbieter-Dashboard
│   └── api/               # API Routes
│       ├── auth/
│       ├── bookings/
│       └── webhooks/
├── components/
│   ├── ui/                # Basis-Komponenten (Button, Input, etc.)
│   ├── forms/             # Formular-Komponenten
│   ├── layouts/           # Layout-Komponenten
│   ├── cards/             # Card-Varianten
│   ├── maps/              # Google Maps Komponenten
│   └── providers/         # Context Provider
├── lib/
│   ├── firebase/          # Firebase Config & Helpers
│   ├── hooks/             # Custom React Hooks
│   ├── utils/             # Utility Functions
│   └── validations/       # Zod Schemas
├── types/                 # TypeScript Definitionen
└── styles/                # Globale Styles

Warum diese Struktur?

Route Groups (public), (auth), (dashboard): Ermöglichen unterschiedliche Layouts ohne URL-Änderung
Komponenten nach Funktion: Nicht nach Seite - so sind sie wiederverwendbar
Strikte Trennung: Firebase-Code nur in lib/firebase/

Deep Dive: Next.js 15 App Router

Server Components als Default

Der größte Paradigmenwechsel: Komponenten sind standardmäßig Server Components.

// app/providers/[id]/page.tsx
// Das ist ein Server Component - läuft NUR auf dem Server!

import { getProviderById } from '@/lib/firebase/providers';
import { ProviderProfile } from '@/components/providers/ProviderProfile';

export default async function ProviderPage({ 
  params 
}: { 
  params: Promise<{ id: string }> 
}) {
  const { id } = await params;

  // Direkter Datenbankzugriff - kein API-Call nötig!
  const provider = await getProviderById(id);

  if (!provider) {
    notFound();
  }

  return <ProviderProfile provider={provider} />;
}

// Metadata für SEO - auch serverseitig
export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { id } = await params;
  const provider = await getProviderById(id);

  return {
    title: `${provider?.name} | Taskilo`,
    description: provider?.description,
    openGraph: {
      images: [provider?.avatar || '/default-avatar.png'],
    },
  };
}

Wann "use client"?

Nur wenn wirklich nötig:

'use client';

// Interaktive Komponenten
import { useState, useEffect } from 'react';
import { useRouter } from 'next/navigation';

export function BookingCalendar({ providerId }: { providerId: string }) {
  const [selectedDate, setSelectedDate] = useState<Date | null>(null);
  const [availableSlots, setAvailableSlots] = useState<TimeSlot[]>([]);

  // Real-time Updates mit Firebase
  useEffect(() => {
    const unsubscribe = onSnapshot(
      query(collection(db, 'availability'), where('providerId', '==', providerId)),
      (snapshot) => {
        const slots = snapshot.docs.map(doc => doc.data() as TimeSlot);
        setAvailableSlots(slots);
      }
    );

    return () => unsubscribe();
  }, [providerId]);

  return (
    <Calendar
      selected={selectedDate}
      onSelect={setSelectedDate}
      availableSlots={availableSlots}
    />
  );
}

Server Actions: Goodbye API Routes

Für Mutations nutze ich Server Actions - kein Boilerplate mehr:

// actions/bookings.ts
'use server';

import { revalidatePath } from 'next/cache';
import { getCurrentUser } from '@/lib/auth';
import { adminDb } from '@/lib/firebase-admin';

export async function createBooking(formData: FormData) {
  // Auth Check
  const user = await getCurrentUser();
  if (!user) {
    throw new Error('Nicht eingeloggt');
  }

  // Validierung mit Zod
  const validated = bookingSchema.parse({
    providerId: formData.get('providerId'),
    serviceId: formData.get('serviceId'),
    date: formData.get('date'),
    time: formData.get('time'),
    notes: formData.get('notes'),
  });

  // Buchung erstellen
  const bookingRef = await adminDb.collection('bookings').add({
    ...validated,
    customerId: user.uid,
    status: 'pending',
    createdAt: new Date(),
  });

  // Benachrichtigung an Anbieter senden
  await sendProviderNotification(validated.providerId, bookingRef.id);

  // Cache invalidieren
  revalidatePath('/dashboard/bookings');
  revalidatePath(`/providers/${validated.providerId}`);

  return { success: true, bookingId: bookingRef.id };
}

Im Client:

'use client';

import { createBooking } from '@/actions/bookings';
import { useFormStatus } from 'react-dom';

function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    <Button type="submit" disabled={pending}>
      {pending ? 'Wird gebucht...' : 'Jetzt buchen'}
    </Button>
  );
}

export function BookingForm({ providerId }: { providerId: string }) {
  return (
    <form action={createBooking}>
      <input type="hidden" name="providerId" value={providerId} />
      {/* ... weitere Felder */}
      <SubmitButton />
    </form>
  );
}

Firebase in Server Components

Das Problem

Firebase SDK ist für den Client optimiert. Aber Server Components laufen auf dem Server - wie nutzt man Firebase dort?

Die Lösung: Firebase Admin SDK

// lib/firebase-admin.ts
import { getApps, initializeApp, cert, App } from 'firebase-admin/app';
import { getFirestore, Firestore } from 'firebase-admin/firestore';
import { getAuth, Auth } from 'firebase-admin/auth';

let app: App;
let db: Firestore;
let auth: Auth;

function initializeFirebaseAdmin() {
  if (getApps().length === 0) {
    app = initializeApp({
      credential: cert({
        projectId: process.env.FIREBASE_PROJECT_ID,
        clientEmail: process.env.FIREBASE_CLIENT_EMAIL,
        // Private Key mit Newlines
        privateKey: process.env.FIREBASE_PRIVATE_KEY?.replace(/\\n/g, '\n'),
      }),
    });
  }

  db = getFirestore();
  auth = getAuth();

  return { app, db, auth };
}

export const { db: adminDb, auth: adminAuth } = initializeFirebaseAdmin();

Server-Side Data Fetching

// lib/firebase/providers.ts
import { adminDb } from './firebase-admin';

export async function getProvidersByCategory(category: string) {
  const snapshot = await adminDb
    .collection('providers')
    .where('category', '==', category)
    .where('verified', '==', true)
    .where('active', '==', true)
    .orderBy('rating', 'desc')
    .limit(20)
    .get();

  return snapshot.docs.map(doc => ({
    id: doc.id,
    ...doc.data(),
  })) as Provider[];
}

export async function getProviderById(id: string) {
  const doc = await adminDb.collection('providers').doc(id).get();

  if (!doc.exists) return null;

  return { id: doc.id, ...doc.data() } as Provider;
}

Performance-Optimierung: Der Weg zu 90+ Lighthouse

Ausgangslage

Mein erster Production Build war... nicht gut:

LCP: 3.5 Sekunden 😱
TBT: 890ms
CLS: 0.25
Bundle Size: 450KB (gzipped)

Schritt 1: Bundle-Analyse

ANALYZE=true pnpm build

Die größten Übeltäter:

Google Maps SDK: 180KB
date-fns (komplett): 75KB
Firebase Client SDK: 120KB
Framer Motion: 65KB

Schritt 2: Dynamic Imports

Schwere Komponenten werden erst geladen, wenn sie gebraucht werden:

// components/maps/DynamicMap.tsx
import dynamic from 'next/dynamic';
import { MapSkeleton } from './MapSkeleton';

export const DynamicMap = dynamic(
  () => import('./GoogleMap').then(mod => mod.GoogleMap),
  {
    loading: () => <MapSkeleton />,
    ssr: false, // Google Maps braucht window
  }
);

// Verwendung
function ProviderLocation({ coordinates }: Props) {
  const [showMap, setShowMap] = useState(false);

  return (
    <div>
      {showMap ? (
        <DynamicMap coordinates={coordinates} />
      ) : (
        <Button onClick={() => setShowMap(true)}>
          Karte anzeigen
        </Button>
      )}
    </div>
  );
}

Schritt 3: Tree Shaking für date-fns

Statt alles zu importieren:

// ❌ Schlecht - importiert alles
import { format, addDays, subDays } from 'date-fns';

// ✅ Gut - importiert nur was nötig
import format from 'date-fns/format';
import addDays from 'date-fns/addDays';

Schritt 4: Image Optimization

import Image from 'next/image';

export function ProviderCard({ provider }: { provider: Provider }) {
  return (
    <div className="relative">
      <Image
        src={provider.avatar}
        alt={provider.name}
        width={400}
        height={300}
        // Erste 6 Karten priorisieren (above the fold)
        priority={provider.index < 6}
        // Placeholder für bessere UX
        placeholder="blur"
        blurDataURL={provider.blurHash}
        // Responsive Sizes
        sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
        className="object-cover rounded-lg"
      />
    </div>
  );
}

Schritt 5: Route Prefetching

import Link from 'next/link';

// Next.js prefetcht Links automatisch wenn sie im Viewport sind
<Link 
  href={`/providers/${provider.id}`}
  prefetch={true} // Default bei production
>
  {provider.name}
</Link>

Ergebnis

Nach allen Optimierungen:

Metrik	Vorher	Nachher	Verbesserung
LCP	3.5s	1.2s	-66%
TBT	890ms	180ms	-80%
CLS	0.25	0.02	-92%
Bundle	450KB	165KB	-63%
Lighthouse	54	94	+40 Punkte

Auth-System: Firebase + Next.js Middleware

Die Challenge

Firebase Auth ist für SPAs konzipiert. Aber mit Server Components brauchte ich eine Lösung, die:

Tokens auf dem Server validiert
Geschützte Routen serverseitig absichert
User-Daten in Server Components verfügbar macht

Die Lösung: Cookie-basierte Sessions

1. Login-Flow:

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

import { cookies } from 'next/headers';
import { adminAuth } from '@/lib/firebase-admin';

export async function createSession(idToken: string) {
  // Token validieren
  const decodedToken = await adminAuth.verifyIdToken(idToken);

  // Session Cookie erstellen (5 Tage gültig)
  const sessionCookie = await adminAuth.createSessionCookie(idToken, {
    expiresIn: 60 * 60 * 24 * 5 * 1000, // 5 Tage
  });

  // Cookie setzen
  const cookieStore = await cookies();
  cookieStore.set('__session', sessionCookie, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 60 * 60 * 24 * 5, // 5 Tage
    path: '/',
  });

  return { success: true, userId: decodedToken.uid };
}

2. Middleware für Route Protection:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

const protectedRoutes = ['/dashboard', '/bookings', '/settings'];
const authRoutes = ['/login', '/register'];

export async function middleware(request: NextRequest) {
  const sessionCookie = request.cookies.get('__session')?.value;
  const { pathname } = request.nextUrl;

  // Geschützte Route ohne Session -> Login
  if (protectedRoutes.some(route => pathname.startsWith(route))) {
    if (!sessionCookie) {
      const loginUrl = new URL('/login', request.url);
      loginUrl.searchParams.set('redirect', pathname);
      return NextResponse.redirect(loginUrl);
    }
  }

  // Auth-Route mit Session -> Dashboard
  if (authRoutes.includes(pathname) && sessionCookie) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/bookings/:path*', '/login', '/register'],
};

3. User in Server Components:

// lib/auth.ts
import { cookies } from 'next/headers';
import { adminAuth } from '@/lib/firebase-admin';

export async function getCurrentUser() {
  const cookieStore = await cookies();
  const sessionCookie = cookieStore.get('__session')?.value;

  if (!sessionCookie) return null;

  try {
    const decodedClaims = await adminAuth.verifySessionCookie(sessionCookie, true);
    return decodedClaims;
  } catch (error) {
    return null;
  }
}

// Verwendung in Server Component
export default async function DashboardPage() {
  const user = await getCurrentUser();

  if (!user) {
    redirect('/login');
  }

  const userData = await getUserData(user.uid);

  return <Dashboard user={userData} />;
}

Kalender & Buchungssystem

FullCalendar Integration

'use client';

import FullCalendar from '@fullcalendar/react';
import dayGridPlugin from '@fullcalendar/daygrid';
import timeGridPlugin from '@fullcalendar/timegrid';
import interactionPlugin from '@fullcalendar/interaction';

export function BookingCalendar({ 
  providerId,
  initialEvents 
}: { 
  providerId: string;
  initialEvents: CalendarEvent[];
}) {
  const [events, setEvents] = useState(initialEvents);

  // Real-time Updates
  useEffect(() => {
    const unsubscribe = onSnapshot(
      query(
        collection(db, 'bookings'),
        where('providerId', '==', providerId),
        where('status', 'in', ['confirmed', 'pending'])
      ),
      (snapshot) => {
        const bookings = snapshot.docs.map(doc => ({
          id: doc.id,
          title: doc.data().serviceName,
          start: doc.data().startTime.toDate(),
          end: doc.data().endTime.toDate(),
          backgroundColor: doc.data().status === 'confirmed' ? '#22c55e' : '#eab308',
        }));
        setEvents(bookings);
      }
    );

    return () => unsubscribe();
  }, [providerId]);

  const handleDateSelect = async (selectInfo: DateSelectArg) => {
    // Neue Buchung öffnen
    openBookingModal({
      start: selectInfo.start,
      end: selectInfo.end,
      providerId,
    });
  };

  return (
    <FullCalendar
      plugins={[dayGridPlugin, timeGridPlugin, interactionPlugin]}
      initialView="timeGridWeek"
      events={events}
      selectable={true}
      select={handleDateSelect}
      headerToolbar={{
        left: 'prev,next today',
        center: 'title',
        right: 'dayGridMonth,timeGridWeek,timeGridDay',
      }}
      locale="de"
      firstDay={1} // Montag
      slotMinTime="08:00:00"
      slotMaxTime="20:00:00"
      allDaySlot={false}
    />
  );
}

Google Maps: Performance-Tipps

Lazy Loading der Maps API

// hooks/useGoogleMaps.ts
import { useJsApiLoader } from '@react-google-maps/api';

const libraries: Libraries = ['places', 'geometry'];

export function useGoogleMaps() {
  const { isLoaded, loadError } = useJsApiLoader({
    googleMapsApiKey: process.env.NEXT_PUBLIC_GOOGLE_MAPS_KEY!,
    libraries,
    // Vermeide Race Conditions
    id: 'google-map-script',
  });

  return { isLoaded, loadError };
}

Geocoding mit Caching

// lib/geocoding.ts
import { adminDb } from './firebase-admin';

export async function geocodeAddress(address: string) {
  // Check Cache first
  const cached = await adminDb
    .collection('geocode_cache')
    .where('address', '==', address.toLowerCase())
    .limit(1)
    .get();

  if (!cached.empty) {
    return cached.docs[0].data().coordinates;
  }

  // API Call
  const response = await fetch(
    `https://maps.googleapis.com/maps/api/geocode/json?address=${encodeURIComponent(address)}&key=${process.env.GOOGLE_MAPS_SERVER_KEY}`
  );

  const data = await response.json();

  if (data.results[0]) {
    const coordinates = data.results[0].geometry.location;

    // Cache speichern
    await adminDb.collection('geocode_cache').add({
      address: address.toLowerCase(),
      coordinates,
      createdAt: new Date(),
    });

    return coordinates;
  }

  return null;
}

Lessons Learned: Was ich anders machen würde

1. TypeScript Strict Mode von Anfang an

Ich habe mit strict: false angefangen und später umgestellt. Das war ein Fehler - hunderte Type-Fehler auf einmal zu fixen ist kein Spaß.

// tsconfig.json - von Anfang an!
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

2. Component Library früh aufbauen

Ich habe anfangs jeden Button individuell gestylt. Später auf shadcn/ui umzusteigen bedeutete viel Refactoring.

3. Error Boundaries überall

// components/ErrorBoundary.tsx
'use client';

export function ErrorBoundary({
  children,
  fallback = <DefaultErrorUI />,
}: {
  children: React.ReactNode;
  fallback?: React.ReactNode;
}) {
  return (
    <ReactErrorBoundary fallback={fallback}>
      {children}
    </ReactErrorBoundary>
  );
}

4. Monitoring von Tag 1

Ich habe Vercel Analytics und Sentry erst spät hinzugefügt. Hätte ich es früher gemacht, hätte ich Performance-Probleme früher erkannt.

5. Feature Flags

Hätte ich Feature Flags genutzt, wäre A/B-Testing und schrittweises Rollout einfacher gewesen.

Fazit: Lohnt sich der Stack?

Nach 6 Monaten intensiver Entwicklung:

✅ Was großartig funktioniert

Next.js 15 App Router - Server Components sind ein Game-Changer für Performance
Firebase + Vercel - Serverless-Architektur skaliert automatisch
TypeScript Strict - Fängt Bugs ab, bevor sie Production erreichen
Tailwind + shadcn/ui - Konsistente, schnelle UI-Entwicklung

⚠️ Worauf achten

Firebase Kosten - Bei Scale wird es teuer, Reads optimieren!
Caching - Next.js cacht aggressiv, verstehen wie es funktioniert
Hybrid Rendering - Planen welche Seiten SSR/SSG/ISR brauchen
Bundle Size - Regelmäßig analysieren, dynamic imports nutzen

📊 Die Zahlen

150+ React Komponenten
50+ Server Actions
20+ API Routes
94 Lighthouse Performance Score
1.2s LCP (von 3.5s)
165KB Bundle Size (von 450KB)

Resources & Links

Über mich

Ich bin Andy, Full-Stack Developer spezialisiert auf Next.js und Firebase. Ich helfe Unternehmen dabei, performante Web-Applikationen zu bauen.

Interesse an einem ähnlichen Projekt?

👉 the-freelancer.marketing

Fragen oder Feedback? Schreib mir auf Instagram