Going from Zero to Building Multi-Region GraphQL Applications

Hello everyone, thanks for joining, my name is Nikhil Chandrappa, I'm a software engineer at UgerbyteDB, we are a distributed SQL company. I work in the drivers and ecosystem team of UgerbyteDB, 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 drive. If you do a quick Google Trend search, you will see GraphQL is gaining rapid adoption. For UX developers, GraphQL provides autonomy over creating 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 GraphQL architecture.

The GraphQL server which provides abstraction over the database for creating and mutating the data and also a few other advanced features like pagination, filtering, eventing. We wanted to see how all these things fit in with a general REST API development that we generally see. 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 graphQL server. For that, we wanted to use a real world use case. We considered e-commerce domain, which is well known. And also it provides challenges for both UX developers where they had to build an immersive, engaging experience and also API developers where they have to handle the, or where they have to implement the APIs for the randomness of the traffic.

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. This is a general microservices architecture you will see for e-commerce applications. You'll have a bunch of microservices as exposed as a rest API, and this rest API will be consumed by the UI applications or the UX developers to implement UX apps. So it probably is a very quick sell for them to move to graphQL rather than going through entire docs. For us, during our evaluation, we wanted to see how well the graph qL 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 are the UX applications can only retrieve the data they need. Once we dipped our toes in the water when we felt comfortable with the Graphql applications. So we wanted to have a much more complex table or the dataset coming into the picture. We took the 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 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 have to have robust GraphQL server. But that's where we kind of wanted to pivot to use some of the popular open source and GraphQL implement 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 even based systems using GraphQL subscriptions, we wanted to use that. So in our iteration two, we kind of wanted to use GraphQL subscription. 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.