Wrapping Up

[00:00:00]
>> All right, Nicholas has a good question. He asked a couple minutes ago, could we define a type of for verifying if something has a hashtag key instead of using object as any? And I'm gonna guess he is referring to in the trend resolver, this this thing here.

[00:00:20]
So yeah, we have a little bit of a challenge here. First off, I mean, actually I think we do, we could do it like this. This is a better way to do it. It's good you asked. Actually, it's tricky, I'll tell you what I was just thinking. I was about to reach for kind, I was thinking, hey, we already have this kind string, it's something that's stored in our database, right?

[00:00:53]
So we look at the trends, should be maybe at the bottom. Yeah, here it's actually a field, you can think of this, there's a column in our database and serialized in there we should be able to rely on it being in there. However, important to remember, this is the GraphQL representation of that entity.

[00:01:12]
So what we could do instead of doing this, we could in this query as we're assembling this, we could use that cache strategy where we would, while we have access to the DB representation which it's this. This object here. We could maybe build up a map that shows here is the trend ID, and it belonged, it is a hashtag trend or something like that.

[00:01:42]
And then as we're being asked to sort out deeper down in this function like, all right, here's a GraphQL object that has no kind property, right? What is its type? We could then reach into this context object and sort out what's going on. Does that make sense? Now, this is also totally fine.

[00:02:11]
I know this field will be there. So, I would say that this is okay. It's effectively a user defined type guard, but in the GraphQL world instead of in the TypeScript world, yeah, many ways to do it. You could either do some bookkeeping or some introspection. What should I remember as a summary after the course about the cache in terms of which queries we cache and why?

[00:02:38]
And he also mentioned n plus 1 queries, what should I remember about that? So my answer there is, I'm gonna paraphrase that question a little bit. I think what he's asking for is a sanity check. How do you know you're caching in the right places? And not worrying too much about caching in places where it matters less.

[00:03:01]
I would say just study your schema and think about how it's going to impact your resolvers. Things are either going to be called one time or n times usually, it's just, is it a current user thing or is it an N times thing? And it does get a little bit more complicated and this is a challenge with GraphQL.

[00:03:27]
You can't always be sure what's gonna be called in what order and this is the most handwave answer ever. The more complicated your schema gets, the less confident you can feel about users will only be accessed on a per one off basis. Here's an example, you could look at this and we've said this, right?

[00:03:52]
Based on the kind of queries I'm making, it's totally fine when we go to a user and we say, give me your stats, and we're gonna get the whole list of likes that they've made and get all of those into an array. Well, that may have been fine at one point, but I could also get all the tweets and the authors of those tweets which are of type user and then start reaching into those users and getting some of this really expensive stuff.

[00:04:17]
So try to avoid the n plus one queries, but it's the kind of thing where you have to stay well organized. It's one of the main challenges of working with GraphQL. You have a system here that has very little information about how is this information being used and in what circumstance.

[00:04:35]
You can ask it for whatever you want, and that moves the problem. The problem is now, how do you fulfill a wide open set of possible requests people could make in a way where you can guarantee things will be performant and that your systems won't be degraded? An approach that some companies have taken is limiting queries, where maybe you can only ask for certain things on users if it's a one-off request for one user and they'll give you a server error if you try to ask for it in a context where it's gonna degrade things too much.

[00:05:15]
Making something that's fast and easy and consistent and very, very, very, very performant all the time, that sounds like a zero trade off situation and those generally do not exist. I'm not sure how much useful information there isn't that answer, but it's kind of a gray area. This is about system architecture more than how do you put these pieces together to form a full stack TypeScript app.

[00:05:49]
Thanks very much for building this Twitter app. A full stack TypeScript app where the client and server are connected with GraphQL. I hope you can see that some of the benefits you enjoy with writing TypeScript code either on your server or your client, now we get some of those advantages across the stack.

[00:06:07]
Where as we refactor things, as we change things, type information is telling us where we need to finish up and complete our refactor all over the place. So it's a great way to set things up and hopefully it provided a great experience for you and you learn how to use GraphQL and TypeScript together.

[00:06:24]
Thanks a lot.
>> [APPLAUSE]