So, a data source can be either a database, a function that is kind of outside of the main service itself, or an HTTP endpoint for bringing in a microservice architecture into a GraphQL API.
So, let's talk about the data fetching piece of GraphQL, which is really interesting. With GraphQL, you might be coming at this from Rust, so I think it's really convenient and really interesting to kind of compare the two, GraphQL versus Rust. With GraphQL, you have this idea of queries, mutations and subscriptions, and these map really well to things that we've done in the Rust world, kind of mapping to things like the HTTP verbs that we work with. So, when you need to read some data like getting or listing a list of items, you're going to be using a GraphQL query. If you're going to be updating, creating or deleting anything, you're going to be typically using a mutation, and then if you need some type of Realtime aspect to your API, you're going to be using subscriptions.
So, let's take a look at a table of GraphQL versus Rust verbs. So, again, mapping a Get request might make a lot of sense to a GraphQL query. So, getting an item by ID or getting a list of items will be typically a GraphQL query. And then post, put, delete or patch operations will be GraphQL mutations. So, that being said, let's take a look at kind of the way that GraphQL just brings back the data that you've asked for, kind of like we mentioned just a moment ago. So, in a query, you might be able to say, OK, we have this GraphQL type of to-do, and this to-do has four fields. It has an ID, a name and a createdAtValue or fields. And this request, we want to get all four of those fields, so that's fine. But you can also say, I only want to get a subset or a smaller selection set of these fields. And this is going to continue to work. You don't have to kind of make any updates to your back end. The way that GraphQL is built, the way that these queries are created, you only get the data that you've asked for. So again, if you've ever worked with building out different types of client applications for a single back end in the modern world, you might have a web, a mobile, a desktop app that also maybe has an Apple Watch app or even a car app in the future, you never know. Having GraphQL as a data source allows you to kind of have a lot more control over your data access without having to change a lot of code on your back end, once the implementation is complete.
So next, let's talk about the GraphQL subscriptions, which are the real-time aspect of GraphQL. GraphQL subscriptions enable real-time communication between a client and an API. Subscriptions are event-based. So when you create, update, or delete an item, you might be able to subscribe to that event. So typically, a subscription might have a name like onCreate, onUpdate, or onDelete. So for a to-do app, you might have onCreate to do, onUpdate to do, etc. Subscriptions are typically a two-way connection. So you have to have a way to send the update and then have a way to receive the update back on the client. So a lot of times you are then asked about, okay, with this being said, how do you actually implement GraphQL subscriptions? So if you're using a service like Hasura or AppSync or any of these GraphQL services, this is going to be kind of taken care of for you. But if you're building your own API, you're typically going to be making the decision between something like servers and events or websockets.
Comments