Adopting GraphQL
Just like implementing any other cool technology, adopting GraphQL into your organization is a big task (and it comes with a big risk). Luckily, we were able to adopt it incrementally. At Kadira, we use GraphQL in many places, including our internal APIs, to improve customer support.
This is the story of how we adopted GraphQL into our development stack and dev culture.
The Benefits
Usually, GraphQL is marketed as a way to fetch data efficiently for client-side apps. However, that’s not why we use it. We primarily use GraphQL for server-to-server communications. We use GraphQL because of its schema, in-code documentation, and tooling.
🐵: Can you tell us a bit more about this?
At Kadira, we have a set of microservices talking to each other to implement Kadira alerts and similar services. We used DDP-based APIs, and the documentation was hosted on GitHub as a set of markdown files.
When it was time to use those APIs, we had to read through the documentation and try the code manually. That process slowed down our development process, and no one really liked it.
We started thinking about GraphQL as a solution to this problem.
🐵: Interesting! How did you get started with GraphQL?
Baby Steps
Last November, we decided to rewrite our alerting system because it was buggy and it produced a lot of false-positive alerts. It used a small subset of Kadira APIs that we used internally.
We migrated those APIs into GraphQL. I first implemented a few GraphQL types and integrated the GraphiQL IDE into the API. Then I introduced it to the team.
As soon as I introduced GraphiQL, everyone loved it.
Read the above sentence carefully. It wasn’t GraphQL they loved, it was GraphiQL.
GraphiQL is the in-browser IDE for GraphQL. It has a built-in documentation explorer, auto-completion, and many other cool features (even “CMD + D” multi-word selection).
Then, our team started playing around with GraphQL and implemented those APIs.
The project was a success. We launched our new alerting system within a month thanks to GraphQL and GraphiQL.
🐵: What happened next?
Kadira Genie
We began having initial discussions about Kadira Genie. For that, we were planning to use AWS lambda. Inside the lambda functions, we wanted to access almost every part of our API.
That’s when we decided to migrate our entire API into GraphQL. We completed the migration in less than a month. After that, we started using GraphQL inside AWS lambda using Lokka.
At that point, everyone on our team started to see the real benefits of GraphQL. With GraphQL, we never needed to read the documentation to use our API. We even didn’t need to read GraphQL’s in-code documentation.
GraphQL’s schema awareness and GraphiQL’s auto-completion helped us interact with our API without referring to the documentation.
With GraphQL, we could simply stop writing API documentation or reading it. I think that’s the dream of every developer :)
🐵: Cool. So, you are now using GraphQL everywhere at Kadira.
We Use GraphQL When We Need It
Nope. We don’t use GraphQL everywhere at Kadira. For example, we don’t use it for the Kadira UI. We could use our new GraphQL API for that, but our current system works pretty well. Re-implementing it with GraphQL doesn’t give us any advantages.
🐵: What are you guys going to do next?
GraphQL and Kadira
We have a great GraphQL endpoint for the data we collect at Kadira. We are working on making it available to our users.
We are also planning to build a reporting add-on for Kadira, and we are planning to use GraphQL for that. That’ll be our first client-side GraphQL project, and we have some big plans for it.
Finally
GraphQL simply makes APIs better. For us, the benefit was not GraphQL’s performance but the development experience it brought to the table.
If you adopt GraphQL incrementally with your product or company, you can get really good results, and I think everyone on your team will love it.
Follow KADIRA VOICE for more articles like this.
