We’re delighted that Tyk’s no-code GraphQL schema builder is turning heads in the tech world. But the path to innovation isn’t always smooth, as our Technical Director Jens and new Product Owner Agata are happy to reveal.
In the first of a series of blog posts that takes a deeper look at what the Tyk team really gets up to behind the scenes, Jens and Agata walk us through the perils and the pitfalls of building a no-code GraphQL schema builder.
What problem was Tyk trying to solve when it began developing a no-code GraphQL schema builder? Where did the idea come from and who are we helping with it?
Jens: I first began thinking about how to leverage the power of GraphQL with Universal Data Graph about three to four years ago and I realised a user interface to build GraphQL APIs could be something very useful.
I was the head of software development for an online German news website at the time. We had multiple teams – one built mobile apps, one built the website, getting content written by reporters from the content management system, and one dealt with real-time data such as that produced by the stock market or the sports industry. News websites have a lot of data flying around, all coming from different sources, in different languages, different protocols…
There were all these silos of data, with me stuck in the middle wanting to enable my teams to have access to all of them in a simple way. Four years ago, there just wasn’t a simple way to do this. So I was imagining having a GraphQL API that would allow me to use one query to go into all those data silos and get the data and then use it to build whatever I needed.
That capability didn’t exist, so I began thinking about how one might build such a graph. My initial thoughts were that it would need a user interface and the ability to configure all those data sources and somehow mash it altogether. That would provide my teams with a simple but powerful tool with which to query those silos. That’s the problem that I was looking to solve.
What did you initially think the solution would look like?
Jens: I didn’t know Tyk at that time. I was thinking initially of building something where you would define all of the data sources in code – a headless solution. It would be very flexible, dynamic and powerful but also entirely inaccessible for a lot of people!
The attraction for me was exploring how to mash all the data sources together – I wasn’t very focused on the user interface side of things initially. That side of the project came later, when we took it to some very smart UX people at Tyk and they came up with the user interface that we could add on top to make the tool available to a wider audience.
Was the transition from a very code-based tool to a no-code schema builder entirely user-focused, then?
Jens: Yes, absolutely. At Tyk, we have a lot of users who configure their APIs through the Tyk Dashboard, which is our graphical user interface (GUI). So it was a logical step to introduce a similar experience for Universal Data Graph as well.
If you look into configuring Universal Data Graph in depth, you have to write a 5,000-line-long JSON object with very difficult, complicated fields – and if you get one field wrong, it all breaks. So if you don’t have the user interface, it’s barely usable.
In basic terms, how does Universal Data Graph work?
Jens: At a high level, our Universal Data Graph GUI works by asking you first to define your GraphQL schema. That means you need to describe the landscape – the objects that exist in your universe. Let’s say, for the purposes of this example, that your universe has dogs, trees, houses and cars.
Next, you configure the data sources so that the universe knows where to get each of those objects. So it knows to go to one service to get a dog, to another to get a tree and so forth.
That’s Universal Data Graph, in a nutshell!
What were some of the problems you encountered when you built the GUI? What was your biggest headache?
Jens: I think the trickiest part was giving people the flexibility they need without making it too hard. We were already requiring people to define their schema and then attach their data sources to that schema, so it was already getting complicated, even for developers. Coming up with a simple, effective way of letting people configure the data sources to their schema was definitely the hardest part of the process. I still think we can tweak the solution that we’ve built – it works and it’s usable, but I feel like we can polish it with the next iteration to make it feel less complicated.
Before you launched the feature, who was involved in testing it?
Jens: Very early on in the project, when we had some rough ideas from our UX designer laid out on Miro boards, so we took those and we talked to the community about them, along with a few customers who were in line to be our early adopters of this feature.
We bounced ideas back and forth to understand how they could use a no-code schema builder, what kind of problems it could solve for them, that sort of thing. We invested quite a bit of time in ensuring that we were going in the right direction.
Is that process ongoing in terms of consultation and feedback?
Jens: We tend to blend vision-driven development with a lot of community engagement. Right now, for example, federation is a big topic in the GraphQL space. We started this work half a year ago and keep seeing queries about federation come up, so the feedback that we’re getting helps us know we’ve got the focus right for that.
Meanwhile, we always try to release things in a minimum viable style, then throw them open to the community. We have a lot of salespeople and solution architects who look at new releases too, so we get a lot of feedback and questions from a customer-facing perspective as well as the community perspective.
We use all this input to influence our priorities and shape what we’re working on.
Tyk is very innovative and is often the first to the post with new features. Is the no-code schema builder such a feature? And, if so, why hasn’t anyone else developed it?
Jens: There’s an enormous amount of competition in the GraphQL space. Universal Data Graph aims to solve integration problems for GraphQL users. I don’t see anyone competing with Tyk here because the initial investment to get this off the ground was, in my humble opinion, a very stupid waste of resources!
I spent two years building the core of Universal Data Graph as a side project, just because I was interested in it. That’s a very high bar to enter this market! If you don’t have this core capability and the people to evolve it, it takes a big investment to get into the market in the first place. After two years of working on solving this problem, I discovered Tyk and brought the idea to them. Now we have a full team behind it and we can grow it, but I don’t think it’s an easy solution to enter the market with. Which I guess is why nobody else is doing it!
We’re definitely super unique with Universal Data Graph, including the no-code schema builder. There are other solutions that aim to solve the same problems, but on a whole different level. Tyk’s solution is so simple and lightweight. Other solutions require the user to enter a whole new ecosystem and add a whole new level of complexity.
Were there any moments when you felt you had reached a complete dead-end with this project and couldn’t see a way forward?
Jens: I think the whole first year of working on it at Tyk felt like that! It was very hard to find people who were interested in the topic and super hard to find customers. It took almost two years before we found a customer who truly grasped the potential, then suddenly we had this major global tech firm who wanted to do an enormous deal. The sense of relief was huge!
More customers have come on board since then, so the wait was worth it.
Agata: I’ve not been at Tyk that long – I started here a month ago, so I still have quite a fresh perspective.
I’ve come into Tyk from a financial markets background; I’ve been working with a lot of companies that resell financial data. Once I understood what Universal Data Graph actually does, I realised that it is actually revolutionary. Looking at projects that I’ve worked on, where we’ve had to build microservices, and the overhaul of all the technical stuff put on top, with legacy databases and connectors… it took us two years to expose the data we needed to to our customers. Seeing what UDG is capable of, and how fast it can do it, it’s just remarkable.
Where do you think the difficulty lies in terms of explaining to potential clients how much they could benefit from the no-code GraphQL schema builder?
Jens: The one problem we have is that we need to find the real-world use cases – like the one Agata just mentioned – and use those to show people how it could help them. I think, without those, that we risk telling the wrong story. This isn’t about a GraphQL first approach; GraphQL is just the language we’re using here – it’s helper tool. The power lies in the simple integration patterns that we make possible. We need to tell stories like Agata’s to demonstrate that, to show companies that they could save (for example) a year of paying ten developers. That’s what we need to tell the world.
What is the most innovative part of the no-code GraphQL schema builder?
Jens: I think it’s that people who aren’t deeply technical can use Universal Data Graph and do some incredible, powerful stuff with it. We make integration appear simple: you write a schema, you attach a data source, you have a GraphQL API and you can talk to your services. Other solutions don’t enable you to go that far in five minutes.
The amount of time and money that businesses can save sounds immense!
Jens: Let me tell you something about integration. The stupid thing is, if you’re a shop and you have to integrate an API from Stripe, for example, even though the Stripe API is public and everybody can see how it works, the integration into your system is usually proprietary code. So you will never publish it anywhere and it barely has any value to anybody else, because it couples Stripe to your particular system.
All over the world, businesses are spending billions of dollars every day on projects that connect systems in this way, with all this proprietary code. We never share it, because it’s bound to businesses’ internal systems, yet all this code is doing the same thing.
How many people have glued Stripe to their system? Thousands. How often can we reuse the code they used to do so? Never. It’s such a huge waste of code!
The idea behind UDG is that we’ve developed that connector once, we’ve made it open source, and everybody can now just use that connector. They don’t have to reinvent that Stripe connector thousands of times. So it can save the industry a huge amount of resources and time.
Agata: And with Tyk they have the API management on top of that as well, so everything is integrated.
Is it exciting to be working on something that’s so fresh and innovative?
Jens: It is – and GitHub Copilot got me thinking about this while we were creating the no-code schema builder. GitHub Copilot uses artificial intelligence to read through all the source code available on the internet and processes it. Then, when you connect it to your IDE (the programme that you write programmes with) and type something, it suggests the code you might need. A lot of developers are afraid that this will cost them their jobs, but it really depends what you are writing.
I looked to see if Copilot could write Universal Data Graph, for example, and it couldn’t. Copilot can only read and suggest code that already exists. So if you’re writing something new, you’re on your own! That’s a very exciting feeling. We hit so many new problems along the way, but it’s so much fun to be working on a project like that.
What have your key learnings been from working on the no-code schema builder, and on Universal Data Graph in general?
Jens: Slice your work into smaller chunks and get more feedback! It’s like going on a trip to Mars. There are so many directions you can head in; it’s best to just take a few steps and then ask those around you what they think. Don’t run for kilometres in one direction and then find out that what you’re searching for is the opposite way. That’s been my biggest learning.
What are the benefits that the no-code schema builder is providing to Tyk’s clients who are using it?
Jens: We have a client who has a lot of Rest APIs, some of which are tightly coupled to database systems. They have different layers, with specialists for databases, specialists for APIs and so forth. They want to tape all their APIs together and use our GUI to combine them all, then make all of them available to the developers as one single endpoint. It’s the core UDG use case.
The impact? Making APIs more accessible to their developers.
Agata: And doing so without changing the structures of their teams, which makes everything so much simpler.
Thank you both for sharing your experience of building the no-code GraphQL schema builder. We look forward to seeing how it develops further over the coming months and years!
