Reverse Proxy to easily allow for different domains #14
Conversation
Currently the frontend needs to be recompiled in order to host it on a different domain since the "NEXT_PUBLIC_API_SERVER_URL" is compiled into the dashboard. If we instead compile the frontend to make requests to the backend on a fixed root path (e.g. "/api") then we can use a proxy to forward those requests to the backend without needing to worry about CORS. This patch introduces traefik as a reverse proxy to give an idea on how this would look like
|
Cnidarias
changed the title
|
Hey Cnidarias, Thanks for being the 1st contributor to HyperDX 🎉
To simplify the problem, I think we could put default frontend domain URL at |
| docker buildx build ./docker/hostmetrics -t ${IMAGE_NAME}:${LATEST_VERSION}-hostmetrics --target prod & | ||
| docker buildx build ./docker/ingestor -t ${IMAGE_NAME}:${LATEST_VERSION}-ingestor --target prod & | ||
| docker buildx build ./docker/otel-collector -t ${IMAGE_NAME}:${LATEST_VERSION}-otel-collector --target prod & | ||
| docker buildx build --build-arg CODE_VERSION=${LATEST_VERSION} . -f ./packages/miner/Dockerfile -t ${IMAGE_NAME}:${LATEST_VERSION}-miner --target prod & | ||
| docker buildx build --build-arg CODE_VERSION=${LATEST_VERSION} . -f ./packages/api/Dockerfile -t ${IMAGE_NAME}:${LATEST_VERSION}-api --target prod & | ||
| docker buildx build --build-arg NEXT_PUBLIC_API_SERVER_URL='/api' --build-arg CODE_VERSION=${LATEST_VERSION} . -f ./packages/app/Dockerfile -t ${IMAGE_NAME}:${LATEST_VERSION}-app --target prod |
There was a problem hiding this comment.
Good stuff here. I think we want to disable multi-platform build (for local build purpose). Will include this in the separate PR
|
Hey, Thanks for pointing out the issue with the While making it easier to build the image is probably a good start I still feel like providing an option to just run it "wherever" would be really beneficial. I am assuming there are quite a few people that would love to just throw it on a VM and use it there (that's how I stumbled upon the issue) - and I'd like to avoid having to build it first, push it into my CR and then use it. Obviously deciding on if it's worth to add another dependency or not is always tricky. I just threw this PR together really quickly because I wanted to be able to test things and \I saw others were having similar issues. I wasn't really expecting it to get merged ;) One should however probably remove the Thanks again for the cool tool! |
Totally make sense. Please throw any ideas. We'd appreciate and take all feedback seriously. I'm gonna remove |
|
How about we go with less of an "integrated" approach of we're shipping this with another dependency to more of an example type deal? We could make like an example directory for running it behind a proxy e.g. And then in the README we include the steps for building the docker image with the required NEXT_PUBLIC_API_SERVER_URL - the docker-compose.traefik.yml would include traefik and the required overrides for the other services (e.g. the labels for frontend and backend) and then one would run it like so This would allow others to also add configurations for other provides? Then include a link in the main README so people find it quickly? |
Great idea! For the better DX, I'd prefer to not add the dependency at this moment. The goal is every dev should be able to easily start + rebuild the project meanwhile they can plug any dependency if they want to. We really appreciate the effort to solve the problem. It should be resolved in the next release :) |
Hey
Great work on the project - I really like it so far!
I ran into the same issue as #12 and figured it would be a nicer solution if we used a reverse proxy for the communication between frontend and backend.