Treasure reduces subgraph sync times by 50%
Treasure developers were seeing slow and uncertain syncing times, as well as frequent data lag. Switching to Satsuma helped Treasure with both issues.
Summary
- Customer: Treasure is a decentralized gaming ecosystem on Arbitrum connected through the MAGIC token and composable NFTs.
- Problem: Treasure developers were seeing slow and uncertain syncing times, as well as frequent data lag.
- Solution: Switching to Satsuma cut Treasure's indexing times from 4-7 days down to 2 days, and reduced data lag by 80%.
- Impact: Treasure developers waste less time waiting for indexing and ship features faster. In addition, Treasure users see faster website load times.
Get started today
If you have a subgraph or are looking for a reliable indexing solution, get started here!
Full Interview with rappzula
Can you give me a brief overview of what Treasure does?
Treasure is a decentralized gaming ecosystem with a community of builders creating games on the Arbitrum blockchain connected through the MAGIC token and composable NFTs.
What is your role at Treasure?
I’m a full-stack engineer, focusing mainly on front-end and subgraph development.
What are your near-term priorities? What products are you building right now?
Last year we released an automated market maker for our ecosystem tokens called MagicSwap, and we’re currently focused on building it up to support NFT pools. A lot more on this effort can be found on our blog: https://treasuredao.substack.com/p/magicswap-the-first-amm-with-universal
What were the problems you were facing before Satsuma?
We faced a ton of uncertainty around our subgraphs, particularly around syncing times - both full resyncs and just keeping up with the block head. Some of our subgraphs would take 4-7 days to fully resync, and it was a bit of a dice roll to know whether or not it was going to take even longer.
How did those problems impact Treasure? Why did they matter?
For us, uncertainty around subgraph syncing times meant uncertainty about feature development and releases. If you are working on a new feature and you don’t know how many days it will take to resync your data source, it’s difficult to estimate release dates and be able to promise features to the community. This also meant we’d often cut corners or implement hacky solutions to avoid the need for full resyncs, and in the end we would not be delivering the exact product we wanted to build.
Why didn’t other solutions work for you?
We wanted to stick to the subgraph technology for a few reasons, including its open source nature and its strict adherence to on-chain event processing. Many of our current products are built with subgraph-powered backends and switching to a new technology or homegrown APIs would have required too much developer resources focused on somewhat tedious tasks, instead of allowing us to keep working on what we love.
Why did you choose to switch to Satsuma?
- Ease of transition - Satsuma works out-of-the-box with the dozens of subgraphs we had already built, and after going through a trial period, we saw that no development work would be required to rebuild them.
- Managed service - we did not want to be in the business of running graph nodes and keeping developers on-call to troubleshoot and fix issues when downtime occurs. Satsuma’s managed service allows us to not worry about these details, and continue to focus on building our products.
- The team - Jonathan, Dan and team have been a pleasure to work with not just as a vendor, but as technology partners as well. They are always accessible and willing to help us with whatever questions we throw at them.
What is your favorite feature on Satsuma?
The metrics and performance insights are a couple of my favorite features on Satsuma because they really help us figure out where there are bottlenecks in our syncing processes, and I just see a lot of potential with these features being able to continue evolve and make sure that we’re building the most performant services possible.
How has using Satsuma impacted Treasure?
We have spent a lot less time waiting for subgraphs to sync, debugging issues, and troubleshooting downtime, which means we’ve been able to spend more time building our products. That alone is a huge win for us as developers, and the positive reviews from our community noticing faster sync times and snappier products is just an added bonus!
We’re also pleased to have Dan and Jonathan as technology partners as we all collectively try to keep improving and build the most performant blockchain indexers.