Speeding Up Applications with Virtual Threads, Github Actions, and GraalVM

I’ve been working on a personal project recently and thought it would be worth sharing here. For a while, I’ve wanted to create an application that analyzes your film taste using data from the popular film social media Letterboxd—sort of like Spotify Wrapped.

Unfortunately, Letterboxd doesn’t offer any public API, so I’ve developed a Java/Spring app to scrape data and make it easily accessible. It’s simple, but a few features make it worth sharing:

Virtual Threads to Improve Performance of IO Operations

By concurrently executing the HTTP requests that read from Letterboxd, the application performs and scales remarkably better. Here are some informal benchmarks I took:

• single-threaded version: 4.2 seconds for 10 requests; 20.2 seconds for 50 requests
• multi-threaded version: 1.4 seconds for 10 requests; 4.2 seconds for 50 requests

This means that the multi-threaded application is about 3x faster for 10 requests and 15x faster for 50 requests. I’ve had the chance to implement similar changes at work and have seen comparable results, often making legacy applications perform many times faster.

If you want to learn more about virtual threads (especially as compared to platform threads), I found this documentation helpful: https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html. And if you’re looking to learn about concurrency more generally, I can attest to the helpfulness of the standard recommendation, namely Brian Goetz’ Java Concurrency In Practice.

CI/CD with Github Actions and Google Cloud Run

I chose to use Github Actions as my CI/CD platform and Google Cloud for deployment, mainly due to my familiarity working with both at Deutsche Bank.

The part most worth mentioning is GraalVM, a JDK that enables the native compilation of Java applications, improving startup times, enhancing security, and reducing resource usage. I first learned about GraalVM thanks to Dan Dobrin , who presented on it during Deutsche Bank’s Google Cloud Day. His insightful talk covered lots of optimizations for serverless performance—many of which I didn’t have the chance to implement for this project but hope to explore further.

See For Yourself!

This project is more for fun than for perfection, so I wouldn't approach the code as any "best practice" reference, but I hope you find it interesting or learn something new (if you take a look). 🙏

Source Code: https://github.com/blinford/letterboxd-api

I’ve also decided to make the API publicly available, though with some limits and monitoring policies in place to ensure that it will be used responsibly 🙂 Note: I can’t promise that I’ll maintain the deployment for long, so I might stop hosting it at some point…

https://letterboxd-api-518859654353.us-east1.run.app/swagger-ui/index.html

If you don't know any usernames, try "dan" or find an account here: https://letterboxd.com/members/. The letterboxd-film-controller uses film IDs, so try "2001-a-space-odyssey" or take something from the /user/{username}/films endpoint.

Next…

I’m planning on making a post about the film taste analysis part of the project sometime soon, and I’ve also become rather enchanted by the Rust language recently, so that's in the realm of possibility too... 👀