Off late GraphQL workloads see wide adoption in enterprise workloads as GraphQL provides a consistent and flexible way for UI to consume data from the APIs. For API developers like me, seeing GraphQL servers abstracting away the data filtering and the access patterns associated with backend APIs is a complete paradigm shift. Traditional API design tasks, like data modeling, access patterns required to implement high-performance Data APIs, are still relevant when implementing GraphQL applications?
This talk will walk you through the learnings as a backend API developer building a hello world GraphQL application to implement a globally distributed GraphQL API for a real-world e-commerce application. We will look into scaling and resiliency required for building high-performance GraphQL APIs. Also, look into how database capabilities play an essential role in implementing a successful GraphQL application.
Transcription
Hello everyone. Thanks for joining. My name is Nikhil Chandrapa. I'm a software engineer at UbiDB. We are a distributed SQL company. I work in the drivers and ecosystem team of UbiDB, where we build integrations with popular developer tools. Of late, we are seeing a lot of interest in our community as well as from our users to build first-class support for GraphQL, right? If you do a quick Google Trends search, you will see GraphQL is gaining rapid adoption. For UX developers, GraphQL provides autonomy over querying the data. They are able to retrieve only the data they need, right? For us, being a database company, and also on a daily basis, we work with the backend developers and API developers. It made sense for us to understand the server-side concepts of a GraphQL architecture. The GraphQL server, which provides abstraction over the database for querying and mutating the data, and also a few other advanced features like pagination, filtering, eventing, right? We wanted to see how all these things fit in with the general REST API development that we generally see, right? So an API developer would understand the business domain. He comes up with the domain objects. He implements all the access patterns around them. We wanted to see how GraphQL server, how this all looks in the GraphQL server, right? For that, we wanted to use a real-world use case. We considered e-commerce domain, which is kind of well-known, and also it provides challenges for both UX developers, where they have to build an immersive, engaging experience, and also API developers, where they have to implement the APIs for the randomness of the traffic, right? So it's not always constant. It scales based on the user traffic. You have to scale up your APIs or scale down. And also API needs to be available all the time, right? This is a general microservices architecture you will see for e-commerce applications. You'll have a bunch of microservices, which exposes a REST API. And this REST API will be consumed by the UI applications or the UX developers to implement the UX apps, right? So it probably is a very quick sell for them to move to GraphQL rather than going through an entire docs. For us, during our evaluation, we wanted to see how well the GraphQL server can use the native database capabilities. Is it performant or not? And how easy is it to get to production, right? For that, we first wanted to use one of our simple tables, the product catalog. It doesn't have a complex access pattern. You get the product ID in the request and you send back the product details, right? It was a quick win for us. If you see from this complex JSON object that was being sent on the response, now GraphQL clients or the UX applications can only retrieve the data they need. Once we dipped our toes in the water, we felt comfortable with the GraphQL applications. So we wanted to have a much more complex table or the dataset coming to the picture, right? We took product ranking, which has a few things going on there. You have to filter the data based on the category and also sort it based on the ranking. So some of this happens on the database and few of these filtering is also happening on the API layer. One thing we quickly understood was any crud against these tables is super easy and it's fast. It leads to a faster prototyping where UX developer, you need not do back and forth with them. As in when we were bringing more tables, we soon realized like building all these domain mappings and the resolvers is kind of a complex task. It's not something you can have a couple of spins and you'll have a robust GraphQL server, right? So that's where we kind of wanted to pivot to use some of the popular open source and GraphQL server implementations out there. So we kind of pivoted from that to use the open source tools. In our research, what we kind of found out was all these tools have first class support for subscriptions, right? First class support for event based systems using GraphQL subscriptions. We wanted to use that. So in our iteration two, we kind of wanted to use GraphQL subscriptions. So we use it for a order management system where you want to track all the user orders and the status for them. We were super, this kind of solves a lot of issues, right? You don't have to pull for the data. Whenever there's a new status update, you kind of get the notification. Next thing for us to determine was whether it can handle the scale and the SLA requirements for that were currently there on the API. For that, we went ahead and benchmarked the GraphQL subscriptions. We are able to scale to the SLA requirements we needed. And we are super happy. We are super happy with that. And the next thing is in a cloud native application, everybody will ask is like how resilient your apps are. Is it able to like, as in when you move to the cloud, it becomes super essential for us, for you or anyone of us to build an application, which doesn't go down if there is a cloud outage or a region outage, any of such things, right? So next step, what we did is we took the GraphQL servers and we kind of deployed it with a stretched gigabyte DB cluster where we are able to do resiliency tests by taking out a region and taking over entire region or a few machines in the region. And that provided us enough confidence on taking it to production. So we believe along with GraphQL being, GraphQL kind of simplifies the feedback loop between the API developer and the UX developers. And also it becomes very powerful when it's able to use the capabilities of modern cloud native applications. That's it, folks. That's all the talk I had today. If you have any questions, please feel free to ask this question in the live Q&A. Thank you.
