GraphQL Everywhere

Rate this content

There's an old guard of developers that try to convince you that GraphQL only belongs on the front-end. Join the resistance and see the true power of GraphQL as the ubiquitous and agnostic tool that it is for data normalization. From event-driven, serverless patterns, to low-code platforms, we'll talk about the why and how of freeing data access with GraphQL.

20 min
08 Dec, 2022

Video Summary and Transcription

GraphQL is a preferred tool for solving the complex data access challenge in the current ecosystem. It allows merging diverse sets of data into a single API, reducing overhead and providing reusable patterns. GraphQL's purpose is to define data dependencies and it aligns with accessing complex data models and federated data dependencies. Hasura introduces the GraphQL data specification, a powerful tool for defining data needs and creating APIs. They are actively hiring and encourage users to try out their alpha release and provide feedback.

Available in Español

1. Introduction to GraphQL and Hasura

Short description:

Hi, and welcome to my talk, GraphQL Everywhere. There will be a number of things to discuss or think about regarding GraphQL's usage. I am Developer Relations at Hasura, with a background in product and design. I'll provide a practitioner's take on what GraphQL has been and where it's going. Hasura is an open source tool that gives you GraphQL on your data sources, with robust access controls and a powerful predicate push-down model.

Hi, and welcome to my talk, GraphQL Everywhere. This is going to be a very fast talk. There are going to be a number of hot takes in here. And I think that at the end of this talk, we'll all have a number of things to discuss or think about or patterns that hopefully are maybe new to you or ones that will at least challenge some of the preconceived notions you've had about exactly where GraphQL might actually live.

Before we get into that, I want to go ahead and tell you about who I am. I am Developer Relations at Hasura. Hasura is a GraphQL company. I'll explain that here in a minute. I've been doing Developer Relations for GraphQL for roughly five years, and I come from a background in product and design. Some of my observations are going to be, as I described in the title, a practitioner's take on what GraphQL has been, where it's going, and mostly from a builder's mindset.

My name is Jesse Martin. I am a dad of four. That means that there will be a number of dad jokes dropped throughout this chat. I do apologize, but at this point I can't actually help that. You can also find me at MotleyDev. You'll see that Twitter handle there at the bottom of most of my slides. Who knows how long that's going to be good for. So definitely hop on that before that one's gone. But I want to go ahead and actually give you a quick overview of who Hasura is, the company I work for, because that'll give a little bit of context into where these observations and this pattern is coming from.

So first of all, Hasura is an open source tool, basically. And what it does is it gives you GraphQL on your data sources. It'll give us a database or a couple of other data sources at this point, and we'll actually generate the endpoints for you, the resolvers and things like that. Of course, you can customize them and all that kind of behavior. But at the core level, there is this idea of an engine that is interpreting one schema and conforming it or transforming it into another. That's actually going to be really important for us to have a look at later on. Think again Hasura Engine and also think again Hasura Open Source. I like to say, pay me if you want. And so what it does is it gives you very robust access controls, and we have a very powerful predicate push-down model. Basically the authorization takes place at fetching time, and so you're not actually over-fetching from your database. You're able to actually say, we want to have a very lean, very terse select set from our underlying data source.

2. GraphQL and Hiring

Short description:

And yeah, it supports custom business logic as well, event triggers, actions, and all those kind of behaviors you would expect from a data-layered tool. But the last point that I really want to hammer home, especially in times like these, is that we're hiring. So if you actually are in the market, if you're even dev rel, I want to talk to you. But we actually have a lot of openings across our business. And so we are hiring, definitely reach out if it's something of interest to you.

And yeah, it supports custom business logic as well, event triggers, actions, and all those kind of behaviors you would expect from a data-layered tool. But the last point that I really want to hammer home, especially in times like these, is that we're hiring. So if you actually are in the market, if you're even dev rel, I want to talk to you. But we actually have a lot of openings across our business. And so we are hiring, definitely reach out if it's something of interest to you.

