Use standard HTTP API to call Turms Service instead of forwarding through Turms Gateway

[jiangshang111]

A polite question, do you have plans to expose the HTTP API format for Turms Gateway to make RPC calls to Turms Service? Turms is great, but your current implementation restricts you to a specific deployment model. Specifically, it is difficult for me to deploy Turms as a microservice in my complete architecture, because I must at least expose Turms Gateway to facilitate remote users to establish a persistent connection with it, which will conflict with my complete deployment design. My complete design is: deploy a portal that encapsulates all backend microservices, and Turms Service is one of the microservices. I will maintain a persistent connection and heartbeat signals with remote users through the portal. I hope to rewrite Turms Gateway (for example, in Rust) so that the functions of Turms Gateway can be implemented in the Rust-based portal that I will implement, and this portal will interact with the backend Turms Service to achieve the complete Turms functionality. Any suggestions?

[jiangshang111]

The idea I proposed is not just to maintain the heartbeat signal. I can certainly use Rust to implement a WebSocket two-way proxy. However, if it involves semantic transcription, for example, if the original semantics of Turms require three calls to complete the request, I can define a new call on the SDK, and transcribe this call into three calls to Turms Service on the portal, and return the return results of these three calls to the client after business processing. Although the example I gave does not hinder the existence of Turms Gateway, it seems unnecessary. Therefore, since the Turms framework itself is already a layered architecture design pattern, it seems to be a better way to clearly define the boundaries of the two layers externally.

[JamesChenX]

turms-gateway is mainly responsible for 1. Authentication; 2. Session representation (by managing session data in Redis); 3. Push notifications; 4. Backpressure.

So, rather than implementing all these features from scratch in your own gateway. It's practical to use your own gateway as a proxy for turms-gateway and write plugins or update its configs/code if necessary, just like the Nginx servers for the backend servers.

• In other words, your gateway accepts users' connections (no matter whether it is a TCP or WebSocket connection, it is up to you), and creates a TCP or WebSocket connection per user to turms-gateway as needed. In simple words, you can think that turms-gateway treats one authenticated network connection as one user session.
• If your gateway has already handled authentication, you can disable the auth of turms-gateway (for details, read the docs).
• To pass correct client IP to turms-gateway, remember to use HAProxy Protocol for TCP connections and X-Forwarded-For header for WebSocket connections.

This solution is more praticable. If you have other custom logic that really needed to be implemented in turms-gateway, you can write plugins or update its code (that's the meaning of open-source) rather than implementing a server like turms-gateway from scratch.

---

do you have plans to expose the HTTP API format for Turms Gateway to make RPC calls to Turms Service

As a result, no plan for it until there is a real demand.

---

btw, from the perspective of business, ecosystem, and project management, it is not a good idea to implement turms-gateway in Rust in most scenarios.