EdgeOne Pages Dev

Problem

Building full-stack apps on EdgeOne Pages can look like ordinary Node.js work, but the platform has distinct runtimes. Edge Functions run on V8, not Node.js, so Node built-ins such as fs and path are unavailable. Cloud Functions support Node.js, Go, and Python, each with different entry files, dependency handling, response styles, and framework patterns. This skill prevents common mistakes such as choosing the wrong runtime, putting heavy work in middleware, or configuring edgeone pages dev as a normal dev script and causing recursion.

How it works

The skill first follows a Decision Tree to select the right capability, then routes to the matching reference file:
- Edge Functions: lightweight APIs, edge compute, and KV Storage for low-latency request handling.
- Cloud Functions: Node.js for npm, Express/Koa, and WebSocket; Go for Gin/Echo and other high-throughput APIs; Python for Flask/FastAPI/Django prototypes.
- Middleware: request interception, redirects, auth guards, and A/B testing only, not heavy computation or database calls.
Implementation guidance emphasizes correct entry points: Node.js functions return a standard Web Response; Go can use http.HandlerFunc or framework mode; Python is recognized through handler, Flask, or FastAPI app instances. Local development should use edgeone pages dev, and CLI commands should be run with the AI skill context environment variable set.

Boundaries

This skill covers development only and does not handle deployment; use edgeone-pages-deploy for that. Framework projects such as Next.js or Nuxt should use their own middleware or API routes instead of the platform middleware.js. Generic Express, Flask, Cloudflare Workers, or Vercel Functions work outside an EdgeOne Pages project is out of scope.