Wasp app behind reverse proxy does not request correct server url
Im using a custom docker stack with two containers, one node and one nginx with static app files and they are properly built and setup inside their respective containers with all necessary environment variables etc and this setup works for a locally built app with the proper backend urls - like so: https://internaldomain.com/srv/.
When deploying to an external host, the frontend static files want to connect to http://waspbackend/auth/me which is the upstream internal target host. I'm curious why my backend seem to provide its internal host name to the frontend, when I have clearly set the url with REACT_APP_API_URL during the build step of the wasp node app.
As my current deployment method is seemingly unusual, maybe there is something Im doing wrong here?
Please advice.
5 Replies
Hi @linus625. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
It sounds like you're experiencing an issue with your Wasp app's frontend not connecting to the correct backend URL when deployed behind a reverse proxy. This is a common issue when deploying Wasp apps in custom environments.
The Issue
When you build your Wasp app's frontend, it needs to know where to find the backend API. This is controlled by the
REACT_APP_API_URL environment variable. However, there are a few important things to understand about how this works:
1. The REACT_APP_API_URL must be set during the build process of the frontend, not at runtime. This is because React embeds environment variables in the static files during build time Deploying the Web Client.
2. The URL should be the one that the browser will use to access your backend, not the internal Docker network URL.
Solution
Here's what you should check:
1. Make sure you're setting REACT_APP_API_URL correctly during the build step of your frontend:
2. Ensure there are no trailing slashes issues. As mentioned in a GitHub issue, trailing slashes can cause problems with API calls When building the client for deployment.
3. Verify that the URL is valid. Wasp should validate URLs, but it's good to double-check Ensure the REACT_APP_API_URL.
4. If you're using a proxy in development, be aware that this can sometimes cause issues as noted in this GitHub issue Proxy for dev server.
Accessing Configuration
You can check what URL your frontend is actually using by accessing the configuration object in your client code:
This will show you what URL your frontend is trying to use for API calls Client configuration object.
Environment Variables
For your backend, make sure you've set these required environment variables:
- DATABASE_URL - Your PostgreSQL connection string
- WASP_WEB_CLIENT_URL - The URL where your frontend is accessible
- WASP_SERVER_URL - The URL where your backend is accessible
- JWT_SECRET - If using Wasp Auth Environment Variables
Your issue is likely that the REACT_APP_API_URL wasn't properly set during the frontend build process, or there might be an issue with how your reverse proxy is configured. Double-check these settings and ensure your frontend is built with the correct external URL that browsers will use to access your API.
I hope this helps with your deployment setup!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @linus625, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Yes, that is why I do this when building the web-app:
"RUN cd .wasp/build/web-app && npm install && REACT_APP_API_URL=${SERVER_URL} npm run build
"
Wohooo @linus625, you just became a Waspeteer level 2!
If you set the
REACT_APP_API_URL env var correctly and you are using the latest built JS - it should work
Make sure that the JS you built is actually used and you are not using some cached old versionWill try again.
Mysteriously, this is not an issue now, after having upgrading my db to certificate based authentication with a custom ca. That was another rabbit hole though. You can read about that here: https://discord.com/channels/686873244791210014/1360545905362866226