So kind of where does this sort of sit in the big picture? Well, you'll kind of see it sitting in this sort of a layer where authorization, authentication happens externally. And you'll usually get a JWT is kind of the most common pattern. And then those roles get applied at fetch time. So like underneath it all what kind of happens is that you make a query, a GraphQL query, and our engine will actually map that to what the underlying data source understands. In this case, SQL, right? And so this is the way that our engine kind of operates at a fundamental level of letting you do this. This is a widget we have on our homepage. You can actually try it out interactively if you're curious, and there's a lot more information to be had on there. I did say it's open source, but this is not a side gig. So, I mean, it's a really big tool. We do have cloud versions, we have enterprise versions, we have a lot of major, major companies that are running on us. And so if you're looking for a GraphQL adoption at an enterprise-ready scale, reach out. We have a lot of interesting tools that might be of interest to you, and we have a really powerful go-to-market team that's just there to answer questions and get you going. So have a check.

OK, that's the Hasura stuff out of the way for now. And so what I really want to talk about next is that we have, for this talk, I have a couple of assumptions that are really, really important for you to actually bear in mind. Sorry, the benefit of recording from a home studio, right? So here are some assumptions that I want to have you really take with you into this talk, and that is that basically I am assuming that you will know a little bit about GraphQL and kind of what it's been used for up to this point. I really hope so because it's GraphQL conference and the other part of it that you need to be aware of is that some people on the internet get angry about really silly things. So those are the two primary points you need to understand to be able to go forward, and you'll see sort of what I mean by some of these later on. But first of all, so strong opinions loosely held but strongly inferred. I'm looping back to this practitioner's angle again. So these are things that I have seen in the market across multiple GraphQL companies. Now these are things that we have seen, but end of the day, haters gonna hate. So let's go ahead and start. So these are some of my opinions that have been formed from observing GraphQL at a number of different companies, both from the GraphQL provider as well as from the consumer. And that is that REST APIs are still very dominantly preferred by single service providers, people that actually are gonna be shipping an API for general consumption across the market.

3. GraphQL and Data Access Challenge

Short description:

GraphQL is preferred by multiple service consumers due to the complex data access challenge in the current ecosystem. With multiple data sources, microservices, platforms, and tools, the data access challenge becomes problematic. GraphQL allows us to merge these data sources into a single API, providing a federated approach to accessing multiple data. It is easy to model around different consumption patterns, making it a favorite tool for building products with specific data requirements. Metcalfe's Law applies to GraphQL, where the more data sources added, the more value it provides. Abstract models demonstrate the potential for creating recommendation engines and enabling various behaviors.

But GraphQL is preferred by multiple service consumers. And we're gonna have a look into why that is. But I mean, right at this point, you're like, well, that's like your opinion, man. But there's a reason why I've seen this. And there's a reason why I think this is held true. And that is, look at the actual ecosystem right now around building with APIs or building with different data sources. And the data access challenge becomes really, really complex.

We have a number of different data sources, a number of different microservices, a number of different platforms and other tools that we're trying to sort of stitch together. And each one is bringing its own SDK or ORM or other kind of API concept to the party. I mean, it's nice when we have open API specification that a lot of people can adopt. But that can be really spotty at times, as anybody who's built with application APIs lately even knows. And so we have a situation where the data access challenge is really problematic because it's just spread all over the place. And so when we're looking at specifically our microservices, this becomes a really pronounced problem. But we're going to look at that down the road, because I don't want to get ahead of myself here.

