You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running next.js on Workers without smart placement turned on means that any backend logic will have highly unpredictable latency because the server-side logic will run in various locations around the world talking to data/APIs that are mostly centralized in one or small number of locations.
But turning on smart placement, we let the platform determine where the compute should be "placed". The platform will use signals such as db/rest API calls to determine the ideal location, and will place the compute there. This reduces the overall latency of requests that require server-side execution.
There is however a problem. We don't want all of server-side logic to execute in the smartly placed location, as for example the caching and routing logic, should always execute at the edge — close to the user.
So ideally, we'd actually create two worker bundles for each next.js app. One that contains all of our routing logic and user-provided middleware, and second with all the SSR logic.
This obviously increases the complexity of the deployment, since we now have to deploy two workers instead instead of one, and ideally also handle version skew protection between the two workers, which is currently not well supported by the platform.
The text was updated successfully, but these errors were encountered:
Running next.js on Workers without smart placement turned on means that any backend logic will have highly unpredictable latency because the server-side logic will run in various locations around the world talking to data/APIs that are mostly centralized in one or small number of locations.
But turning on smart placement, we let the platform determine where the compute should be "placed". The platform will use signals such as db/rest API calls to determine the ideal location, and will place the compute there. This reduces the overall latency of requests that require server-side execution.
There is however a problem. We don't want all of server-side logic to execute in the smartly placed location, as for example the caching and routing logic, should always execute at the edge — close to the user.
So ideally, we'd actually create two worker bundles for each next.js app. One that contains all of our routing logic and user-provided middleware, and second with all the SSR logic.
This obviously increases the complexity of the deployment, since we now have to deploy two workers instead instead of one, and ideally also handle version skew protection between the two workers, which is currently not well supported by the platform.
The text was updated successfully, but these errors were encountered: