Splits.io is a website similar to Pastebin or GitHub Gist, but for splits generated from speedruns rather than text or code. It's written in Ruby on Rails.
Splits.io supports uploading splits from any timer that supports the Splits.io Exchange Format plus many proprietary timer formats like LiveSplit, WSplit, Llanfair, and more. A full list of supported timers can be viewed in the FAQ.
For full API documentation, see the API readme.
Splits.io runs on Docker, which makes it easy and consistent to set up and run on any machine despite any unusual dependencies. The one downside is that you must first install Docker!
- Docker
- Docker Compose (Mac and Windows include this in the Docker install)
The first time you run Splits.io with Docker is the best, because you'll have time to get a coffee! Yum! After the first run, it will be much quicker.
makeOnce the output looks settled (you should see * Listening on tcp://0.0.0.0:3000), you're good to go! Access
localhost:3000 in your browser. The first page load after a new build may also take a minute.
Splits.io accounts are built on top of Twitch accounts, so if you want sign up / sign in to work, you will need to register a Twitch application at dev.twitch.tv/dashboard. Use this redirect URI when asked:
http://localhost:3000/auth/twitch/callbackTwitch will give you a client ID and a client secret. Put them in .env in the same format as .example.env. Then run
source .env
make buildbefore starting the server again and you're set!
(If you want to do the source step automatically in the future, use something
like autoenv.)
If you're having trouble getting Splits.io running at all using the above instructions, please make a GitHub issue so we can work it out! Even if you think it's a silly issue, the fact that it's happening to you means we haven't ironed out everything (even if the only thing preventing you from setting up is better documentation!).
If you have the app up and running but are looking for insight into debugging your own changes, you can access a Rails console inside the Docker container with
make consoleIf you use binding.pry anywhere in the code, once you hit the breakpoint specified use the command
make attachin another terminal window to attach to it. To detach, make sure to exit the debug session then use the docker
attach escape sequence ctrl + p then ctrl + q.
If you need to attach to a container other than web, specify a container with the syntax
make attach container=workerTo run tests from inside the Docker container, use
make testTo run only specific tests, use
make test path=spec/path/to/test/file/or/dirWe use Rubocop for code cleanliness and styling. To run it against changed files, commit your changes and run
make lintSplits.io utilizes a few libraries for profiling our code.
Rack Mini Profiler is used to find major slowdowns in the code through the use of the badge in the top left corner of the browser window. There is also a slew of different URL paremeters that you can use to get more detailed information about various aspects of the request. Details of these are explained in the readme for RMP. To get more detailed information about how code will perform in a production like environment, run
make profileto boot the app in the profiling environment, which has most of the production flags toggled on.
DerailedBenchmarks is used to test memory over lots of requests. The commands that can be run are detailed in the readme for DB. When you have a command you want to run, use the make task like so with the options that you need
make derailed env="-e TEST_COUNT=5000 -e USE_AUTH=true" command="exec perf:mem_over_time"The env flag is optional, so feel free to leave that blank if you have no environment variables to set.
If you change the Dockerfile or Gemfile, you'll need to run
make buildto rebuild the Docker image for your changes to apply.
If you want to reset from scratch, you can run
make cleanwhich will run docker-compose down, resetting your local database and any Docker image builds.
Splits.io is built in Ruby on Rails, but has some help from other pieces of infrastructure.
Production
+---------------------------------------------------------------------------------+
| AWS Auto Scaling Group (usually at 1) |
+---------------------------------------------------------------------------------+ +----------------+
| AWS Target Group | | AWS RDS |
| +--------------------------------------+ +------------------------------------+ | | +------------+ |
| | AWS EC2 Instance | | AWS EC2 Instance | |-->| | PostgreSQL | |
| | +----------------------------------+ | | +--------------------------------+ | | | +------------+ |
| | | Docker | | | | Docker | | | +----------------+
| | | +------------------+ +-------+ | | | | +------------------+ +-------+ | | |
| | | | Rails (& worker) | | Redis | | | | | | Rails (& worker) | | Redis | | | |-------------------------\
| | | +------------------+ +-------+ | | | | +------------------+ +-------+ | | | |
| | | | livesplit-core | | | | | | livesplit-core | | | | |
| | | +------------------+ | | | | +------------------+ | | | |
| | +----------------------------------+ | | +--------------------------------+ | | |
| +--------------------------------------+ +------------------------------------+ | New file trigger V
+---------------------------------------------------------------------------------+ +------------+ | +--------+
| AWS Application Load Balancer |<--| AWS Lambda |<--| AWS S3 |
+---------------------------------------------------------------------------------+ | +------------+ +--------+
^ | Lambda tells Rails to parse ^
HTTPS | | WebSockets |
| V |
+------+ |
| User |--------------------------------------------------------------/
+------+ Upload run using presigned S3 POST from Rails
Rails will synchronously parse any unparsed run before rendering it, but the asynchronous Lambda job is the preferred way for runs to be parsed because it still catches unvisited runs (e.g. in the case of a multi-file upload via drag-and-drop).
In development PostgreSQL and S3 are also Docker containers (see docker-compose.yml). Lambda is not yet implemented in development mode.
Favicons are generated by Favicon Generator and its Rails gem. To generate favicons from the source image (public/logo-imageonly.svg), run
docker-compose run web rails generate faviconConfig for this generation is at config/favicon.json.
Splits.io runs Bootstrap 4 on a paid theme called Dashboard. Its license does not allow its source to be included in this repository; however there are three modifications we make to the source before producing the included final build. This is within the terms of the license.
- In
/v4/scss/variables.scss:- Change
$theme-colors[primary]to#489BE7 - Change
$theme-colors[success]to#6EE588 - Change
$theme-colors[warning]to#F5BA46
- Change
These new colors match those in the Splits.io logo.
If you find a security vulnerability in Splits.io, please email it to [email protected], as posting the vulnerability in public may allow malicious people to use it before it's able to be fixed.
Splits.io uses livesplit-core for parsing runs. The parser is located in lib/parser/*. To upgrade
it, run
make update_lscand commit the changes.
To generate run history charts Splits.io uses Highcharts, which requires a written license. Licensing is based on the honor system, so you do not need to enter a key anywhere. Highcharts is free to use for testing purposes.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
