Managing deployments for a multi-domain, multi-microservice architecture requires ensuring consistency and reliability across all components. The primary challenge is preventing incompatible versions between APIs, databases, and client applications, which can lead to unexpected behavior, bugs, and corrupted data that may only be discovered after failures occur.
Next.js addresses this elegantly through single deployments. We follow the same pattern for client-facing applications: app.zooly.ai serves as the single deployment, with other client apps reverse-proxied to it.
auth.zooly.ai
Type: Next.js app (self-contained)
The auth.zooly.ai application is a single entrypoint for all authentication across all Zooly applications (including local, dev, stage, and prod environments). This separation exists because:
app.zooly.ai
Type: Next.js app (shared backend)
The app.zooly.ai application serves as the backend for all applications that require write access to the database. It handles all write operations and serves as the primary deployment target for client-facing applications.
api-readonly.zooly.ai
Type: Next.js app (read-only backend)
The api-readonly.zooly.ai application provides read-only backend access for all applications that need to query the database without write permissions. This separation helps optimize read performance and provides an additional security boundary.
ops.zooly.ai
Type: Vite app (client-only)
The Ops app is a client-only application built with Vite. It consumes both app.zooly.ai and api-readonly.zooly.ai as backends. This app can be deployed separately, allowing for quick fixes to statistics and metrics without deploying the full application stack and risking disruption to the main app.
Deployment Considerations for Ops App
app.zooly.ai can break the applicationReverse proxy applications are deployed as part of the main app's single deployment. These proxies are typically configured once and rarely changed, as the actual application code resides in the main app.