Stellate Expands on GraphQL with Caching and Other Tooling
Since being open sourced in 2015, GraphQL has become a staple in the development community. Described as “a query language for your API,” the multifunctional server-side runtime technology’s main purpose is retrieving data. A worthy alternative to REST, GraphQL’s most celebrated features are its speed and ability to supply programmers with a full description of the data in their API. Though undoubtedly popular, those who use GraphQL on a large scale find it a bit lacking in certain areas.
Stellate, formerly known as GraphCDN, is attempting to address these specific pain points with solutions designed for GraphQL. Started in March 2021 by co-founders Max Stoiber and Tim Suchanek, Stellate’s GraphQL Edge Cache was built with the intent to “reduce origin traffic and boost performance by caching GraphQL queries.”
“The last company I co-founded,” Stoiber said in an interview with The New Stack, “we were using GraphQL and we ran into this issue where we had huge scaling problems. Our servers were crashing twice a day, I’d get paged every night and have to reset the servers. It was terrible.” He added that the root of the problem was having “a pretty bad database”.
Remember, GraphQL is neither frontend nor backend technology. It’s more the mouthpiece to communicate between the two, meaning you have to implement your own database and compile a stack that works best for your use case.
“At my last company, we had a very public use case — a forum,” said Stoiber. “Imagine I’m sitting in Vienna, Austria, and most of the world’s servers sit in Virginia and Ashburn, because that is where AWS has its one data center. So every time that I want to get data from a website, for example, I have to go all the way from Vienna, all the way to Ashburn servers to compute the data that has to go all the way back. What edge caching does is this: [If I’m in] Vienna the first time I’m going to load that data, I’m going to go through our location in Vienna, which won’t have the data yet. It will go to the origin in Virginia that will compute its thing and figure out what data to return. It’s going to send that data back to our location in Vienna, which will then store the data and then send it back to me. So that the next time somebody requests that data, it’s immediately there and can be sent back without having to go all the way to Virginia.”
Stoiber says that growing companies need caching to scale effectively, or they risk facing the server overload problems he did. “We knew that caching could solve all of our scaling problems, but the product didn’t exist. Nobody had built it yet.”
Why Does GraphQL Need a Supplement?
“Facebook built it, [but] it’s one layer of their architecture,” Stoiber continued. “They needed GraphQL in order to make sure that their client developers could get the exact data they needed from the backend. And the open source GraphQL is sort of like a thin slice of what they built, and it actually solves the problem they had really well, which is data access. Clients can access data really well via GraphQL because it has this centralized contract. Now, the thing is, they didn’t open source any of the other tooling they have because it’s so tied to their infrastructure. What happened is [that] all of the big companies that adopted GraphQL in order to make sure that they’re building great APIs ended up having to rebuild all of that tooling internally, because Facebook hadn’t open sourced it.”
“We started off with edge caching, but the underlying goal is to provide the tooling that the big companies have to everyone.”
I asked Stoiber if that means GraphQL is, technically, somewhat of an unfinished product. He swiftly objected. “GraphQL and the technology of GraphQL are finished. It’s just the surrounding tooling you need that [Facebook] has kept internally.”
“Everybody keeps rebuilding the same tooling over and over again,” he continued. “What we’re doing is looking at what problems do people run into once they’re running GraphQL in production, and which of those can be solved for everyone. We started off with edge caching, but the underlying goal is to provide the tooling that the big companies have to everyone.”
Improving the Base Model
Stellate offers GraphQL Edge Caching and GraphQL Analytics, in addition to its Performance Monitoring and Error Tracking tool. Compatible with any GraphQL backend, Stellate sits in front of your GraphQL and proxies all traffic. “We just ping your Graph API when we need to in order to get the data we need,” Stoiber says.
On the analytics front, Stoiber says that “the other piece of this is that the analytics help our customers cache better because we give people insights into how their caching is performing.”
Stellate’s GraphQL Performance and Error Tracking is another tool designed to simplify the developer experience.
“Our error tracking feature essentially just looks at all of the errors that come back from your GraphQL API and tracks all of them,” said Stoiber, “And then we’ve built alerts into the system, to where we can alert you in Slack or PagerDuty, and you can see what is going wrong, and you can debug it.”
GraphQL on a Worldwide Scale
According to Stoiber, Stellate is just getting started with expanding GraphQL. “We’re going to be building what we’re calling the global data graph. We’ve realized all these companies are using GraphQL to turn their data into a graph. Then each company sort of has its own siloed graph, where they’ve connected all of their data, but it’s not connected to anyone else.”
Stoiber says there is a huge opportunity that everyone’s missing. “For example, imagine if you’re in Salesforce and you have a customer. That customer is the same person that you have in Stripe who just paid their latest invoice. That person might also be the same person with that you have a shared Slack channel with your Slack account. If every company in the world had data exposed by GraphQL APIs, maybe there’s a way we can connect all of them together. And if we connect all of that data together, how much more productive would that make software engineers?”
Stellate’s goal is to create a connected data map that spans countries. Of course, in order for the global data graph to be truly valuable, more of the world’s data has to be exposed by a graphical API. In the meantime, Stoiber says he’s happy “making GraphQL more accessible for the businesses that need it.”