DEV Community: BB Dev Team

Bulletproof by Default: Security Architecture for Adult Platforms That Actually Get Attacked

BB Dev Team — Mon, 06 Apr 2026 22:42:38 +0000

_Why platforms in the adult industry face some of the most aggressive attack surfaces on the web — and how to build a system that holds up using NestJS, React Router, and a strict three-environment pipeline.
_
Running a platform in the adult industry means operating in one of the harshest security environments in commercial web development. That's not hyperbole — it's what we see in our logs every single day.

The attack vectors are wider than those of a typical SaaS product. Users store highly sensitive information: personal data, payment details, photos, and private communications. A breach isn't just a PR disaster — it can destroy lives. The market is competitive and not always above-board: competitors order targeted DDoS attacks or attempt to harvest user databases. Regulatory requirements (GDPR, and soon the EU Digital Services Act) demand verifiably documented security measures.

In our monitoring we see daily credential-stuffing waves, scraper botnets, SQL injection attempts, and targeted attacks on WebSocket endpoints. A "that won't happen to us" attitude is simply not an option.

Security can't be an afterthought. It has to be baked into the architecture — from the first line of code to the production deployment. This is what that looks like in practice.

1. Why Adult Platforms Need a Different Threat Model

Most web applications have to protect their users' data. Adult platforms have to protect their users' identities.

That's a fundamentally different bar. Consider the data that lives on a typical escort platform: real names, phone numbers, location history, banking details, profile photos that users explicitly don't want associated with their identity elsewhere, and private messages between users who trust the platform to keep those conversations confidential. A breach of this data doesn't just mean spam emails — it means real-world consequences: outing, blackmail, career damage, relationship breakdown.

This shapes every architectural decision we make. We don't ask "what is the minimum security we need to comply?" — we ask "what happens to our users if this particular piece of data leaks?" That question has a way of focusing the mind.

Practically speaking, the threat landscape looks like this:

Credential stuffing: Automated bots testing leaked username/password combinations from other breaches against our login endpoint. This is constant.
Scraping: Botnets systematically harvesting profile data to build competing datasets or blackmail users.
Targeted attacks: Competitors or bad actors directly targeting infrastructure — DDoS, attempted database exfiltration, social engineering of support staff.
WebSocket exploitation: Our real-time messaging system is a favourite target; attackers probe for replay vulnerabilities, missing authentication on upgrade, and insecure deserialization.
Regulatory probes: Authorities and NGOs scan platforms for CSAM, age verification bypasses, and GDPR non-compliance. These aren't malicious attacks, but they demand robust audit trails.

The threat model shapes the architecture. Let's get into it.

2. The Three-Environment Pipeline: Dev → Staging → Prod

The foundation of our security strategy is a strict three-environment separation. No feature, no hotfix, no configuration change ever lands directly in production.

Development

Local development uses mock services, a local Postgres instance, hot-reloading, full debug logging, and CORS open to localhost. The payment provider is faked. Secrets are fake. The goal is developer velocity — this environment is intentionally permissive because it is completely isolated from real user data.

Staging

Staging is where things get serious. It runs on production-equivalent infrastructure, with real TLS certificates, production-equivalent secrets (different values, same structure), and real data — anonymized and stripped of PII before being seeded. Every deployment to staging triggers the full security gate suite: SAST, dependency audits, container scanning, DAST. Load tests run here. Penetration tests target this environment.

The single most important rule: staging must be indistinguishable from production in terms of configuration. A security vulnerability that isn't visible in staging because the config differs will hit production without warning.

Production

Production deployments happen only after staging approval. Manual SSH access to production servers is impossible — there are no keys, no bastion hosts for developers. All deployments flow through the CI/CD pipeline. Debug output is completely disabled. The WAF is active. Rate limiting is strict. An audit log captures every meaningful action, immutably, in a separate append-only datastore.

We manage all three environments with Terraform, with strictly separated state files per environment. Environment-specific secrets live in HashiCorp Vault and are never shared across environments.

dev    ──────────────┐
                     ▼
staging  ──── [security gates] ──── approval ──── prod

3. Security Gates in CI/CD

Before any code reaches staging or production, it passes through a series of automated security checks. These aren't optional quality checks — a failed gate stops the deployment completely.

git push → lint/typecheck → unit tests → SAST → dep audit → container scan → staging deploy → DAST → prod deploy

Static Application Security Testing (SAST)

We use semgrep with our own ruleset alongside eslint-plugin-security to scan every commit for known vulnerability patterns: SQL injection risks, missing input validation, hardcoded secrets, unsafe regex patterns (ReDoS), and insecure deserialization. The scan runs in under 30 seconds and blocks on any findings.

# .github/workflows/security.yml (relevant excerpt)
- name: SAST - Semgrep
  uses: returntocorp/semgrep-action@v1
  with:
    config: >-
      p/nodejs
      p/secrets
      p/owasp-top-ten

Dependency Auditing

Every npm audit run with --audit-level=high is a pipeline blocker. On top of that, we use socket.dev — which doesn't just check known CVEs but also detects suspicious behavioral changes in npm packages. Supply chain attacks via malicious package updates are underestimated as an attack vector, and socket.dev catches them before they land in our dependency tree.

Container Image Scanning

Docker images are scanned with trivy before being pushed to the registry. Base images are restricted to minimal Alpine or Distroless variants. No root user in containers, ever. The CI step fails if any HIGH or CRITICAL CVE is found in the image.

trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

Dynamic Application Security Testing (DAST)

After every staging deployment, an OWASP ZAP baseline scan runs automatically against the staging environment. It tests for the OWASP Top 10: XSS, injection, security misconfiguration, broken access control, and more. Only when this scan returns clean does the production deployment gate open.

4. NestJS: Building the Backend as a Fortress

NestJS provides an excellent foundation — but a secure baseline doesn't emerge on its own. Here are the patterns we apply consistently.

Guards First: Locked by Default

Every route is locked by default. Authentication and authorization run through Guards, never through ad-hoc checks in controllers. The critical inversion: routes must explicitly opt into being public, not opt out of being protected.

// auth.guard.ts — global guard, no route is public by default
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
  canActivate(context: ExecutionContext) {
    const isPublic = this.reflector.get(IS_PUBLIC_KEY, context.getHandler());
    if (isPublic) return true;
    return super.canActivate(context);
  }
}

// main.ts — registered globally
app.useGlobalGuards(new JwtAuthGuard(reflector));

// Routes that should be public are explicitly decorated
@Public()
@Post('auth/login')
async login(@Body() dto: LoginDto) { ... }

Input Validation with class-validator

All incoming data is validated through DTOs with class-validator and class-transformer. Whitelist mode is active: properties not defined in the DTO are automatically stripped. forbidNonWhitelisted turns unknown properties into a 400 error, making it immediately obvious when a client is sending unexpected data.

// main.ts
app.useGlobalPipes(new ValidationPipe({
  whitelist: true,              // strip unknown props
  forbidNonWhitelisted: true,   // or throw exception
  transform: true,              // auto-cast types
  transformOptions: {
    enableImplicitConversion: false  // stay explicit
  }
}));

// dto/create-profile.dto.ts
export class CreateProfileDto {
  @IsString()
  @Length(2, 100)
  @Transform(({ value }) => sanitizeHtml(value))
  name: string;

  @IsEnum(ProfileCategory)
  category: ProfileCategory;

  @IsOptional()
  @IsString()
  @MaxLength(2000)
  description?: string;
}

Rate Limiting and Throttling

With @nestjs/throttler we limit requests per IP and per endpoint. Login endpoints have particularly aggressive limits. After five failed attempts, the IP is temporarily blocked with exponential backoff. Additionally, nginx sits in front of the application with limit_req_zone as a first line of defense — it blocks volumetric attacks before they ever reach NestJS.

// app.module.ts
ThrottlerModule.forRoot([
  {
    name: 'short',
    ttl: 1000,
    limit: 10,
  },
  {
    name: 'medium',
    ttl: 10000,
    limit: 50,
  },
]),

// auth.controller.ts — stricter limit on login
@Throttle({ short: { limit: 3, ttl: 60000 } })
@Post('login')
async login(@Body() dto: LoginDto) { ... }

Security Headers with Helmet

helmet is mandatory — but configured, not just switched on. Content Security Policy is locked down to our specific domains. HSTS is set with a long max-age. X-Frame-Options prevents clickjacking.

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      imgSrc: ["'self'", 'data:', 'https://cdn.our-domain.com'],
      scriptSrc: ["'self'"],
      styleSrc: ["'self'", "'unsafe-inline'"], // only where unavoidable
      connectSrc: ["'self'", 'wss://api.our-domain.com'],
      frameAncestors: ["'none'"],
    }
  },
  hsts: {
    maxAge: 31536000,
    includeSubDomains: true,
    preload: true,
  },
  referrerPolicy: { policy: 'strict-origin-when-cross-origin' },
}));

Audit Logging

Every sensitive action — login, logout, profile update, payment, admin action — is written to an append-only audit log with user ID, IP, timestamp, and action details. This log is stored separately from the application database and is write-only from the application's perspective. Even if the main database is compromised, the audit trail remains intact.

5. React Router: Security on the Frontend

Frontend security is routinely neglected. Yet the frontend is the first attack surface the user sees — and therefore the primary vector for social engineering, XSS, and token theft.

Route-Level Authorization

With React Router v7 we implement a ProtectedRoute wrapper that checks authentication and authorization state before any route renders. Token refresh happens automatically and transparently.

// components/ProtectedRoute.tsx
export function ProtectedRoute({ requiredRole }: { requiredRole?: Role }) {
  const { user, isLoading } = useAuth();

  if (isLoading) return <LoadingSpinner />;
  if (!user) return <Navigate to="/login" replace />;
  if (requiredRole && !user.roles.includes(requiredRole)) {
    return <Navigate to="/unauthorized" replace />;
  }

  return <Outlet />;
}

// routes.tsx
const router = createBrowserRouter([
  {
    element: <ProtectedRoute />,
    children: [
      { path: '/dashboard', element: <Dashboard /> },
      { path: '/messages', element: <Messages /> },
      {
        element: <ProtectedRoute requiredRole={Role.ADMIN} />,
        children: [
          { path: '/admin', element: <AdminPanel /> },
        ],
      },
    ],
  },
]);

Token Storage: Never localStorage

JWTs are never stored in localStorage. That's an open XSS entry point — any XSS on the page, including from a third-party script, can steal that token. Our approach:

Refresh tokens: stored as httpOnly, Secure, SameSite=Strict cookies. JavaScript cannot access them at all.
Access tokens: stored only in memory (React Context / Zustand store). Short lifetime of 15 minutes. Gone on page reload, automatically refreshed via the httpOnly cookie.

