SocketIO Docs

[eweren]

Currently the docs on all socket events are missing as well as a more detailed setup when self-hosted.

[JanCizmar]

Thanks for reporting!

Websocket events are noc currently meant to be used internally by the frontend. However, it's still not used by the frontend and thats why it's not described in the the self-hosting docs section.

Do you have any use case for using websocket events? If yes, I can document it next week. 👍

[cyyynthia]

The @tolgee/socketio-client js package contains a bit of information about what events are broadcasted by the Socket.IO server, this may be useful for reference.

For the setup when self-hosting Tolgee, I'm unsure what's missing as there's barely anything to do to get the Socket.IO server up and running (and is enabled with the default configuration) 🤔

As for the use case, it could be used to wire translation hot-reload while developing, which I can see being useful especially when working on mobile apps where "refreshing" isn't as easy as pressing f5 on a keyboard 😅

[eweren]

I didn't have a real world use case in mind. I was just wondering what exactly the socket endpoint is. When hosting via docker the docs show that it runs on 9090 but since I couldn't connect I was just wondering what the exact endpoint was. Haven't seen the socket repo of yours. I guess that helps :)

[cyyynthia]

When hosting via docker the docs show that it runs on 9090 but since I couldn't connect

The command shown in the docs doesn't have it iirc, but you need to tell Docker expose port 9090 to connect (-p 9090:9090) otherwise the socket is not available on your localhost.

That being said, seeing that the Socket.IO server isn't actually used or documented beyond the config properties, I'm wondering if a plain WebSocket server on the main http server wouldn't be enough for Tolgee (e.g. wss://app.tolgee.io/api/websocket); not only would it be lighter on the network, but it'd mean a simpler structure (only 1 http server), and better compatibility as WebSockets are simpler to deal with overall than a Socket.IO server which is a more complex protocol to deal with

[eweren]

That being said, seeing that the Socket.IO server isn't actually used or documented beyond the config properties, I'm wondering if a plain WebSocket server on the main http server wouldn't be enough for Tolgee (e.g. wss://app.tolgee.io/api/websocket); not only would it be lighter on the network, but it'd mean a simpler structure (only 1 http server), and better compatibility as WebSockets are simpler to deal with overall than a Socket.IO server which is a more complex protocol to deal with

Sounds great to me!

[JanCizmar]

  I'm wondering if a plain WebSocket server on the main http server wouldn't be enough for Tolgee

Yep. We wanted to use Socket.IO, since it looks like more trusted in Frontend world. But it has multiple drawbacks. We are using Netty SocketiIO, which is not supporting SocketIO v4, so we are stuck with version 2. Also the package doesn't seem to be that reliable now.

It seems like it's possible to really do it with single http server, which i didn't know.

However, we currently have different priorities, so if you would be interested into digging into it and try to replace the Netty SocketIO with the Spring websocket integration feel free to do that. Otherwise I keep this open until the time for working on websocket comes. ⏳

[JanCizmar]

Hi there! We've already implemented the new websockets, so we follow the Spring conventions now. There is no need to configure another server (it's running on the same port as the server does).

However, it's not prepared to be used by external users. We are using that for live changes in the platform now and will add more functionality to support notifying client about status of long time operations.

We will probably document it after we find out what are the needs for external usage while we will be working on the Tolgee CLI.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.