[v1.3.1] Roblox-RTC - a real time two-way communication module

[littleBitsman]

Roblox-RTC

Roblox-RTC is a real-time communication module between Roblox servers and a NodeJS backend server.

GitHub · NPM Backend Module · Roblox Module Docs

Features

• Send data from Roblox to your backend (any JSON-serializable type)
• Send a message to a server with a matching JobId and/or PlaceId.
• Broadcast a message to all servers.
• Get players in a server.
• Get player data (name, display name, etc.) from a player in a server.
• More coming soon!

Quick Start

Examples

See examples in the GitHub repository in examples.

Links

Roblox Module
NPM Backend Module

Upcoming Features

• serializing Roblox-native types like Vector3 and UDim2 (in progress)
• sending data larger than 1024 bytes (the 1kb limit in place with Messaging Service) to Roblox
• support for other server languages (Python, Java, C/C++, C#, etc.)

Why use this over HTTP long polling?

HTTP long polling is the way that many open-source two-way communication scripts/modules work. In HTTP long polling, a Roblox server sends an HTTP GET request to a backend, which the backend hangs (doesn’t respond until timeout) until there is data available for the Roblox server to get, which it sends. Long polling is very inefficient when it comes to data limits, especially if you have a high volume of HTTP requests outside of the long polling script.

How does the module work?

Send data to Roblox:

Data is sent to Roblox via the Open Cloud Messaging Service API.

Send data to backend:

Data is sent to the backend via regular HTTP POSTs, using an API key sent over Messaging Service along with some hashing algorithms in order to make it harder (maybe impossible) to impersonate a Roblox server.

Note

Any datatypes exclusive to Roblox like Vector3 are not JSON-serializable, and therefore cannot be sent either way over the module unless you manually serialize it into an object and deserialize it upon receipt. The same goes for metatables (all metatable information is lost upon sending a table).

License

This module is licensed under the GNU AGPL v3.0 license.
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Affero General Public License for more details.

Feedback

Any feedback would be greatly appreciated, whether it is a feature request or criticism.
(Let me know if there’s anything I should add to this post, it’s my first one. Also let me know if I’m not supposed to have a license, thanks!)

What do you think of this as my first community resource post?

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

Would you use this module?

• yes
• no

[bitsplicer]

Amazing, I’ll set this up with my websites API and begin using this in my games.

[littleBitsman]

[v1.0.2] Changelog:
Non-breaking changes:

• fixed a security vulnerability with cookies and CSRF in the NPM module - everything should work as normal; if anything starts to break please let me know!

[bitsplicer]

Just finished setup with this on my website!

[littleBitsman]

[v1.1.0] Changelog
Breaking changes:

• allowed the ability to decide whether the cookie is secure on the backend (see secureCookie in server creation option)
• the players object of Connections in the backend now returns an array of Player objects, see JSDocs for more info on that.
• setting the session store on the backend is now actually a thing

[littleBitsman]

[v1.1.1] Changelog
Changes:

• oops I forgot to build JS files, everything is back to normal
• see v1.1.0 changelog

[KadenBloxYT (Kaden)]

I hope there won’t be any breaking changes

[littleBitsman]

Don’t worry, there aren’t any that break anything except for the updates to the Connection.players object (see v1.1.0 changelog). If you don’t use Connection.players you’re still good to go! (Though I still recommend updating every time there is an update)

[KadenBloxYT (Kaden)]

This looks like an amazing resource by the way! I’ll recommend it to my developers if something like this is needed!

[littleBitsman]

[v1.1.2] Changelog
Non-breaking changes:

• couple of minor bugfixes

[Bakonowychlopak123]

@littleBitsman

Why use this over HTTP long polling?

HTTP long polling is the way that many open-source two-way communication scripts/modules work. In HTTP long polling, a Roblox server sends an HTTP GET request to a backend, which the backend hangs (doesn’t respond until timeout) until there is data available for the Roblox server to get, which it sends. Long polling is very inefficient when it comes to data limits, especially if you have a high volume of HTTP requests outside of the long polling script.

its legit same thing you are long polling players in the server

Roblox-PlaceId header is not needed because roblox already send placeid by default inside roblox-id header

you are using deprecated spawn and deprecated wait please switch to task.spawn and task.wait

you dont need ipairs you can just

for i,v in game:GetService("Players"):GetPlayers() do end

[littleBitsman]

@Bakonowychlopak123

its legit same thing you are long polling players in the server

Long polling is hanging requests for data that are outbound from Roblox (in Roblox context) to the backend and POSTing player user IDs to the backend is not an example of HTTP long polling.

My code uses wait and spawn once each, so I doubt it is as much of a problem as you think it is, but I have published the change to task.defer and task.wait.

There isn’t anything wrong with ipairs, but I have also changed the code to no longer use it since it actually looks a bit cleaner.

I don’t believe there are any issues with adding another header for the place ID, so I will leave it as is.

Thank you for the feedback.

[Bakonowychlopak123]

@littleBitsman

I don’t believe there are any issues with adding another header for the place ID, so I will leave it as is.

What i mean is that you dont need Roblox-PlaceId header

roblox already sends place id by default just check roblox-id header

[littleBitsman]

[v1.1.6] Changelog
Breaking changes:

• Added playerAdded and playerRemoving events on server side

Non-breaking changes:

• Changed when players are sent (on PlayerAdded and PlayerRemoving instead of every couple seconds)
• Minor bugfixes
• Changed the URL-matching pattern during validation

[littleBitsman]

[v1.3.1] Changelog:
Sorry for the bump but I’m actually updating this again lol

Changes (JS):

• Player objects are now their own classes and cache data to avoid excessive HTTP requests
• fixed Connection close event
• changed createId default function to crypto.randomUUID
• slightly changed how request validation works
• fixed sending data other than objects to Roblox
• added type specification for TypeScript usage on the data event

Changes (Luau):

• BREAKING: all data sent to Roblox will be the Data property of the table passed to any event callbacks and the message event callback. The Timestamp property will also exist on the table.
• custom events are now supported. Note that there are no efforts made to enforce any type casting for custom events.
• minor bugfixes
• fixed sending data other than dictionaries/tables to backend
• added custom event handling

In other news I plan on making libraries in other languages that support this as well.

JSDocs have been updated but the Luau docs on GitHub haven’t been updated yet.