// auth.context.tsx
interface AuthState {
  accessToken: string | null;  // in-memory only
  user: User | null;
}

function useAuthStore() {
  const [state, setState] = useState<AuthState>({
    accessToken: null,
    user: null,
  });

  const refresh = useCallback(async () => {
    // Refresh token is sent automatically via httpOnly cookie
    const res = await fetch('/api/auth/refresh', { credentials: 'include' });
    if (!res.ok) return setState({ accessToken: null, user: null });
    const { accessToken, user } = await res.json();
    setState({ accessToken, user });
  }, []);

  return { ...state, refresh };
}

Common mistake: localStorage.setItem('token', jwt) is the most popular security error in frontend development. Any XSS anywhere on the page — including in an embedded third-party script — can exfiltrate that token.

CSP Enforced by the Backend

Content Security Policy is set as an HTTP header — never as a meta tag. Meta tags can be bypassed via DOM injection. Inline scripts are forbidden. External scripts may only load from explicitly allowed domains. This is set in the NestJS helmet configuration and applies to every response.

6. Live Messaging with End-to-End Encryption

The messaging system is the most security-critical feature of our platform. Users expect absolute confidentiality. We implement real end-to-end encryption — the server never sees the plaintext of any message.

How It Works

Every user generates an asymmetric key pair on their first login: X25519 for key exchange, AES-256-GCM for message encryption. The private key never leaves the user's device. Only the public key is stored on the server.

// crypto.service.ts (client-side, using WebCrypto API)

// Generate key pair on first login
async function generateUserKeyPair(): Promise<CryptoKeyPair> {
  return crypto.subtle.generateKey(
    { name: 'X25519' },
    true,
    ['deriveKey']
  );
}

// Export public key for server storage
async function exportPublicKey(publicKey: CryptoKey): Promise<string> {
  const raw = await crypto.subtle.exportKey('raw', publicKey);
  return btoa(String.fromCharCode(...new Uint8Array(raw)));
}

// Private key is encrypted with a user-derived key and stored in IndexedDB
// It never travels to the server
async function storePrivateKey(privateKey: CryptoKey, userDerivedKey: CryptoKey) {
  const exported = await crypto.subtle.exportKey('jwk', privateKey);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const encrypted = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    userDerivedKey,
    new TextEncoder().encode(JSON.stringify(exported))
  );
  await db.set('privateKey', { encrypted, iv });
}

Sending a Message: ECDH Key Exchange

When sending a message, the sender performs an ECDH key exchange with the recipient's public key, derives a shared session key, and encrypts the message with it. The result — ciphertext plus an ephemeral public key — is sent over WebSocket and stored on the server. The server is a pure transport and storage layer for encrypted blobs. It cannot read any message.

async function encryptMessage(
  plaintext: string,
  recipientPublicKey: CryptoKey,
  senderPrivateKey: CryptoKey
): Promise<EncryptedMessage> {
  // Derive shared secret via ECDH
  const sharedKey = await crypto.subtle.deriveKey(
    { name: 'X25519', public: recipientPublicKey },
    senderPrivateKey,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt']
  );

  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    sharedKey,
    new TextEncoder().encode(plaintext)
  );

  return {
    ciphertext: bufferToBase64(ciphertext),
    iv: bufferToBase64(iv),
    // Include ephemeral sender public key so recipient can derive the same shared secret
    senderEphemeralPublicKey: await exportPublicKey(recipientPublicKey),
  };
}

WebSocket Security

WebSocket connections are only accepted over WSS (TLS). A valid JWT is validated during the handshake, before the upgrade completes. Every message includes a timestamp and sequence number — replay attacks are detected and rejected. NestJS WebSocket Gateway handles this:

@WebSocketGateway({ cors: false, transports: ['websocket'] })
export class MessagingGateway implements OnGatewayConnection {
  async handleConnection(client: Socket) {
    const token = client.handshake.auth.token;
    const payload = await this.jwtService.verifyAsync(token).catch(() => null);
    if (!payload) {
      client.emit('error', { message: 'Unauthorized' });
      client.disconnect();
      return;
    }
    client.data.userId = payload.sub;
  }
}

Forward Secrecy matters: We use ephemeral keys per session. Even if a user's long-term private key is eventually compromised, past messages remain encrypted. This is a non-negotiable property for a platform handling sensitive communications.

7. Data Encryption at Rest and in Transit

In Transit: TLS 1.3 Only

All HTTP connections enforce TLS 1.3. TLS 1.0 and 1.1 are disabled. TLS 1.2 remains active as a fallback for older clients but is deprioritized in cipher negotiation. Certificates come from Let's Encrypt with automated renewal. Certificate Transparency is active — any unexpected certificate issuance for our domains triggers an alert.

Our nginx TLS configuration achieves an A+ on SSL Labs. The relevant settings:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:...';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

At Rest: Field-Level Encryption for Sensitive Data

Full disk encryption on the infrastructure level is a given, not a substitute for application-level encryption. Sensitive database fields — phone numbers, real names where stored, payment-related identifiers — are encrypted at the application level before being written to the database.

// encryption.service.ts
@Injectable()
export class EncryptionService {
  private readonly algorithm = 'aes-256-gcm';
  private readonly key: Buffer;

  constructor(private configService: ConfigService) {
    // Key loaded from Vault at startup, never from env vars
    this.key = Buffer.from(configService.get('ENCRYPTION_KEY'), 'hex');
  }

