Urql Q&A

[00:00:00]
>> Scott Moss: I highly recommend going to the urql docs and reading about cache updates. Or if you click on Graphcache, you got to Cache Updates, I highly recommend reading about this, okay? This right here is you'll most likely 100% be doing this in a production app if you're using any type of systems like urql or Apollo, you're gonna have to interact with the local cache on updates.

[00:00:26]
Like an example right here, this is actually the perfect example for us. This is how we would have fixed our issue being added to a list when we create an issue. We would have, so in their case, they're making a new todo. We were making a new issue.

[00:00:40]
So very similar. In our cache exchange, we can write a handler for our create issue mutation here. And this is where it kinda gets confusing, so I didn't really wanna talk about it. So they're querying the local cache with GraphQL. And this is where it gets crazy. So they're not querying the API with this query here.

[00:01:00]
This query is for the local cache, because the cache itself is a graph. So you can query the cache with GraphQL. GraphQL doesn't have to go over the network, it can query any data source, even if it's local. So they created a query to get all the todos by their ID.

[00:01:19]
That'll give them a todo list, and then what they can do is they can update the query for this todo list. They'll get all the todos here. And they'll return a new cache with all the previous data on there unrelated to todos, and make a new array for todos with the current todos on it, plus the new one that just got added.

[00:01:40]
Right, so it's very similar to Redux. It's immutable operations, right? They're doing an immutable operation here. But this is very specific to urql. Every client that I saw has a version of this and they're all different. So I was just like, okay, I'm just not gonna teach it, but I'll talk about it because as you can see, they're never gonna be this small.

[00:01:59]
They're gonna be way bigger than this. They're gonna be massive. So it can get quite complicated, caching strategies is quite complicated. I didn't wanna dive into a lot of that stuff because they're just advanced performance level things that you don't really need to get started. And this is more of like a getting started course, so I didn't really dive into them.

[00:02:19]
But I'm talking about them now as a means for you to go and check out. So if you start using this in production and are like, how do you get past certain things? So something to keep an eye out on. Yeah, so I would say check that out.

[00:02:32]
And then all the other stuff is probably gonna be covered in the server course. The server course covers 90% of GraphQL. The frontend stuff is quite simple. It's the backend stuff that's really hard to wrap your head around sometimes. So we'll do that, yes.
>> Speaker 1: What factors do you consider when choosing between urql versus Apollo?

[00:03:00]
>> Scott Moss: What factors do I consider? Documentation, resources, recent updates, and whether or not they have a good track record of supporting some of the latest features. Like, I use Next.js quite often. App Directory has been out for a long time. The fact that urql had support for it, that's not experimental.

[00:03:24]
What's good for me, if I click here, they actually have.
>> Scott Moss: I know they talk about it in here somewhere, but the app directory, they support server components, they do all that. Whereas all the other ones, also Legacy, here we go, all the other ones have experimental support for it.

[00:03:47]
I'm just like, App Directory been out for, I don't know, a year plus now. It's still experimentalist. I just don't like that, I'm just like, move a little faster. So for me, I'm always looking at something that's useful, that a lot of people use, but it's being updated and is staying up to date.

[00:04:03]
Documentation is simple, easy to use. So that's kinda how I look at it. I mean, urql is gonna be just as good as Apollo. It's just that Apollo has a bigger ecosystem. So it's like urql can do everything Apollo can, but Apollo probably already has a plugin for it.

[00:04:18]
So it's just a massive ecosystem, which is why we're using it on the server for the server course, but I didn't use it on the client course cuz I felt like it was like shooting a fly with a shotgun. It was just too much. It was like, you didn't need all of that.

[00:04:32]
You just need something a little more simple, so I chose urql.
>> Speaker 2: So I'm familiar with some tools like Qlik, and that's sort of for data aggregation and business intelligence. Now, I,
>> Speaker 2: Was under the impression. I mean, somebody gave me some wrong information about GraphQL a long time ago, and it's in this life, I had to reset.

[00:05:02]
But I look at the fact that you're dealing with graph data underneath the covers.
>> Scott Moss: Yes.
>> Speaker 2: And that you've got different ways of mapping information into it and then how to get it out, which is great. But I was curious if a tool like Qlik, do you think that's the kinda thing that they're doing?

[00:05:21]
Because they've got a lot of that kind of, whether it's Qlik or other data aggregation type services, I can see that this would be really sort of a good core technology to accomplish that kinda stuff for a SaaS or-
>> Scott Moss: Yeah, I think a lot of those tools, what they're probably doing, I mean, they could benefit from GraphQL.

[00:05:44]
I think for them, it's like the end result of GraphQL is some client querying it, right? But if a product like Qlik, which is probably doing, their end result is to get this data from here to here. And yeah, eventually, there is a client somewhere, but that client doesn't pull it directly from this source.

[00:06:02]
It goes into this warehouse or something, and then there's some analysis, and then out comes something else. So for them, GraphQL probably might not be that useful because they're not allowing someone to directly query this data that's coming from all these different sources. They're just trying to move data from here to here.

[00:06:20]
So they could use it, but it probably wouldn't be worth the time of them building the infrastructure for GraphQL. It's probably better for them just to say, we'll just write the code that maps directly to these field types. We'll just rely on the database schemas as our contract and not so much the GraphQL schemas.

[00:06:36]
And hopefully, that never changes. If there's a migration, we'll have to adjust. I think that's probably what they're doing, they're just relying on the fact that the sources that they're pulling from have version APIs. And they can subscribe to those different versions and without fear of those APIs breaking.

[00:06:52]
And they probably just do that. But yeah, I think that would probably be the best use case because, yeah, you'd only get half the value of using GraphQL without eventually having someone on the client be able to query that. You know what I mean? So I would say probably that, yeah.