Proxying internal website traffic to a developer’s local machine for faster iteration
When we started Bixoto.com, we chose Magento for the website because at that time it was the best open-source platform for ecommerce with an API to deal with supply and catalog, and later to go headless. In July 2023, we replaced 99% of the frontend with SvelteKit, and kept only some essential pages in Magento for now.
This setup is using a nginx reverse proxy configured to server some paths with SvelteKit and others with Magento. It works roughly like this:
upstream svelte {
server 127.0.0.1:1234;
}
upstream magento {
server unix:/run/php/php-fpm.sock;
}
server {
listen 443 ssl http2;
server_name bixoto.com;
location /pages-served-by-svelte {
proxy_pass http://svelte;
}
location /pages-served-by-magento {
fastcgi_pass magento;
}
The real setup is more complex, but this is the gist of it.
We recently had the need to develop a complex feature that needed to use our internal development environment, but it would have been cumbersome to directly develop on the server or push every time we wanted to test. A solution we found was to reverse-proxy /pages-served-by-svelte not to the local server, but directly to the developer’s computer.
The dev used npm dev -- --host $private_ip --port 5173 to expose their local server on our private network, and on the server we modified the nginx config to proxy to that address:
upstream svelte {
# Normal config:
#server 127.0.0.1:1234;
# New config:
server $private_ip:5173;
}
We had to add a few patterns to the proxied routes (/@fs/, /@id/, /@vite/, /src/, /node_modules/, /.vite/, /.svelte-kit/) for this to properly work. Once we reloaded nginx, all requests to /pages-served-by-svelte were routed to the developer’s computer. This enabled a fast feedback loop.
To revert to the normal setup, we just have to change the server directive to point to the local server again.
This is of course something you shouldn’t do in production, but for development on a private network it works well.
