I often see the convention where /api/* paths are routed to the backend through a reverse proxy. For instance, the frontend would call $FRONTEND_URL/api/..., and something like nginx would map these /api/* routes to the backend URL.
What if the frontend directly calls the backend’s domain, such as $BACKEND_URL/api/...?
Is this really considered bad practice, or is it just not preferred because of potential complexity in larger setups? Personally, I find directly calling the backend easier for my project since I don’t have to manage nginx or rerouting rules. However, I want to ensure this approach is secure. Thanks for your insights!
EDIT: Thanks for your responses! To clarify, my query is about directly calling the backend API domain from the frontend versus routing /api paths via a proxy.
what’s your take on handling security when making direct calls in smaller projects? i see the simplicity angle, but do the benefits really outweigh the risks for you?
Choosing between direct API calls and using a reverse proxy depends on the context of your project. For smaller applications or during the development phase, direct calls to the backend API can indeed simplify your setup and reduce latency. However, directly exposing your API to the frontend does come with significant security risks, including CORS issues and potential data exposure. In larger and production environments, using a reverse proxy is generally preferred to improve security through centralized handling of authentication and logging, offering scalability benefits and easing maintenance by decoupling services.
If you keep your project smaller, and control your environment, directly calling the backend might be feasible. Just ensure you’re handling security well, especially with CORS and auth issues. Larger setups though, a reverse proxy like nginx will give better control and scalability. It’s more about security and future growth.