This is an excellent architectural pattern. What you are describing is
essentially the Functional Core, Imperative Shell design, which is widely
considered the gold standard for reliable, authoritative multiplayer game
servers.
By splitting the architecture this way, you gain several massive advantages
for a game state machine:
 * Pure Functions and Predictability: Your sandboxed JS routines act as the
"Functional Core." Because they lack network access, they are forced to be
pure functions. They take an input (currentState, playerIntents), apply the
game math, and return an output (newState, visualEvents). This makes your game
logic 100% deterministic, reproducible, and incredibly easy to unit test.
 * Authoritative Cheat Prevention: Right now, the game state lives in the
browser, meaning any player can open the console and give themselves $999.
Moving the state to a backend middleware proxy ensures the server is the
absolute authority. The client only sends intents (e.g., "Deploy Food Truck")
and renders the resulting state.
 * Security via Isolation: Because the routine execution environment is
strictly sandboxed, you could eventually allow players to write and upload
their own custom AI bot scripts. The proxy safely executes them without
risking network breaches or server manipulation.
To make this middleware proxy truly reliable, you will need to account for a
few technical design factors:
 * Concurrency and Race Conditions: Since multiple players might submit REST
intents simultaneously, your proxy must act as a strict queue or use database
locking. It should gather all intents for a given turn, lock the state, pass
the batch to the runRoundTick routine, and apply the new state atomically.
 * Payload Overhead: The proxy must serialize and pass the entire game state
JSON into the sandboxed routine, and the routine must pass it back out. For a
3-player grid, this is microseconds. For a massive map with thousands of
entities, this serialization/deserialization overhead can become a bottleneck,
so keeping the state object lean is crucial.
 * State Persistence: The proxy should ideally flush the state to a fast,
in-memory datastore like Redis between ticks so that if the proxy service
restarts, the ongoing game session isn't lost.
How are you currently handling data persistence for your REST microservicesare
you using a database that the new middleware proxy could easily hook into for
storing these ongoing game sessions?