  encrypt(plaintext: string): EncryptedField {
    const iv = crypto.randomBytes(12);
    const cipher = crypto.createCipheriv(this.algorithm, this.key, iv);
    const encrypted = Buffer.concat([
      cipher.update(plaintext, 'utf8'),
      cipher.final()
    ]);
    return {
      data: encrypted.toString('base64'),
      iv: iv.toString('base64'),
      tag: cipher.getAuthTag().toString('base64'),
    };
  }

  decrypt(field: EncryptedField): string {
    const decipher = crypto.createDecipheriv(
      this.algorithm,
      this.key,
      Buffer.from(field.iv, 'base64')
    );
    decipher.setAuthTag(Buffer.from(field.tag, 'base64'));
    return decipher.update(Buffer.from(field.data, 'base64'), undefined, 'utf8')
      + decipher.final('utf8');
  }
}

Secret Management

No secrets in CI/CD logs. No secrets in code repositories. No secrets in environment variables that get passed around carelessly. We use HashiCorp Vault for all secret management with automatic rotation. Application secrets are loaded at startup and never logged. Database credentials rotate every 30 days automatically. If a credential leaks, the blast radius is bounded in time.

8. Incident Response and Monitoring

Security is not a set-and-forget problem. An attack will come. The question is how quickly you detect it and how coordinated your response is.

Alerting Stack

We run a layered monitoring stack: application logs go to Loki, metrics to Prometheus, dashboards in Grafana. Critical events — failed login attempts above threshold, unusual traffic spikes, 5xx rates above 0.1%, anomalous message volume — trigger immediate PagerDuty alerts with on-call escalation.

Specifically, we alert on:

More than 10 failed logins from a single IP in 5 minutes
Any admin action outside business hours
Database query time spiking above p99 baseline (potential injection causing table scans)
A new IP accessing more than 100 profiles in 10 minutes (scraper pattern)
Any 5xx response from the payments service

Anomaly Detection

ML-based anomaly detection sounds sophisticated but in practice often starts as simple pattern matching: a user generating 500 profile views in 5 minutes is not a human. An IP systematically iterating sequential numeric user IDs is a scanner. These patterns are detected and lead to automatic temporary blocks. More sophisticated behavioral analytics (session velocity, geographic impossibility) layer on top as the platform scales.

Incident Response Playbook

Every team needs a written playbook — even if you hope never to use it. Our playbook defines: first response within 15 minutes of a P1 alert, isolation of the affected system, internal communication chain, external communication obligations (GDPR: 72-hour reporting deadline to the supervisory authority in the event of a data breach), and a mandatory post-mortem process.

Run tabletop exercises: "What do we do if the database is compromised tomorrow morning?" A playbook that only exists on paper is worth little in a real incident. We run a 90-minute tabletop exercise every quarter.

9. Security Checklist to Take Home

A summary of every control described in this article, usable as a review checklist for your own platform:

Infrastructure & Pipeline

[ ] Three strictly separated environments (Dev / Staging / Prod) with independent secrets
[ ] No manual deployment to production — CI/CD pipeline only
[ ] SAST, dependency audit, and container scan as pipeline gates that block on failure
[ ] DAST against staging after every deployment
[ ] Infrastructure-as-Code with per-environment state files
[ ] Secret rotation via Vault — no static, long-lived credentials

Backend (NestJS)

[ ] Global auth guard: routes opt-in to being public, not opt-out of being protected
[ ] ValidationPipe with whitelist: true on all endpoints
[ ] Rate limiting on both application and nginx level
[ ] Helmet with restrictive CSP — no wildcard inline scripts
[ ] Field-level encryption for sensitive database columns (AES-256-GCM)
[ ] Append-only audit log stored separately from the main database

Frontend (React Router)

[ ] Route-level authorization via ProtectedRoute wrappers
[ ] JWT: refresh token as httpOnly cookie, access token in-memory only — never localStorage
[ ] CSP enforced as HTTP header from the backend, not as meta tag

Messaging

[ ] End-to-end encryption: server never sees message plaintext
[ ] Ephemeral keys per session for forward secrecy
[ ] WebSocket auth validated on handshake before upgrade completes
[ ] Replay attack protection via timestamp + sequence number

Network

[ ] TLS 1.3, HSTS with preload, Certificate Transparency monitoring
[ ] WAF active in production with tuned ruleset

Operations

[ ] Real-time monitoring with defined alert thresholds
[ ] Written incident response playbook
[ ] GDPR breach notification process documented and tested
[ ] Quarterly tabletop exercises

Closing: Security as Culture, Not as Feature

Technical measures alone aren't enough. What truly protects is a culture where security is understood as a quality trait, not a brake on velocity. No developer on the team should find the question "is this secure?" annoying — it's part of the definition of done.

For platforms in the adult industry, this holds with particular force. Users entrust us with data that directly affects their lives. That trust is non-negotiable. And neither is the technical foundation that supports it.

We are the engineering team behind one bb-escort.de. On dev.to we share what we've learned scaling, securing, and building our platform — unvarnished and practical.

Have a question about any of the patterns described here? Drop it in the comments — we read everything.

Why We Switched from Next.js to React Router 7 (And Don’t Regret It)

BB Dev Team — Sun, 01 Mar 2026 16:31:12 +0000

Over the past few years, our platform evolved from a fast-moving startup stack into a performance- and infrastructure-sensitive system.

We started with Next.js — like many teams do. It’s powerful, mature, and incredibly productive.

But as our requirements grew more specific, we increasingly felt constrained by framework assumptions around rendering, deployment, and infrastructure.

Eventually, we made the switch to React Router 7.

Here’s why — and what changed for us.

1. We Use React Server Components — Without Traditional Page SSR

Leaving Next.js doesn’t mean abandoning advanced rendering.

With React Router 7, we use React Server Components (RSC) — but without being tied to a page-based SSR architecture.

What this gives us:

Server-rendered components where it makes sense
Streaming support
Reduced client hydration overhead
More granular server/client boundaries

Traditional SSR often means rendering entire pages on the server and hydrating everything on the client.

With RSC and React Router’s data APIs, we can be more surgical.

In practice, this improved client performance because we reduced unnecessary hydration and shipped less JavaScript to the browser.

Next.js gives you powerful defaults.

React Router gives you explicit control.

At our scale, explicit control wins.

2. True Middleware Patterns — Fully Integrated

A common assumption is that Next.js has “real” middleware while React Router does not.

That’s outdated.

React Router 7 provides fully integrated request handling via:

loaders
actions
standard Request / Response objects
nested route data APIs

These patterns allow:

Authentication guards
Geo-based logic
Logging and observability
Access control
Request transformations

Because everything is route-scoped and explicit, it’s easier to reason about.

We don’t rely on edge-only middleware or special folder conventions. We write standard request logic in predictable places.

In practice, this feels cleaner and more composable.

3. SPA Mode — When We Need It

Another major advantage: React Router 7 allows us to run certain parts of our system in pure SPA mode.

This is extremely useful for:

Internal dashboards
Admin tools
Authenticated application areas
Feature-heavy UI sections

We can:

Disable server rendering where it’s not needed
Ship static assets
Optimize purely for client interactivity

With Next.js, the architecture is always SSR-first (even when using client components heavily).

React Router gives us freedom:

We can choose SSR, RSC, streaming, or pure SPA — per application or even per route.

That flexibility matters.

4. We Recommend Using Framework Mode

One important note: we strongly recommend using React Router 7 in Framework Mode.

While React Router can be used as a minimal routing library, Framework Mode unlocks its full potential:

Built-in data loading patterns
Integrated server handling
Structured routing conventions
Production-ready architecture out of the box

It removes a lot of boilerplate and architectural decisions you would otherwise have to reinvent.

At the same time, it doesn’t lock you into rigid conventions. The system remains highly adjustable:

You control hosting
You control rendering strategy
You control deployment targets
You control infrastructure

For us, Framework Mode hits the perfect balance:

Less repetitive setup work —

but still full architectural sovereignty.

5. It’s Lightweight — In Dev and Production

Next.js is a full-stack meta-framework.

React Router is a routing and data orchestration layer.

That difference shows in bundle size and runtime complexity.

What we observed after migrating:

Smaller production bundles
Less framework runtime logic
Cleaner dependency graph
Faster CI builds

There’s simply less abstraction between us and React.

6. Faster Dev Environment

We use Vite for development, which significantly improved:

Cold start times
HMR speed
Debug clarity

One honest note:

Vite does not fully tree-shake in development mode.

Some of our dev pages can grow large (we’ve seen ~15MB), especially when using icon libraries.

However:

This only affects development
Production builds are optimized correctly

Overall, the dev feedback loop is still faster and more transparent than before.

7. Faster Bugfix Turnaround

From our experience:

React Router maintainers respond quickly — often within days from issue report to fix.

With larger frameworks like Next.js, turnaround can take weeks or longer. This is understandable given project size and ecosystem scope.

But when your business depends on framework stability, responsiveness matters.

Smaller, focused projects often move faster.

8. Self-Hosting & Geo Clustering

We host and geo-cluster our infrastructure ourselves.

We require:

Custom regional routing
Infrastructure-level SEO optimization
Strict data control
Full observability
Predictable scaling costs

Next.js increasingly assumes Vercel as the optimal deployment target.

React Router makes zero assumptions about hosting.

We can:

Run on Node
Deploy to edge runtimes
Use containers
Geo-cluster however we want

No vendor lock-in.

No deployment pressure.

No hidden coupling.

That independence is extremely valuable.

9. Clearer Mental Model

This might be subjective — but important.

With React Router:

What we write is what runs.
There’s less invisible framework behavior.
Routing and data are explicit.

In large systems, clarity beats convenience.

10. What Next.js Still Does Well

To be fair, Next.js is excellent at:

Quick startup productivity
Batteries-included defaults
Strong ecosystem adoption
Opinionated structure for smaller teams

For many projects, it’s absolutely the right choice.

But once you need architectural sovereignty, the trade-offs become more noticeable.

Why We Switched

Our platform operates in:

SEO-sensitive environments
Performance-critical markets
Privacy-sensitive domains
Regionally distributed infrastructure

We needed:

Rendering flexibility (RSC + SPA)
Integrated middleware control
Hosting independence
Lightweight runtime
Faster iteration cycles

React Router 7 gave us exactly that.

Final Thoughts

Switching frameworks is never trivial.

But sometimes growth forces you to reconsider architectural constraints.

For us, moving from Next.js to React Router 7 wasn’t about hype.

It was about:

Control.

Clarity.

Independence.

And so far, we’re very happy with the decision.

