Native GraphQL, GraphQL as a Database Query Language

Rate this content
Bookmark

GraphQL was originally not designed as a database language yet it's quickly becoming a popular choice to interact with databases. What if databases natively support GraphQL default? What are the advantages of native GraphQL support? How is a GraphQL query handled behind the scenes in FaunaDB and what database guarantees does such an approach provide?

8 min
02 Jul, 2021

Video Summary and Transcription

The Talk introduces NativeGraphQL, which translates a GraphQL query into one FQL query, offering advantages over traditional GraphQL resolvers. The VANA approach to NativeGraphQL avoids the n plus one problem and provides several benefits. FQL is a good fit for NativeGraphQL as it solves the tree traversal problem and offers the same advantages as the rest of the native FQL language. Native GraphQL also provides multi-region scalability, ACID, and transactionality out-of-the-box.

Available in Español

1. Introduction to NativeGraphQL at VANA

Short description:

Hi everyone, I'm Brichts, I'm super excited today to talk at the GraphQL Galaxy conference. Today I'm going to talk about NativeGraphQL or GraphQL as a database query language. NativeGraphQL means that a GraphQL query is going to translate into one FQL query. This one-to-one translation has huge advantages. Let's take a detour and understand how GraphQL resolvers work. GraphQL resolvers work by mapping fields to functions. However, this approach can lead to the n plus one problem, where multiple database calls are made. To solve this problem, batching and caching techniques can be used. But these solutions introduce complexity and have limitations. The VANA approach to NativeGraphQL avoids these problems and provides several advantages.

Hi everyone, I'm Brichts, I'm super excited today to talk at the GraphQL Galaxy conference. I'm Databrichts on Twitter, I work for the Vana database and today I'm going to talk about NativeGraphQL or GraphQL as a database query language.

Now if we talk about Native GraphQL at VANA what does it mean? Well, first of all, we have a VANA query language which we call FQL and basically NativeGraphQL means that a GraphQL query is going to translate into one FQL query. That one-to-one translation has huge advantages, so first of all, you might wonder which advantages we'll look into that, and question 2, why doesn't everyone do this if there are such advantages?

To answer these questions, we actually have to answer other questions like how do GraphQL resolvers work? So let's take a detour. How do GraphQL resolvers work? Well, typically if you have a query like this with getList, toDo, title, every field in here, like getList and toDo's and title are fields, will map on a function. So getList will be a function and that will delegate to the toDo's function, that will delegate again to the title function, for example, to the title attribute. This is a resolver chain, which is a chain of functions, but it's actually more of a resolver tree of function calls.

Because here there's one function that calls n functions. And if we turn this around, we get n plus 1 and it's basically a problem. And this is actually called the n plus one problem. That's why I turned it around. And when is this a problem? Well, basically, if you're going to call the database for each of these resolvers, because then you get n plus one database calls, which is not efficient. So question four, how can we solve the n plus one problem? Well, there are multiple solutions. Solution one is batching or n in-memory caching. So in that approach, we're going to hook into these functions, for example, todo.titles, and just wait until all the todo.titles are called and then combine these. So instead of going to do n calls for these todo.titles, we're going to do one call. So in total, two calls. That's batching and that's often combined with caching. So if a similar call comes in, then instead of going to the database, we can go to an in-memory cache, so we don't hit the database at all.

A very popular implementation is Facebook's data loader, which you can just plug in on top of your resolvers and it will handle it for you. However, there's a problem with this solution as well. It should in fact be a last resort. Well, why? Your data is no longer live. It's no longer consistent. You can't apply it on everything. You can't patch everything. So you will have still multiple calls. What about caching validation, memory pressure that you have to do deal with suddenly. So it introduces complexity. So the first question, which advantages that FANAS approach provides? Well, it doesn't deal with these problems because it doesn't have these problems.

2. Advantages and Fit of FQL in Native GraphQL

Short description:

It is live by default. It is consistent. It requires no extra work. And there is no memory constraint problem. It just works out of the box. So you don't have to do this. The problem here is that what joins solve, which is a join between two tables, is a different problem than what the actual problem is, which is more like a tree traversal problem or a graph-like problem. So joins are maybe the wrong tool for the job. There is an implementation, a very impressive implementation, called JoinMonster, which actually comes from the problem they're trying to solve. A monster join that might be the result of a GraphQL query. That's why FQL actually fits the problem. Because we have the same advantages as the rest of the normal native FQL language, we can actually combine that with FQL and use FQL for the flexibility and power and GraphQL for the ease of use. We have multi-region out-of-the-box, scalability out-of-the-box, we have 100% ACID and transactionality out-of-the-box. So that's what native GraphQL is.

It is live by default. It is consistent. It requires no extra work. And there is no memory constraint problem. It just works out of the box. So you don't have to do this.

Solution two, generate one query, which is what FANAS does behind the scenes. But why doesn't everyone do that? If you would look at SQL, for example, and let's say we would select a star from lists where ID is equal to something, then we would go to the to-do calls and do the same and try to concatenate that query. Of course, we'll have to do it for multiple to-do's, so we'll end up with a join. And the problem is if we go deeper like that in a GraphQL traversal, we might end up with a lot of joins. Now, not only is it super complex to analyze this query and then generate SQL from it and then transform the results back to a GraphQL format, it might also be inefficient depending on the joins. You might overfetch a lot and then have to throw away things. And then how are we going to paginate this? Limit 100 might not be exactly what you're looking for. So the problem here is that what joins solve, which is a join between two tables, is a different problem than what the actual problem is, which is more like a tree traversal problem or a graph-like problem. So joins are maybe the wrong tool for the job.

So there is an implementation, a very impressive implementation, called JoinMonster, which actually comes from the problem they're trying to solve. A monster join that might be the result of a GraphQL query. If you look at the work involved, you can see that it's a complex problem to solve. That's question 4, how can we solve the n plus 1 problem, so the two solutions. That brings us back to question 2, why doesn't everyone do this? Well, we just showed it, the query language might not fit the problem or the execution plan might not fit the problem. Then of course, why does FQL fit the problem? Well, we do it quite differently because it's a different query language and has quite graph-like properties. If we would look at the same query, we would start by getting a list with match, index and the list ID. We would immediately wrap it in paginate, so we actually will have pagination on every level, and very sane pagination with an after and before cursor that is always correct. Then we just map over the results of these lists and we would call a function. That's actually just like a normal programming language, where you would just map over something and then call the function. In that function we can do whatever we want and if we look at the get to dos there, well, what is this? It's just a JavaScript function because I'm using the JavaScript driver for FQL, where we just throw out more FQL. Pure function composition. Then we see the same pattern, paginate and map. So we have the second level of pagination immediately and map and again a function that will be called. This is actually a graph-like reversal that we're just implementing in FQL. Because that's possible, it was super easy for Fana to implement that one-to-one translation from GraphQL to FQL. So what is actually happening here, if we look at the query execution, is that we map get over all the lists, then we paginate that immediately and then we just continue map getting and paginate on every level. There is no monster join problem because we do it completely different, so we don't have to solve the problem. So question five, that's why FQL actually fits the problem. Back to question one, which advantage does that bring, because we have mentioned advantages but there are others. Because we have the same advantages as the rest of the normal native FQL language, we can actually combine that with FQL and use FQL for the flexibility and power and GraphQL for the ease of use. We have multi-region out-of-the-box, scalability out-of-the-box, we have 100% ACID and transactionality out-of-the-box. So that's what native GraphQL is.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura