如何实现后端通过浏览器向用户本地localhost服务器发起请求（含GraphQL方案）

Great question—this is a classic "browser as a bridge" scenario since your backend can't reach the user's localhost directly. Let's break down the feasible approaches, with a focus on GraphQL support, along with tech choices and library recommendations.

Core Architecture Overview #

The core idea is to use the user's browser (which has localhost access) as a middleman between your remote backend and their local Python server. The flow looks like this:

Your Remote Backend ↔ Browser (ReScript) ↔ Local Python Server (localhost:2000)

For GraphQL, we need to handle three operations: queries, mutations, and subscriptions. Subscriptions require bidirectional real-time communication, so WebSocket is the best fit here—though we can cover HTTP-based flows for simpler use cases too.

Recommended Technical Stack #

Primary Choice: WebSocket-Based Proxy (Supports GraphQL Subscriptions) #

WebSocket enables full bidirectional communication, which is essential for GraphQL subscriptions (real-time updates from the local Python server to your backend). This is the most robust approach for complete GraphQL support.

Alternative: HTTP + Long Polling/SSE (For Queries/Mutations Only) #

If you don't need subscriptions, you can use HTTP with long polling or Server-Sent Events (SSE) for one-way updates, but WebSocket is cleaner for any real-time needs.

Step-by-Step Implementation Schemes #

1. WebSocket Proxy with GraphQL Support #

This is the preferred approach, especially if you need GraphQL subscriptions.

Flow Details:

• Step 1: The user's browser (ReScript app) establishes two WebSocket connections:
  1. One to your remote backend (e.g., wss://your-backend.com/proxy)
  2. Another to the local Python server's GraphQL WebSocket endpoint (e.g., ws://localhost:2000/graphql/subscriptions)
• Step 2: When your remote backend needs to send a GraphQL query/mutation/subscription to the local server, it sends the payload over the first WebSocket to the browser.
• Step 3: The ReScript frontend forwards this payload to the local Python server's GraphQL WebSocket.
• Step 4: Responses (including subscription events) from the local server are sent back through the browser to your remote backend.

Library Recommendations:

• ReScript Frontend:
  • Use @rescript/ws (a ReScript binding for the Node.js ws library) to handle WebSocket connections.
  • For GraphQL client logic (to talk to the local server), use @rescript/apollo-client if you're using Apollo, or wrap a lightweight client like graphql-request with ReScript bindings.
• Local Python Server:
  • For GraphQL with WebSocket subscriptions: Use Graphene (GraphQL framework) + Django Channels (if using Django) or Ariadne (GraphQL library with native WebSocket support).
  • Example: Set up a WebSocket endpoint in Ariadne to handle GraphQL subscriptions per the official protocol.
• Your Remote Backend:
  • If using Node.js: Use the ws library to manage WebSocket connections with browsers.
  • If using Python: Use websockets library for WebSocket server logic.

Security Note:

• Add authentication (e.g., JWT) to the WebSocket connection between your backend and the browser to ensure only authorized users can use the proxy.
• Validate all payloads forwarded to the local server to prevent malicious requests from reaching the user's machine.

2. HTTP Proxy for GraphQL Queries/Mutations (No Subscriptions) #

If you only need to handle queries and mutations (no real-time subscriptions), you can use an HTTP-based flow with the browser as a relay.

Flow Details:

• Step 1: Your remote backend sends a request to the browser (via WebSocket or SSE) containing the GraphQL query/mutation payload.
• Step 2: The ReScript frontend uses fetch (via @rescript/fetch) to send the payload to http://localhost:2000/graphql.
• Step 3: The frontend receives the GraphQL response and sends it back to your remote backend via the same WebSocket/SSE channel.

Library Recommendations:

• ReScript: Use @rescript/fetch for HTTP calls to the local server.
• Local Python Server: Any GraphQL library works (e.g., Graphene, Ariadne) since we're using standard HTTP POST requests.

3. Service Worker Transparent Proxy (Advanced) #

For a more seamless experience (without modifying your main frontend UI code), you can use a Service Worker to intercept requests from your remote backend and forward them to the local server.

Flow Details:

• Step 1: The user's browser installs and activates a Service Worker from your app.
• Step 2: Your remote backend sends requests to a specific endpoint (e.g., https://your-app.com/local-proxy/graphql).
• Step 3: The Service Worker intercepts these requests, modifies the URL to http://localhost:2000/graphql, and forwards them.
• Step 4: The Service Worker receives the response from the local server and sends it back to your remote backend.

Caveats:

• Service Workers only work over HTTPS (or localhost for development).
• Requires the user to have your app open in the browser for the Service Worker to be active.

Key Considerations for GraphQL #

• GraphQL Over WebSocket: For subscriptions, make sure both your remote backend and local Python server implement the standard GraphQL over WebSocket Protocol—most modern GraphQL libraries support this out of the box.
• Payload Forwarding: When relaying GraphQL requests, ensure you preserve all headers (like Content-Type: application/json) and payload structure (including operationName, variables, and query).

内容的提问来源于stack exchange，提问作者Peteris