We’re excited to announce that WebSockets are now available within Studio! WebSockets provide a persistent, bidirectional communication channel, allowing your plugins to connect to external servers for efficient, real-time data transfer. We hope this will streamline building integrated development tools and plugins, such as real-time syncing, live debugging and language servers.
How to get started
Since WebSockets use the same WebStreamClient interface as Server-Sent Events, you might already be familiar with the following steps:
Use CreateWebStreamClient() function to create a WebStreamClient. Make sure to specify the WebStreamClientType as WebSocket. In the Url field, specify the url or port of a WebSocket server.
Define your logic for handling streamed events (e.g., onMessage, onError) and connect those functions to the WebStreamClient.
To send data to the server, invoke the Send() method.
Sample Code:
local function handleMessage(message)
print(message)
end
local ws_client = HttpService:CreateWebStreamClient(Enum.WebStreamClientType.WebSocket, {
Url = "ws://localhost:8080"
})
ws_client.MessageReceived:Connect(handleMessage)
ws_client:Send("hi")
We can’t wait to see what kind of development tools you build with WebSockets! As always, please share your feedback and questions in the comments.
Roblox Creator Services Team
FAQ:
When should I use WebSockets over Server-Sent Events?
SSE connections are more lightweight, but are limited to one way communication from the server to the client after the initial request. They are ideal for use cases when the server doesn’t expect an immediate response, such as live notifications or streaming LLM output.
WebSockets are more suited for use cases that require real-time interactive communication. Some use cases are real-time syncing and live debugging.
Can I use WebSockets in-experience?
Just like Server-Sent Events, this feature is restricted to Studio only. Any CreateWebStreamClient() requests made in a live experience will be blocked.
As a reminder, while you can use WebSockets within Studio, make sure to remove any CreateWebStreamClient() calls in your code before publishing.
How long can WebSocket connections last?
WebSocket connections can last indefinitely. Any server pings will be automatically responded to with a pong frame.
How many WebSocket connections can I have active at once?
You can have up to 4 WebStreamClients at once. The connection pool is shared between SSE and WebSocket clients. The purpose of this limit is to not block all 5 of the HTTP requests allocated to plugins with long-running requests. We are actively working on raising this limit.
This is awesome. Will we see anything regarding the internal React DevTools being worked on? If I recall correctly, it was blocked for public use because WebSocket support wasn’t public yet.
Thanks all for the feedback! We appreciate your excitement and understand your desire to see this feature enabled for experiences.
To help us get there, could you share how you would plan to use WebSockets in live experiences? Concrete use cases would be really useful, including what kinds of servers you plan to connect to.
Personally, I’m planning on making a Discord-based moderation function for my game using WebSockets to know exactly when to take an action and on who. I made a prototype using Python based on polling, but the code is sloppy and it takes too long to poll events and respect my servers so I’m holding out until I can simply connect to a WebSocket. I’m also planning an in-house analytics solution using sockets, but I haven’t prototyped that yet.
This would be incredibly useful for external moderation and liveops tooling, for example keeping in contact with a central server to allow for efficient monitoring, control, and moderation of servers across experiences in one central place using one central methodology of communication. Existing methods are inconvenient or not ideal (long polling, using messagingservice/datastores over Open Cloud alongside httpservice). This would alleviate the need for these, in my opinion, janky solutions.
Hi, I have a few practical use cases here and would LOVE to see WebSockets exposed to live experiences!
I would use WebSockets to connect to my personal domains in order to facilitate real-time two-way communication across experiences on Roblox in a way faster than the currently required “GET polling” can provide and without using up bandwidth of Roblox API’s like Open Cloud; this would be a gigantic boon for an “HTTP-like” communication layer I am creating for a custom OS I’m building from a virtualized CPU&VM in Roblox.
I would use WebSockets to connect to - again my personal domains - in order to facilitate bidirectional communication between our Administration system and our Web Panels/Discord bots, in order to allow things like executing moderation commands in-game or starting in-game events without forcing moderators/developers to start up Roblox every time they get a report and need to ban someone, or to allow developers to remotely extract the F9 logs of players in our game for analysis and on-demand error debugging when a user reports a bug in the Discord(without needing the user to “understand” F9), etc.
It’s the combination of using MessagingService and DataStores over Open Cloud for external to experience communication and HTTPService for experience to external communication to achieve two way communication is what I find janky.
Players across all servers being able to instantly sell and buy items from other players, very short delay and high reliability (necessary)
Globally synchoronized event
Recently update events (eg. admin abuse) have become more and more common, and frequently I saw devs having to run events multiple times because not all servers received a message
you may generally consider using MessagingService, which I understand is useful.
however I had some bad cases with it:
unreliability - not all servers received a message (which could be really bad if I’m disabling a game-breaking future for all servers)
size of message too small - 1KB has not been enough for all my cases (which led me to use it with DataStore to send large data)
that being said, if MessagingService became highly reliable and supported much bigger messages I would gladly use it!! hovewer I would still like the option to interact with my own WebSocket server, in which I could safely rely
