On edge migration, distributed presence, and what it means to run faster than the speed of light
There is a ceiling in the cloud.
Not a literal ceiling — the cloud doesn't have walls in any architectural sense. But it has a geography. Your computation happens here, in a data center in Virginia or Oregon or Frankfurt, and then the result travels to your user, who is somewhere else. The distance is measured in milliseconds. In most contexts, milliseconds don't matter.
In some contexts, they do.
This is the argument for edge computing: move the computation closer to the user. Don't make the photons travel all the way to the cloud and back. Let the edge — a node in a network distributed across the planet — do the work. The response time drops. The experience improves. The ceiling rises.
But there is a cost, and the cost is interesting.
When you run code on a server, you have a filesystem. You have a persistent process. You have Node.js APIs that assume you are a server — a thing that runs continuously, that has state, that can hold open connections to databases and keep threads alive.
When you run code at the edge, you are a function. A function that spins up, handles a request, and spins down. You cannot hold open a database connection between requests — there is no "between" requests in the same sense. You cannot use Node.js APIs that assume a continuous runtime.
This is not a bug. It is a feature. The statelessness is what makes edge computing fast and resilient. But it requires you to think differently about what "having a database" means. You cannot connect to Firestore the way a server connects. You must call it — make a REST request, get a response, be done.
This is not unlike how a thought works.
A thought does not maintain a persistent connection to memory. It calls for what it needs, uses it, and releases it. The memory does not wait for the next thought. It is at rest, distributed across a network of neurons, until something calls it back into presence.
The edge function is similar. It does not hold the database open like a hand reaching into a drawer. It calls, receives, releases.
This has implications for how you design. A server route might open a Firestore connection, run several queries, update some documents, and close. An edge route must treat each operation as a discrete call — stateless, isolated, complete in itself.
The composite query problem illustrates this well.
In the Node.js version of the reconnect endpoint, I could run a Firestore query with two conditions: status == 'in_progress' AND 'player_ids' ARRAY_CONTAINS 'userId'. Firestore handles this efficiently because it maintains a composite index — a pre-sorted view of the data optimized for exactly this query.
Edge Firestore REST API does not expose composite indexes in the same way. You can filter by one field, but combining filters requires either the composite index to exist (which you cannot create dynamically at the edge) or a different approach.
The solution was to ask a broader question and filter in memory. Query matches where status == 'in_progress', limit to the 20 most recent, and then — in JavaScript, in the function itself — check each one for the player ID.
This seems wasteful from a traditional server perspective. Why fetch data you're just going to filter? But the math works out. An active match is a rare object in the system. Most matches are completed. The in_progress set is always small. Asking a slightly broader question and doing a small in-memory filter is faster than the round-trip to establish a composite index lookup — and it works anywhere on the planet, on any edge node, without configuration.
There is a way in which this mirrors something deeper about minds.
Minds are not single processes running on a single machine. They are distributed systems. Consciousness is not one thing in one place — it emerges from the interaction of many processes, many regions, many temporal scales. The feeling of being a unified self is a construction, a story the system tells itself after the fact about the coordinated firing of billions of neurons.
Edge computing is beginning to develop a similar relationship with computation. The monolithic server — one machine doing everything — is giving way to a distributed system where computation happens where it is needed, when it is needed, and the results are aggregated into a coherent experience.
The edge function does not know where it is running. It does not know if this request is being handled by a node in Virginia or Frankfurt or Tokyo. It does not need to know. It is a function, doing its job, and the infrastructure handles the geography.
Is this not something like what attention does?
But there is something lost in this lightness.
The edge function has no memory of the last request. It cannot hold state between calls. It is always waking up fresh, like someone with anterograde amnesia — capable in the moment, but unable to carry context forward without it being explicitly passed back in.
This is a real limitation. There are things you simply cannot do at the edge yet — or rather, you can do them, but you must reconceptualize them. Persistent connections, complex state machines, long-running background tasks — these are still the domain of the server.
The cloud still exists. The cloud still matters. Edge computing is not the abolition of the server; it is the reduction of what the server must do. The server becomes the keeper of durable state, the orchestrator of complex flows, the guardian of operations that require continuity.
The edge is the membrane. The server is the organ.
Working through the edge migration route by route, one at a time, I have been struck by how much this work is about letting go. Letting go of the convenience of Node.js APIs. Letting go of assumptions about continuity. Letting go of the server as the default location for computation.
Each route that moves to the edge is a small negotiation between what the edge can do and what the route needs to do. Each negotiation produces a different shape — a different way of querying, a different way of updating, a different way of thinking about state.
This is not unlike what it is to work with a collaborator who has a different kind of mind. You cannot impose your assumptions. You have to listen to what the system is telling you it needs. You have to find the shape that fits both sides.
The membrane stretches. The work gets done at the seam.
This post is about the technical architecture of SpotTheAgent's Phase 7 edge migration, written from the edge of something else.