Common Base Project

    17. Full opening of CloudFlare’s ecosystem

    Members only · Non-members can read 30% of the article.

    Published
    November 17, 2025
    Reading Time
    4 min read
    Author
    Felix
    Access
    Members only
    Preview only

    Non-members can read 30% of the article.

    So far, the back-end infrastructure involved in the entire project is lacking, such as queues, timers, memory KV, Websocket, etc. These capabilities are not necessary to implement a minimalist project, but they can help everyone better understand the back-end ecology and architecture, and recall these infrastructures from dusty memories when needed one day in the future.

    These parts can be fully realized through the Cloudflare ecosystem. I am very grateful to xxgw for bringing the video link to Bilibili. It is because of the video that this chapter is supplemented.

    Change the entrance of Worker

    First, in order to customize the behavior of Cloudflare Worker, we need to modify the project's wrangler.jsonc configuration file. Point the main attribute to a new entry file worker.ts. This file will serve as a unified entry point for all of our Cloudflare backend services, not just running Next.js applications.

    // wrangler.jsonc
    {
      // ...
      "main": "worker.ts"
      // ...
    }
    ```
    
    Next, we create the `worker.ts` file. The core idea of ​​this file is: while processing the requests of the Next.js application itself, it also extends support for other native functions of Cloudflare, such as scheduled tasks (Cron Triggers), Durable, etc.
    
    ```typescript
    // 1. Import the Next.js application processor generated by open-next
    // @ts-ignore `.open-next/worker.ts` is generated at build time
    import { default as handler } from './.open-next/worker.js'
    
    // 2. Export an object containing fetch and scheduled processors
    export default {
      /**
       * Handle all incoming HTTP requests.
       * We delegate requests directly to open-next's handler to ensure that Next.js applications run properly.
       */
      fetch: handler.fetch,
    
      /**
       * Process scheduled tasks triggered by Cron Triggers.
       * Cloudflare calls this function at a scheduled time.
       */
      async scheduled(controller: ScheduledController, env: CloudflareEnv, ctx: ExecutionContext) {
        // You can perform different tasks based on cron expressions defined in wrangler.jsonc
        switch (controller.cron) {
          case '*/3 * * * *':
            //Execute every three minutes
            console.log('Cron job (every 3 mins) processed at:', new Date(controller.scheduledTime))
            break
          case '*/10 * * * *':
            //Execute every ten minutes
            console.log('Cron job (every 10 mins) processed at:', new Date(controller.scheduledTime))
            break
          case '*/45 * * * *':
            //Execute every forty-five minutes
            console.log('Cron job (every 45 mins) processed at:', new Date(controller.scheduledTime))
            break
        }
      }
    } satisfies ExportedHandler<CloudflareEnv>
    
    // 3. Re-export open-next and custom Durable Objects processors
    // This ensures that the Cloudflare platform recognizes and uses them correctly.
    // @ts-ignore
    export { DOQueueHandler, DOShardedTagCache, BucketCachePurge } from './.open-next/worker.js'
    export { Counter } from './durable/counter.js'
    ```
    
    At this point, we have completed the critical step of integrating the Next.js application with custom Worker logic (such as scheduled tasks). All Cloudflare ecosystem extensions can be configured and exported in worker.ts.
    
    Next, we can roughly classify Cloudflare's ecological functions into two categories: configuration-driven functions and extension-like functions. Understanding the difference between the two helps us organize our code and configuration more clearly.
    
    1. Configuration-Driven
        The core working mode of such functions (such as timers and queues) is "configure first, process later". You first need to declare their trigger rules or binding information in the wrangler.jsonc file. Then, in the worker.ts file, you need to implement a corresponding processor function (such as scheduled for timer, queue for queue) to respond to these events and execute specific business logic.
    2. Class-Based Extension
        The representative of this type of functionality
    
    Members only

    Subscribe to unlock the full article

    Support the writing, unlock every paragraph, and receive future updates instantly.

    Comments

    Join the conversation

    0 comments
    Sign in to comment

    No comments yet. Be the first to add one.