Back to blog
July 9, 2026

Hybrid Edge Architecture: Redesigning the DP-FIRE Intranet

ReactCloudflare WorkersExpressTursoClean ArchitectureDrizzle

1. The Operational and Infrastructure Challenge

The intranet and management system of DP-FIRE Chile SpA centralizes critical operations including logistics, corporate inventory control, and multi-company vehicle inspections. Previously, the backend consisted of a monolithic Express API running on Render (with a fixed monthly cost of $7.00 USD).

The primary operational bottleneck was the manual management of logistics sheets and Excel reports. In automating these processes, we faced two critical challenges:

  1. Reduce fixed monthly infrastructure costs to zero ($0.00 USD) for intranet hosting and database services.
  2. Bypass the physical limits of Edge computing. Although we wanted to migrate the entire system to Serverless on Cloudflare Workers, generating PDFs and Excel spreadsheets is CPU-intensive and exceeds free-tier limits.

2. The Solution: Hybrid Edge Architecture

To solve this, we designed a hybrid microservices architecture housed in a monorepo managed with pnpm workspaces.

graph TD
    Client[Client: React SPA] -->|Requests| Gateway[Gateway: Cloudflare Worker Hono]
    
    Gateway -->|/auth & /virtual-library| EdgeRoutes[Edge Native: Web Crypto & R2]
    Gateway -->|Other Routes: /users, /rems, /products| Express[Express Backend: api-reports]
    
    EdgeRoutes -->|Drizzle ORM| Turso[Turso DB: SQLite Edge]
    Express -->|Drizzle ORM| Turso

2.1. Separation of Concerns at the Edge (Cloudflare Workers vs. Node/Express)

Cloudflare Workers provides a generous free tier but imposes a strict 10ms CPU execution time limit per request.

  • Common tasks like lightweight cryptographic workflows (signing or verifying security tokens) and image redirection to R2 take microseconds and are perfect for Workers.
  • Heavy tasks like generating PDF certificates (pdfkit) and exporting Excel report spreadsheets (exceljs) consume CPU intensively, taking between 100ms and 1.5s.

The Solution: We split the backend into two functional blocks:

  1. api-core (Cloudflare Workers + Hono): Resolves authentication, native Edge routes, and access control in microseconds, hosted for free ($0 USD).
  2. api-reports (Node.js + Express on Railway): Handles heavy document generation. Railway operates on an active-usage billing model (only charging during request execution), reducing costs to practically zero during the company’s inactive hours.

Both services connect to Turso (libSQL) using Drizzle ORM, a distributed database at the Edge with low-latency replicas and a monthly cost of $0 USD in its free tier.

2.2. Clean Architecture (Ports and Adapters)

To decouple business rules from external infrastructure providers (such as R2, AWS S3, or local disks), we implemented the Ports and Adapters pattern:

  • The Port (Interface): An abstract interface StorageService that exposes functions like uploadFile() and deleteFile().
  • The Adapter (Implementation): We implemented a concrete adapter S3StorageService that uses the official SDK to interact with Cloudflare R2 or AWS S3.
  • Benefit: If we decide to change from Cloudflare R2 to Google Cloud Storage or a local disk in the future, we won’t touch a single line of business logic code; we will only change the adapter.

2.3. Applied Engineering Principles

  • Domain-Driven Design (DDD): The backend monorepo is structured around Bounded Contexts such as /auth, /users, /companies, /rems, and /certificates. Each context isolates its Drizzle ORM schemas, DTOs, and domain services.
  • Test-Driven Development (TDD): We used Vitest Projects to set up an automated testing harness. We validate token cryptographic compatibility and database consistency before deployment.
  • Automated CI/CD: A continuous integration pipeline in GitHub Actions runs formatting, linting, dead code analysis (knip), and rigorous TypeScript compilation on every push/pull-request.

3. Impact of the Redesign

  • Financial Optimization: We went from a fixed monthly cost of $7.00 USD (Render) to a fixed base operating cost of $0.00 USD for hosting the API and database (with Railway charging only fractions of cents based on active usage).
  • Performance: Daily intranet operations resolve queries in milliseconds thanks to the Turso Edge database.
  • Maintainability: Decoupling and Clean Code principles ensure that adding new features to the monorepo is fast and regression-free.