Roboat - A Roblox API Library For Rust

Resources Community Resources
#1

Quick Links

Why?

When I was developing Roblox tools in Rust, the biggest issue was a lack of (maintained) libraries for the Roblox API. After roughly half a year of creating my own Roblox tools with the raw HTTP clients available in Rust, I decided to make a Rust library for the Roblox API for me and everyone else to use.

Description

This is a Rust crate (library) used for interfacing with the Roblox API.

This crate is heavily focused on documentation. Every Client method (used for sending requests to the Roblox API) includes documentation and at least one example. The majority of methods have at least two examples (one doc example and one full binary example). The full documentation, along with quickstart examples, and an API coverage checklist, can be found here.

In an attempt to make the crate easy to use, the Client (used for making all requests to the Roblox API) is built in a way that abstracts away synchronization primitives from the user (types such as Mutex and RwLock). This makes it easier for the user to make requests in parallel from the same Client without all of the trickiness that comes with Rust async.

Disclaimers

Note that in this crate interfaces are not exactly 1:1 and some unnecessary data returned from endpoints is removed and some broken URL parameters are not provided in arguments.

As this project is young, it is also still in early development. The Roblox API is not fully covered but I am working on adding what I can over the summer. The crate’s APIs may also have breaking changes across minor versions until the first major version is released (v1.0.0).

This crate is also open source and is open for issues and pull requests.

Syntax Example - Fetching User Data

// Replace this value with your own roblosecurity token.
const ROBLOSECURITY: &str = "your-roblosecurity-token";

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = roboat::ClientBuilder::new()
        .roblosecurity(ROBLOSECURITY.to_string())
        .build();

    let robux = client.robux().await?;
    let user_id = client.user_id().await?;
    let username = client.username().await?;
    let display_name = client.display_name().await?;    

    println!("Robux: {}", robux);
    println!("User ID: {}", user_id);
    println!("Username: {}", username);
    println!("Display Name: {}", display_name);

    Ok(())   
}
5 Likes
#2

I think this is a good idea, I plan on making a .TOML file configurer for VSCode, when you import a model link, it would get the information, so this is good for rust users who want to interact with roblox, but we might have to add the cookie

1 Like
#3

What would one be using this for?

1 Like
#4

Anything that uses the Roblox API. For example, I made a group ranking bot based on age for my friend using this library (can be found here).

#5

Finally, a reason to start re-learning Rust again.

1 Like
#6

How complete is this wrapper? Just wondering as I’ve been building a API wrapper for Node.js
Does it have support for realtime.roblox.com? Built-in caching? etc…

Unfortunately, even if it’s written in Rust, it will be slow. Roblox API response times are sluggish, my wrapper takes 3 seconds max to sign in, validate it’s token and generate a CSRF token.

1 Like
#7

It’s not too complete, most of the time spent is on testing and documenting the api and its quirks. A list of what the library can do is on the front page of the docs.

I actually kinda forgot about caching, I’m glad someone mentioned it here. I may actually work on that tonight because of that.

The “high performance capable” part of the library refers to its ability to easily (for rust) and performant-ly make multiple requests in parallel across threads/tokio tasks. Personally when using js I got too a point where stuff started to break down when too many requests were being made. Using the rust version allows me to have (potentially) the fastest wrapper given that Rust is built in a way that allows for the bare minimum amount of data to be synchronized between threads (using stuff like Mutexes)

Edit: I did a quick sweep and it doesn’t look like there’s much http-level caching (I did a quick sweep of roblox with a browser debugger and didn’t see any 403s). Other than that, caching is left to the user so they can decide how important getting current, non-cached data is

#8

Nice!
I’ve been a bit lack luster with my wrapper at the moment as I’ve been wanting to move everything to TypeScript due to the way I import modules into the Client class.
If you have any time at all, tell me what you think just based on the donks.

The main things I cache in my wrapper are profile pictures, spammy API calls that almost never change and more. All of it can be disabled via a client argument.

The reason why I made my own wrapper is because of how frustrating noblox.js is, it could barely keep short-polling for group wall posts. My wrapper managed to stay running and updating my Discord server with new wall posts constantly, for weeks straight.
With the help of a friend, we managed to get realtime.roblox.com working and we could get a websocket connection to the endpoint that handles updating Friends activity on the home page.

1 Like