Building a Payment Provider: The Hidden Technical Complexity

BB Dev Team — Wed, 03 Sep 2025 18:18:28 +0000

Most companies integrate with existing payment providers (Stripe, Adyen, PayPal).

But what if you need to build your own payment provider?

We went down this path, and it turned out to be one of the hardest technical challenges we’ve faced.

Here’s a breakdown of the complexity that comes with building a system that moves money reliably and securely at scale.

What you can expect: no standardized, old interface, many special regulations and lots and lots of testing ;)

1. Multi-Layered Interfaces

A payment provider isn’t one API – it’s many:

Card Networks (Visa, Mastercard, Amex): Integration with different protocols, settlement, and reconciliation.
Alternative Payments: Bank transfers, wallets, crypto, vouchers.
Merchant Interfaces: APIs and dashboards for external clients.
Regulatory APIs: KYC, AML, fraud monitoring.

Every integration has different standards, formats, and SLAs.

Your system becomes the glue between dozens of protocols.

2. Subscription & Billing Management

Recurring payments are much harder than one-time transactions.

Subscriptions: Track cycles, retries, upgrades, downgrades, cancellations.
Invoices: Generate legal documents in multiple jurisdictions.
Prorations: Handle when a user changes a plan mid-cycle.
Dunning Logic: Retry failed payments intelligently without spamming banks.
Multiple Currencies: Exchange rates, rounding rules, settlement differences.

We ended up building a dedicated billing microservice to handle this logic.

3. Data Storage & Security

Payment data is the most sensitive data you can hold.

PCI DSS Compliance: Storage of cardholder data requires tokenization and encryption.
Vaults: Sensitive card data must never touch the core DB – it’s stored in isolated vault services.
Encryption-at-Rest + In-Transit: All data is encrypted multiple times.
Minimal Retention: Store as little as legally possible.
Audit Trails: Every read/write must be logged and immutable.

We designed a segmented database architecture:

Encrypted vault DB for card data.
Transaction DB for operational data.
Analytics DB for reporting.

4. Fraud Detection & Risk Management

A payment provider must detect and prevent fraud in real time.

Velocity Checks: Too many transactions in short time.
Behavioral Analysis: Unusual patterns compared to history.
Device Fingerprinting: Identify suspicious devices.
Machine Learning Models: Risk scoring on each transaction.

Every millisecond counts – fraud detection must run inline with transactions.

5. Reliability & Idempotency

Payments are state machines – and distributed systems love to break.

Idempotency Keys: Critical to prevent duplicate charges when retries happen.
Ledger System: Every transaction must be immutable, reversible only with compensating entries.
Consistency: Even under failure, your books must reconcile to the cent.
Partial Failures: One bank might succeed, another fails – the system must handle rollback scenarios gracefully.

We implemented a double-entry ledger with immutable transaction logs to guarantee reconciliation.

6. Developer Experience

Your clients (merchants) expect:

Clean REST + Webhook APIs.
SDKs in multiple languages.
Sandbox Mode for testing.
Real-Time Dashboard for transactions and disputes.

Building a developer-friendly product requires as much effort as the core payment logic itself.

7. Scaling & Compliance

High Throughput: Payments must clear in milliseconds, even under peak load.
Global Scale: Data residency laws → different storage per region.
Compliance: PSD2, PCI DSS, GDPR – each with strict requirements.
Disaster Recovery: Active-active datacenters, multi-region replication.

The system must be designed for 99.999% availability, because downtime means lost money.

Conclusion

Building a payment provider is not “just another API.”

It’s a network of integrations, a secure vault, a billing engine, a fraud system, and a financial ledger – all in one.

While integrating Stripe takes a few hours, building Stripe takes years.

For us, this has been one of the most demanding engineering challenges – but also one of the most rewarding.

It forces you to think about:

Security by design.
Reliability in distributed systems.
Performance at financial scale.

And in the end, you realize: Money never sleeps – and neither can your payment system.

Next.js and the Evil Web Vitals - a ranking killer?

BB Dev Team — Wed, 03 Sep 2025 18:13:05 +0000

Building a large-scale platform in a highly competitive industry means two things:

Visibility is survival (SEO, SSR, structured data).
Performance is ranking (Core Web Vitals decide who’s on top).

In this article, we’ll share why we chose Next.js 15 (with Turbo & App Router) as the foundation of our frontend, how we leverage it for SEO, SSR, and PWA, and how we overcame performance challenges like INP (Interaction to Next Paint) and FCP (First Contentful Paint).

Why Next.js for Our Platform?

Our requirements are very specific:

Server-Side Rendering (SSR): Critical for SEO-heavy pages that need to be indexed fast.
Static Generation + Revalidation: Balance between speed and freshness of content.
Progressive Web App (PWA): We use Serwist to add offline caching, push notifications, and app-like behavior.
Internationalization (i18n): Our audience is global – Next.js handles routing and language detection elegantly.
API Routes: Simplify integration with backend services.
App Router + Turbo: Cleaner routing, faster builds, and improved scalability.

Next.js gives us the best of both worlds: SSR for crawlers and static caching for humans.

The Challenges in Our Industry

We operate in a very competitive market where SEO is extremely hard-fought. Every millisecond and every snippet of metadata counts.

Load Times: Bounce rates skyrocket if users wait.
Crawling Efficiency: Google punishes slow sites with poor Web Vitals.
Meta Data Wars: Correct OpenGraph tags decide whether a page gets shared.
Structured Data: JSON-LD is essential for rich snippets in search results.

