Deployed Server is a Private Docker Container

[lepeuvedic-natixar]

https://github.com/Natixar/Blockchain-frontend/blob/cb0d07e4cb5f62c82b7418b30cecd8560df6a5b1/.github/workflows/deploy.yml#L40

Problem

The deployment makes undocumented assumptions. The resulting deployed docker server isn't publicly accessible.

How to Reproduce?

Just deploy successfully on a server.

What is Needed Instead?

The deployment process leaves behind a running docker container which serves the app on port 3024. It is not good practice to let the same server serve static resources and server side rendered pages. The deployment script should at last document the required configuration of a web server (preferably Apache or Cloudflare) for static resources, and proxying the script URLs to the node server.

Note that breaking the Jamstack assumption has significant consequences, on security and operational deployment.

[lepeuvedic]

The current deployment target is the development container.

[Sagerahl]

Clarification on Next.js and the Current Docker Setup:

The current Next.js application is designed to be served directly from a Node.js process inside the Docker container, which is a common practice for server-side rendered applications. The deployment script sets up a Docker container that runs the Next.js server on port 3024.

This setup assumes that the Docker container runs in an environment where it's either:

• Directly accessible via the specified port.
• Behind a reverse proxy, such as Nginx or Apache, which handles SSL termination, caching, and static file serving.

It’s true that for more complex production environments, separating concerns and using a reverse proxy (e.g., Nginx/Apache) in front of the Docker container is common practice. This is usually done to:

• Offload the serving of static assets (like images, JS, CSS) for better performance.
• Handle SSL termination.
• Manage caching, load balancing, and proxying dynamic requests to the Next.js app.

However, the Next.js app in its current form can directly serve both static resources and server-side rendered pages within the container itself.

If you prefer to serve static resources and proxy requests through Nginx/Apache (as you've suggested), it’s certainly possible to configure an Nginx or Apache reverse proxy in front of the container. This would allow you to:

• Serve static assets directly from Nginx/Apache from .next/static
• Proxy API and dynamic requests to the Next.js server running in Docker.

[lepeuvedic]

Serving static resources from the node server is considered bad practice because it only uses cooperative multitasking and cannot fully utilize the resources of the host system. Its very basic HTTP server is not meant for front line use either (not focused on cyberdefense) and may not make optimal use of Internet caching.

The current setup uses HAProxy to handle SSL termination, request validation, load balancing and routing to backends. It is quite easy to route a /static route to Apache. Apache runs and serves static web sites and their resources, and also currently handles the reverse proxy for some server-side rendered PHP services, although this is being phased out.

As an alternate, we can deploy static resources on render.com using a subdomain like static-blockchain.natixar.pro (.com in the future). The deployment only requires a script that would be downloaded by render automatically upon successful pull request completions and executed to isolate the resources in a folder. Render runs the build on private servers (with Internet access) and only installs the specified build folders on CloudFlare. Performance and security of CloudFlare served static files is great (much better than Nginx or Apache on my servers).

But, this approach implies some flexibility in the source address of static resources between dev and prod environments, and also has CORS implications.

The remaining issues here, are:

• to extract the /static resource bundle in the deployment script (can be a full build followed by extraction of /static)
• make sure the pages use a configurable prefix to access static resources (is it possible?)

[Sagerahl]

Thanks for your suggestions.

• Extracting Static Assets: I could update the deployment process to extract the static files from .next/static after the build. However, I would need more information about the exact location where these files should be copied, whether that's an Apache server directory or another service like Render.com.

• Configurable Static Resource Prefix: I could configure the app to use a configurable prefix for static resources via assetPrefix in next.config.js. This would allow the static resources to be served from a different location (like Apache or CloudFlare) in production, while keeping it simple in development. Using something this in the next.config.mjs: assetPrefix: process.env.NODE_ENV === 'production' ? 'https://static-blockchain.natixar.pro' : ''

• CORS Configuration: If we decide to serve the static assets from a different domain (e.g., Render.com with CloudFlare), we would also need to ensure that proper CORS headers are set to allow the main app to access these assets.

Additional Information Needed:

Could you please provide more details on where and how the .next/static files should be deployed in your setup? Once I have that information, I can make the necessary updates to the deployment process.