And so when we think about it, what would be kind of really cool from a data access perspective is what if we could just kind of use these data APIs and these services and just sort of kind of merge them all together into a single mesh where this service can use the same API that it's a member of to access other parts of the data. And so this is a concept that we're trying to kind of talk about, about this idea of a single API, where GraphQL gives us this ability to say we have one, one single API that actually federates across all these different pieces. So this is a really critical concept about why multiple data consumers are data consumers of multiple data really need to have access to all that in a single API because it's just one end point and one type of way of querying that data that lets them get access to their content. And so I want to go a little bit deeper here. And the reason is, is that when we look at why REST has developed the way that it has, or that the people presume like REST when it comes to delivering an API, is that it's really easy to model around deliverables, right? Because you have a pretty well defined scope of what data you're shipping out, and you have a pretty well defined scope around how you want people to access that data. But as soon as you start to have to model around different kinds of consumption patterns, you see that GraphQL quickly becomes a favorite tool because it's really easy to model around consumables, around what is this product that I'm trying to build, and what's its data requirements going to be? And then suddenly, I'm with a graph and I have to figure out how do I actually get all of these different data sources in a streamlined, resource-friendly way. Now I used the word model on purpose, because when I say it's easy to model, it is easy to model, but it's not always easy to implement. So I want to go ahead and talk about that also a little bit later on. So let's have a look again at what the GraphQL benefit here is. So this is why I like to refer to as Metcalfe's Law for GraphQL. And if you're not familiar with Metcalfe's Law, the more nodes that a graph has, the more value that it has, right? This is the social network theory. And so with GraphQL, it's very much the same way, the moment that you add more and more data sources, you get a lot of value from it. So let's have a look at some abstract models here. How does this play out? Well, if you look at something like a bunch of diverse data models here, we've got a scooter, coffee and a user. This sounds like a really bad day in New York. But if you take all these different nodes and if we kind of flesh it out a little bit into additional pieces of content, now we want to bring in things like weather and maybe like charging stalls and locations and battery status and other kinds of pieces of this data, well, suddenly we're actually looking at a recommendation engine for, hey, you're nearby this coffee shop and you've got some need to charge, why don't you stop by, charge your scooter and get a coffee? Or other behaviors.

4. GraphQL and Data Orchestration

Short description:

GraphQL allows merging diverse sets of data into a single API, reducing overhead and providing reusable patterns. It is agnostic to the consuming application, making it valuable across different contexts. GraphQL enables accessing complex data models and federated data dependencies. By accessing data at the execution time, round-trips are reduced. This approach is implemented in various industries, proving its practicality. Some argue that it's not what GraphQL was created for, but it aligns with its purpose of defining data dependencies. Latency is a solvable problem, and users are willing to wait for optimized services. However, new APIs may introduce new challenges.

The value that we're able to build and extract from diverse sets of data becomes really, really powerful. And the reason why then GraphQL makes this all really helpful for us is that to orchestrate this, there's less overhead, because I've just merged all the pieces into a single API, I have a smaller control plane, I'm not having to worry about shipping around my environment variables and everything else. I've got reusable patterns that I can reuse over and over again at different tooling. And it's like totally agnostic to the consuming application, if I'm shipping an Android application or an iOS application or whatever it might be that doesn't matter. And that agnostic part is actually really, really, really critical because I'm arguing here that that API has value for us across a number of different contexts, not just front-end consumers.

Well, let's go ahead and dive a little bit further into the theoretical models here. So what we have here is sort of your common GraphQL service structure, right? You've got your order product, you've got for reads, and then log in, log out, purchase, and editing your orders as mutations, or roughly speaking. And so you've got maybe SQL services or REST services identified for the data you need on the one side, and then on the other side, you've got micro-services for logging in and logging out and resets, and that's kind of roughly how this data sort of plays together. Well, you'll see that the data dependencies of something like a purchase, we need access to all this data. But something like a purchase model might actually be protected context, right? Because we're talking about mutating a database, or we're inserting content, or wanting to have data that's potentially interfacing with our database, and so we want this federated of data dependencies in the context of wherever our service might be running. So if that service happens to be purchased, we still need user order and product, but why can't we just get access to that data, like, at the execution time? And we're going to talk about some of the reasons people say that you can't, but let's go ahead and break this into a bit more of a less abstract model.