That’s why we implemented a full SEO toolkit in our platform:

Dynamic meta tags and OpenGraph tags.
Structured data with JSON-LD (Article, BreadcrumbList, VideoObject, etc.).
Automated sitemap.xml and RSS feeds.
Canonical tags to avoid duplicate indexing.

Performance Problems with Next.js

Next.js is powerful, but it comes with challenges:

INP (Interaction to Next Paint): Hydration can delay interaction readiness.
FCP (First Contentful Paint): JavaScript-heavy pages delay first paint.
Bundle Size: Next.js includes a lot of code by default. If you don’t monitor carefully, it explodes.
next/image Issues: While useful, it’s often too slow for our needs and adds extra runtime overhead.

At scale, these issues directly impact rankings and conversions.

How We Tamed the Web Vitals

We approached performance systematically:

1. Aggressive Caching

CDN Caching for static assets.
Incremental Static Regeneration (ISR): Pages revalidate every X seconds → always fresh, never slow.

export async function getStaticProps() {
  return {
    props: {}, 
    revalidate: 60, // page is regenerated every 60 seconds
  };
}

2. Partial Caching with Revalidate Keys

Since we are a platform with highly dynamic content, full caching is not possible.

Our solution: partial caching.

Static sections of a page (layout, headers, footers, metadata) are cached aggressively.
Dynamic sections (recommendations, user feeds, trending data) are updated frequently.
We rely heavily on revalidate keys to refresh only the parts that change.

// Example with revalidateTag in Next.js 15
import { revalidateTag } from "next/cache";

export async function POST(req: Request) {
  const body = await req.json();
  revalidateTag(`user-${body.userId}`); // revalidate only specific user cache
  return Response.json({ revalidated: true });
}

This approach allows us to serve fast cached pages while keeping dynamic data fresh.

3. The Golden Strategy: Async Loading

Our principle is simple: load everything asynchronously except what’s visible above-the-fold on first render.

Critical UI (headers, navigation, hero content) loads instantly.
Everything else (widgets, tracking, secondary UI) is loaded asynchronously.
This ensures fast FCP/LCP while still reducing bundle size and execution time.

4. Image Optimization in the Backend

Instead of relying only on next/image, our backend pre-generates images in multiple formats (WebP, AVIF, JPEG).

This reduces runtime overhead and ensures the best format is delivered instantly via CDN.

5. Library & UI Optimization

We spend many hours profiling and optimizing third-party libraries, especially UI components.

Unnecessary dependencies are removed, and only the minimal code required is bundled.

6. Bundle Size Control

We use next-bundle-analyzer to keep bundle size under control.
Strict commit guidelines ensure no debug or unused code slips in.
Every KB matters, especially since Next.js ships with a heavy base.

7. Fonts: Loaded Correctly via NestJS + Next.js

Fonts can drastically impact FCP. Our strategy combines NestJS static serving with Next.js optimization:

Fonts are self-hosted and served via NestJS static middleware.
Correct Cache-Control headers ensure long-term caching.
Next.js 15’s @next/font is used for automatic font-subsetting and preload links.
Above-the-fold text fonts are preloaded, while secondary fonts are loaded async.

Results: Best Possible Web Vitals

After multiple iterations we reached:

INP: consistently under Google’s “good” threshold.
FCP: improved by caching, async loading, and font optimization.
LCP (Largest Contentful Paint): optimized via backend image pre-generation, partial caching, and CDN.

Our Web Vitals are now among the best in our industry, directly improving SEO and user retention.

Conclusion

In a competitive industry, SEO + Performance = Survival.

Next.js 15 (with Turbo and App Router) gives us SSR, SEO tools, PWA support (via Serwist), and scalability.
The ecosystem around metadata (meta tags, OpenGraph, JSON-LD, sitemaps, RSS) makes it the best choice for visibility.
Performance challenges (INP, FCP, hydration, bundle size, next/image) are real, but solvable with caching, async loading, backend image optimization, and careful bundle management.
Partial caching with revalidate keys is the secret weapon for dynamic platforms like ours.
Fonts must be handled carefully – preloaded for above-the-fold, async for the rest.

Next.js may bring “evil” Web Vitals problems out of the box, but with the right strategy, you can tame them and even turn them into a competitive advantage.

Security by Design with NestJS, zod, ts-rest, and Custom In-House Frameworks

BB Dev Team — Wed, 03 Sep 2025 18:01:11 +0000

When you build a platform that handles millions of users and sensitive data, security and reliability are not just features – they’re survival requirements.

In our engineering team, we rely on NestJS (backend) and Next.js (frontend), but we don’t stop there. To ensure maximum security and resilience, we combine battle-tested open-source tools with custom in-house frameworks designed specifically for our threat model and performance needs.

This post gives an overview of how we approach data protection, authentication, validation, system reliability, secure real-time communication, and code security at scale.

Core Security Principles

1) Minimal Data Collection

Every extra field increases risk.
For KYC, we persist only the legally required attributes and discard everything else.

2) Encryption Everywhere

At Rest: All DB fields with sensitive data are encrypted.
In Transit: TLS 1.3 + HSTS with automatic certificate rotation.
On Application Layer: Some values (like ID scans) are encrypted before they ever reach the database.

import * as crypto from "crypto";

