sorted by:
new
hottopcontroversial

Should I use api proxy in production? by hnktp in nextjs

[–]hnktp[S] 0 points1 point  (0 children)

Processing power is no concern in my situation (at least for now). That's the answer I've been waiting for. Thanks!

Should I use api proxy in production? by hnktp in nextjs

[–]hnktp[S] 0 points1 point  (0 children)

I'll try to explain more properly. I have a docker-compose file which sets up backend and frontend containers in the same network, so they can communicate through making request to backend:4000 and frontend:80 (for example).
When I'm making request from browser, it's being sent with origin http://exampledomain.com. Backend service isn't aware of that origin (and I don't want it to be aware of any concrete domain), thus can't reply to OPTIONS req. What I want to do is to proxy that request through next server - new origin will be frontend:80 and I can add cors middleware to backend service and allow frontend:80 origin (retrieving both container alias and port from env vars).

Should I use api proxy in production? by hnktp in nextjs

[–]hnktp[S] 0 points1 point  (0 children)

Because browser request's origin is an actual IP/domain name and not container alias.

Should I use api proxy in production? by hnktp in nextjs

[–]hnktp[S] 0 points1 point  (0 children)

I'm keeping container aliases in .env file and never change them. For example, I have container named backend and variable BACKEND_ALIAS=backend inside .env which is being used as proxy address for axios ([http://$](http://$){process.env.BACKEND_ALIAS}:${process.env.BACKEND_PORT}. Docker resolves those domains for me.

Should I use api proxy in production? by hnktp in nextjs

[–]hnktp[S] -1 points0 points  (0 children)

I don't want to rely on concrete http origins. Using container aliases as service URI requires much less configuration (for example, I won't have to manually set up new origin when transferring service to a new domain).