[question] using Centrifugo Proxy endpoint in stateful services ?

[sajjad-fatehi]

Hey guys,

There is a situation we need help with, so if anyone can help, it would be greatly appreciated.

During the previous conversation, you advised against using client SDK (websocket) in the backend. Due to the stateful nature of our service and the fact that it runs in a K8s environment, we cannot manage the RPC proxy endpoint, and using Centrifugo API seems impossible. Could we use the server API without changing our software architecture? Is there anything you can advise me on?

[FZambia]

@sajjad-fatehi hello, to be honest I do not understand the problem here – could you elaborate more? Why k8s is a limiting factor? Why exactly using RPC proxy endpoint is impossible? K8s provides services, services have DNS address, so communication between Centrifugo and your backend should be definitely possible.

[sajjad-fatehi]

you are right ! its possible in k8s to communicate between services.
let me explain more :
our service is not stateless ! so we have to create channels isolated . i mean a channel only will be created and used in one of our PODs.
so if we suppose we have 2 PODs , we have two api endpoint addresses like :

• k8s-link-pod-1
• k8s-link-pod-2
  correct me if im wrong here
  now if any client connect to centrifugo and send RPC to Channel-1 ... i want to all RPCs proxies to only k8s-link-pod-1.
  something like this .

[FZambia]

RPCs are not sent to channel, they have method and data fields. I.e. no relation to channels at all.

Does Granular proxy mode solves this for you? You can configure different RPC endpoints for different RPC namespaces. If you need more complex logic on per-method level – then I suppose you can create HTTP proxy service which will route RPC requests from Centrifugo to proper destinations.

[sajjad-fatehi]

thank you .

I suppose you can create HTTP proxy service which will route RPC requests from Centrifugo to proper destinations

i think this is our solution.

[FZambia]

There is a very similar issue about channel-related proxying - #483 - the idea is to have some templating for proxy endpoint construction, based on variables available at the moment of issuing the request.

In this case you are talking about RPCs, so I suppose all we have is user and method at this point - sth like pattern matching to detect endpoint could be done I suppose, but this requires full understanding how exactly you want to transform methods to endpoints. Probably describe your use case there, maybe it will be possible to address one day – but it's definitely not a quick addition