function encrypt(value: string, key: string) {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv("aes-256-gcm", Buffer.from(key, "hex"), iv);
  let encrypted = cipher.update(value, "utf8", "hex");
  encrypted += cipher.final("hex");
  const authTag = cipher.getAuthTag().toString("hex");
  return { iv: iv.toString("hex"), data: encrypted, tag: authTag };
}

3) Strong Authentication (2FA)

Mandatory 2FA for users and admins.
NestJS Guards make it straightforward to enforce OTP/WebAuthn or second-factor checks on sensitive routes.

import { CanActivate, ExecutionContext, Injectable } from "@nestjs/common";

@Injectable()
export class TwoFactorGuard implements CanActivate {
  canActivate(ctx: ExecutionContext): boolean {
    const req = ctx.switchToHttp().getRequest();
    return req.user?.is2FAAuthenticated === true;
  }
}

4) Role-Based Access Control

Implemented via NestJS Guards and decorators.
Principle: Least Privilege – narrow, task-focused scopes.

5) Auditing & Monitoring

Centralized logging (e.g., ELK / Datadog) with anomaly detection.
Alerts on suspicious patterns (login abuse, unusual data exports).

Request & Response Validation with ts-rest + Zod

We use ts-rest combined with Zod to strictly validate both requests and responses. This enforces contracts between backend and frontend and prevents accidental leaks or schema mismatches.

import { initContract } from "@ts-rest/core";
import { z } from "zod";

const c = initContract();

export const authContract = c.router({
  login: {
    method: "POST",
    path: "/auth/login",
    responses: {
      200: z.object({
        accessToken: z.string(),
        refreshToken: z.string(),
      }),
    },
    body: z.object({
      email: z.string().email(),
      password: z.string().min(8),
    }),
  },
});

Reliability: Microservices & Proxies (API Path)

Security without availability is meaningless. Our API services are designed for fault tolerance:

Microservices: Isolated domain services reduce blast radius and allow independent scaling.
Proxies & API Gateway: Centralized entry for routing, rate limiting, schema validation, and WAF.
Graceful Degradation: If one service fails, proxies reroute/fallback without exposing raw errors.
Zero-Downtime Deployments with blue-green strategies and rolling updates.
Circuit Breakers & Retries with idempotency keys to avoid duplicate side effects.

Note: The real-time stack (Socket.IO) is separate from the microservices runtime. See the next section.

Secure Real-Time Communication (Socket.IO Path)

We use a heavily adapted version of Socket.IO for customer chat and live website updates. This channel is independent from the microservices and optimized for reliability and security:

All socket connections are encrypted end-to-end.
Custom handshake validation prevents session hijacking.
Events are schema-validated before leaving or entering the server.
Proxies apply throttling and IP-based abuse detection.

Why We Use In-House Frameworks

While we like NestJS and Next.js, we intentionally reduce reliance on third-party open-source libraries.

Many open-source packages are under-maintained and accumulate vulnerabilities.
In-house frameworks allow us to:
- Control the attack surface.
- Patch vulnerabilities instantly.
- Simplify dependency management.

We selectively integrate OSS only when the maintenance and security posture is strong – and even then, often behind our own abstraction layers.

UI: A Hardened Version of shadcn

For the frontend UI, we rely on a heavily customized version of shadcn/ui.

It gives us a consistent, accessible component system.
We stripped unnecessary dependencies and hardened components against XSS and injection risks.
Our version is tightly integrated with our own design system and security checks (e.g., CSP compliance).

Code Security: Obfuscation, Commit Rules & Tooling

We treat code as a security boundary itself:

Obfuscators: We run multiple stages of JS/TS obfuscation on build artifacts to hinder reverse engineering.
Commit Guidelines: Hard rules enforced via Git hooks – no secrets, no TODOs, no debug code in commits.
Automated Toolchain: Before deployment, every commit passes through a suite of security tools:
- eslint with strict security configs
- ts-prune to detect unused/forgotten code
- depcheck and npm audit for dependency issues
- semgrep for static code vulnerability scanning
- zap-cli (OWASP ZAP) for lightweight API security scans in CI/CD
- docker-bench-security for container hardening checks
- Custom secret scanners to detect keys, tokens, or credentials in code

This ensures that only secure, hardened, and obfuscated code ever reaches production.

Architecture Overview

   [ User ] 
      │
      ▼
 [ Proxy / WAF ]
      │
 ┌────┴─────────┐
 ▼              ▼
[ Auth ]     [ API Gateway ]
   │              │
   ▼              ▼
[ Microservices ]       <-- encrypted APIs
   │
   ▼
[ Encrypted Database ]

   (Parallel Stack)
   [ User ]
      │
      ▼
 [ Secure Socket.IO ]  <-- chats & live updates

Key Takeaways

Collect less, protect more – store the minimum data possible.
Encrypt at every layer – DB, transit, application.
2FA everywhere – users and admins alike.
Validate requests & responses with ts-rest + Zod.
Design for failure – microservices + proxies keep the system resilient.
Harden real-time communication – encrypted and validated Socket.IO.
Limit external dependencies – in-house frameworks reduce attack surface.
UI is also security – a hardened design system prevents front-end exploits.
Secure the code itself – obfuscation, commit rules, and automated security tooling.

Security is never “done.” But by combining strong principles, carefully chosen tools, and a defense-in-depth strategy, you can significantly increase both trust and resilience.

We are the engineering team behind bb-escort.de. On dev.to we share lessons learned about scaling, security, and developer experience.