What happens if we were to say that the data model we're actually working with is way more complex, right? So we've got, you know, network credit average, we've got pending purchases, historical income, we've got the history of the users' returns, blah, blah, blah, what we have here is a risk assessment model. This is highly protected data. This is something we would like to be able to get information from as a feedback to just kind of wait, whether or not this person has a risk assessment for a credit score or whatever else. It's like, we need all this other data, which is going to live in very different silos, to be able to come together to make this weighted calculation. And so what I'm arguing here is I'm saying that, you know, we have the query coming from the client, from the front-end client, trying to get information about, am I approved or not approved, whatever it might be, but then that same protected environment can actually make a query itself with the same data API that I was able to call from my front-end client with the same API endpoint from the actual risk assessment service back to my same GraphQL API and get the entire data picture that I'm looking for to be able to make that calculation. Why do I, all of a sudden, do I need to actually break out into an entirely new environment for all of this data? I want to be able to access this data at the place that I need it. And so, then, if I can make that calculation, I can work with all the data payload I need for my calculation, I'm reducing the amount of round-trips and everything else that I might happen to need. Well, this isn't actually just theory, right? This is actually something that we see implemented everyday, at Hasura specifically, across healthcare, across reverse ETL things, DORA metrics, we have food delivery companies, all kinds of different services that are having to deal with this data.

Now I wanna go into some dissenting opinions and, as I say, also here, everybody's allowed to be wrong, but one of the arguments is that it's not what GraphQL was created for. I argue that, well, actually, it is totally what it was designed for, to be defining your data dependencies for an execution. Yes, it wasn't in the front-end context to reduce data over the wire, but it was about getting the data you need in the context you need it. Well then, what about latency? Okay, so, marginally higher than potentially a very optimally designed REST API, but that too is a solvable problem, so I want to cover our approach to that. So when we move on here, talking about our solutions for that, we want to do the gotchas, and there are none, so we can just go. So when we talk about latency, there are actually solvable problems for this, but this is something you have to bear in mind with the data model. This is true for any API, but generally speaking, the user can wait, right? I would be happy to wait an extra one to two seconds, if the service worked the first time and didn't have a hangup on the API side. The second piece is new API, new problems. So potentially we're actually just shifting all of the errors or the issues we had with best-consuming patterns for our microservices just into an entirely new context where we have to build out all of this new infrastructure to support microservices consumption of GraphQL. And here's where I really want to kind of hammer here. So we actually have a new API, but we have a hero emerging.

5. Introduction to GraphQL Data Specification

Short description:

Hasura introduces the GraphQL data specification, a powerful tool for defining your data needs and creating APIs. It allows you to abstract the underlying data sources and feed them into an engine. This alpha release seeks community feedback and encourages users to try out the playground and provide their input. Visit the Hasura GitHub repo for more information. Thank you for attending the talk and feel free to reach out with any questions or join the Hasura community.

And so Hasura is building off of this experience we've had helping customers implement these patterns. And we're now actually introducing a new tool that we'd like you to have a look at. And that is actually the GraphQL data specification.

The GraphQL data specification, very specifically, is a description or it's a DL that is a description for what underlying data sources might look like. How can we connect these data sources across different entry points? What do edges look like? How does it resolve? We're abstracting away the underlying data source at the moment for us. We use a database schema. We're abstracting that away into saying, let's have an actual DL that we can feed into an engine. And that engine will actually allow us to be able to read or be able to create the APIs that we need from GraphQL to support this.

So this specification says, yes, microservices execution is great, front-end execution is great. But the bigger picture here is defining what your data needs are. So use a tool like this, use a tool where you can define your entire data layer inside of a DL, and then feed that into an engine and be able to actually have that interpret and create the content you need. That's a really, really powerful way to work.

This is a very, very alpha request for feedback, get-involved, community-driven thing that we're releasing here. We would love to have you get involved with this and let us know what your feedback is. You can try out this playground here. We'll drop the links inside of the chat where you can find this and be able to actually test it out for yourself. So it's the GraphQL data specification. It's on the Hasura GitHub repo for right now. You can find it there. But we would love to have you have a look.

That being said, that's actually my last slide. I want to thank you very much for coming out today. If there's any questions, feel free to drop them in chat and I'll try to answer them. But again, thank you so much for watching this talk. I know it's fast. I know there was some hot takes in there. But if you have any questions, find us on Discord. Find us inside of our community, GitHub issues, everything else. Try out Hasura. Use the Hasura cloud. It is the fastest way to get going with Hasura. There's a free tier on there. But we think you're going to love it. And we can't wait to hear from you and see you on the community.

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
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
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
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
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.