Robin’s back! And Eve Porcello, author of Learning React and Learning GraphQL, joins us to talk GraphQL in React Native
Robin’s back! And Eve Porcello, author of Learning React and Learning GraphQL, joins us to talk GraphQL in React Native
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio podcast. Brought to you by Pampers, the try-catch of the baby world. Episode 226 GraphQL with Eve Porcello.
Mazen Chami:
Jamon, I'm really excited about this episode. Before we get started, can I play a little song for you?
Jamon Holmgren:
A song? Okay. So this is a little out of the ordinary, but yeah, let's go ahead and let's play the song. That sounds good.
Mazen Chami:
All right. Let me cue it up.
Derek Greenberg:
(singing)
Jamon Holmgren:
Wait, what are you saying, Mazen? What exactly is Derek singing there in that song?
Mazen Chami:
Robin's back.
Jamon Holmgren:
Robin's back. Robin.
Robin Heinze:
I'm back.
Jamon Holmgren:
Welcome back. You're back. Yay. Where have you been? We've been looking for you everywhere.
Robin Heinze:
You want the fun story or the real story?
Jamon Holmgren:
Both.
Robin Heinze:
That's too bad. I don't have a fun story.
Jamon Holmgren:
Okay. Well, what's the real story?
Robin Heinze:
I had a baby.
Jamon Holmgren:
You had a baby.
Robin Heinze:
I had a baby.
Jamon Holmgren:
Oh, congratulations. You had a little boy.
Robin Heinze:
Yep. His name is Peter. He is pretty much the cutest thing I've ever seen.
Jamon Holmgren:
Can confirm, I've seen photos.
Mazen Chami:
That's a fact.
Robin Heinze:
Yep. We're still working on sleeping.
Jamon Holmgren:
Yeah.
Robin Heinze:
But that'll come.
Jamon Holmgren:
Yeah. I have four kids. I know what that's like. This is your second kid, right?
Robin Heinze:
Yes. Second kid.
Jamon Holmgren:
How's your oldest dealing with having a new baby?
Robin Heinze:
She loves him. She can't wait to actually be able to boss him around. He doesn't really listen to her yet.
Jamon Holmgren:
Yeah. Classic. Takes after his mom. That's pretty awesome. Well, congratulations again. We're so happy to have you back though. It's great. In fact, we've been getting tweets, when's Robin going to be back?
Robin Heinze:
Well, I feel so loved.
Jamon Holmgren:
Derek made that song and Mazen, thanks for playing it. Derek wrote that song in a day. I mean, it's patterned after another song, Welcome Back, by who was it?
Robin Heinze:
Well, it's the theme song from Welcome Back, Kotter.
Jamon Holmgren:
Welcome Back, Kotter. Yes. But I think it originally was... Yeah. Anyway, it doesn't matter, but it's a great old song. The lyrics of the original song are pretty funny too and Derek took it and put his own twist on it. It was perfect. Love it. Derek Greenberg, he is of course our guest coordinator and of course now apparently our official musician of the podcast. Love it.
Robin Heinze:
He's the Lin-Manuel Miranda of React Native Radio.
Jamon Holmgren:
That's perfect. We needed one. I'm Jamon Holmgren, your host, friendly CTO of Infinite Red, and I'm joined today by my fine co-hosts.
Robin Heinze:
Fine?
Jamon Holmgren:
You could read that in a few different ways, fine.
Robin Heinze:
Fine?
Mazen Chami:
Just fine?
Jamon Holmgren:
Okay. Just fine. Okay.
Robin Heinze:
Well, we were shocked that you hadn't used fine yet of all the crazy words you've used, fine.
Mazen Chami:
It's just fine.
Jamon Holmgren:
Well, you said that I'd be running out of synonyms, but I'm digging a little deep into the barrel of these and I may have to start reusing them at some point.
Robin Heinze:
I mean, aren't we all like just fine right now?
Jamon Holmgren:
I hope you're fine. I hope everybody in the audience is fine right now.
Robin Heinze:
This is fine.
Jamon Holmgren:
Doing fine.
Robin Heinze:
This is fine. Everything's fine.
Jamon Holmgren:
Robin Heinze, welcome back and is a senior software engineer located in Portland, Oregon, works at Infinite Red, specializes in React Native and raising very cute little kids. How are you doing Robin?
Robin Heinze:
I'm doing well. I didn't get a lot of sleep last night, but coffee is a great savior.
Jamon Holmgren:
A wonder drug. Mazen, of course, is a co-host as well. He works at Infinite Red is a senior React Native engineer, lives in Durham, North Carolina, former pro soccer player and coach, and has been holding down the fort with me while Robin's been gone. I really appreciate it, Mazen. How are you doing?
Mazen Chami:
Doing well. Glad Robin's here. Now, I can take the back seat again.
Jamon Holmgren:
I don't think that's going to happen. You've been doing great. Not only do we have Robin back, but we have an amazing special guest today and I cannot wait to introduce her. And I will in just a second, but I would do have to say this episode is sponsored by Infinite Red. Infinite Red is a premier React Native design development agency located fully remote in the US and Canada. If you're looking for React Native expertise for your next React Native project, hit us up. You can learn more on our website, infinite.red/reactnative. And don't forget to mention that you heard about us through the React Native Radio podcast.
Jamon Holmgren:
And though we are hiring, as you heard Derek say in the song, we have grown a bit since Robin has left. And in fact, we are needing developers so badly that we had Robin go off and make another one for us, which was very nice of her to do. It's going to take a little bit though to get that one turned around, but you can go to careers.infinite.red if you are a senior React Native engineer living in the US or Canada. So our guest today is Eve Porcello. That's how you told me to pronounce it so that's how I'm pronouncing it.
Eve Porcello:
No Italians in the audience.
Jamon Holmgren:
Apparently, yes. Eve is the co-founder of Moon Highway, which is an awesome name by the way. I love it. A curriculum development and training company, where she teaches JavaScript, GraphQL and React training workshops to tech professionals around the world. She creates courses for LinkedIn learning and Egghead, and is the co-author of Learning React and learning GraphQL from O'Reilly Media, which is very impressive. I know O'Reilly's the gold standard, so you not only have your stamp on one of them, but two awesome books. That's pretty awesome, Eve. How are you doing?
Eve Porcello:
I'm great. I'm so happy to be here today. Thanks for having me. And I co-wrote both those books with my husband/coworker, Alex Banks. So technically I've only written one, so I appreciate the compliment, but I can't fully take it. Yeah.
Jamon Holmgren:
As a fellow co-founder, I put my name on everything and I take credit for everybody's work. That's just how it works. That's what you're supposed to do.
Eve Porcello:
Oh, certainly and I definitely do that.
Jamon Holmgren:
So our topic today and why we're bringing you in is GraphQL. And as mentioned, you wrote the book on GraphQL, which is awesome. We're going to specifically talk more about GraphQL in React Native. Of course, we're the React Native Radio podcast so we want to talk about that, but we're also going to talk a little more generally about GraphQL. A lot of the stuff we talk about will be applicable to both ReactJS web and React Native projects.
Jamon Holmgren:
Sometimes in some cases there may be slight differences, but that's the beauty of React Native is a lot of times it applies across the board. So I will say there are a number of React Native Radio episodes about GraphQL, but we haven't done any since Infinite Red took over the podcast. So people can go back and listen to those past episodes if they want, but it's about time that we approach this ourselves. So Eve, I first want to maybe have you start off maybe tell us a bit about your background, how you got into coding, how you got into teaching and all that.
Eve Porcello:
Yeah. So I got into programming maybe 10 years ago when we moved to Lake Tahoe area, there were no jobs here at all. This was before people could work remotely. And so my husband was trying to get me into programming. I was working in program management, product management, and he's like, "You should work with me for a couple years." And I always said, "No, I'll never do that." And then we moved here where there's no jobs. And I was like, "Yeah, I guess I have to at this point." Got into programming as a JavaScript front end person who was working on client projects, small websites and things like that.
Eve Porcello:
And then got into training because we live three hours or so away from the Bay Area where there's tons of training opportunities there. So I got into teaching, Node.js at PayPal when they were first adopting it and got lucky with learning React fairly early too, because we were teaching at Yahoo and they were saying, "Hey, we're transferring all of our YUI code to React." And we're like, "We better figure out what React is."
Eve Porcello:
So we got the inside track on that early, which was pretty cool. But teaching and programming have gone hand in hand and we've work on a lot of curriculums for these types of things too so that other trainers can teach what we have created. And that allows us to spread out because there's only a couple of us working here so we can have other people teach our content.
Jamon Holmgren:
That's awesome. We've done some level of teaching ourselves, but developing curriculum is a lot more work than it looks like and it's very difficult.
Robin Heinze:
Definitely a full-time job.
Jamon Holmgren:
Oh man. Yeah. So that's pretty awesome. I really love that.
Eve Porcello:
Yeah. I think developing curriculum feels like something you do once and it's like, "This class is done." And then everything changes and you have to move everything to a new tool or new technology. So yeah, it's ongoing, definitely a full time job.
Robin Heinze:
So I think it probably makes sense to start off our conversation about GraphQL with just what is it? For our listeners that may not know, what is GraphQL and how did you come across it and how did you get involved with it?
Eve Porcello:
Yeah. So GraphQL is a way of writing queries to get data in your front end applications. And it's a query language for your API is the short tagline for it, but it really allows you to have this query language for asking for the data that you need from your data sources. GraphQL doesn't care at all where your data lives so that's something that's cool about it. You can get it from REST APIs, databases, and you can get it from all those places at one time actually.
Eve Porcello:
So GraphQL allows a lot of flexibility there. Something kind of the unsung feature of GraphQL, which everyone uses all the time, but they don't talk about it as much maybe is that it gives you a type system for your API too. It allows you to create a schema, describe all of your APIs types, your products, your users, you think about what are actually the fields that we need from our data sources.
Eve Porcello:
And then you have this awesome typed API for just making sure that your clients are only asking for the data that they need really in an efficient way. I think a lot of us have gotten into it this way through React because GraphQL came out of Facebook and suddenly at every conference there was a GraphQL talk. And I was like, "I don't what this is and I really am curious about it."
Eve Porcello:
And one of the nice things about working with GraphQL is it gives you this in browser tool called GraphiQL or GraphQL Playground or the new Apollo Studio now. And this is such an awesome thing that you can use to get into GraphQL right away. So I think a lot of folks are charmed by it, day one as I was, because it feels very fun and easy to get the data from wherever it is. So GraphiQL, always got to give it a shout out because it's the coolest part of GraphQL I feel like.
Robin Heinze:
It has really good curb appeal. It's really flashy from the get go draws people in.
Eve Porcello:
Totally.
Robin Heinze:
I'm pretty sure I heard about it for the first time at Chain React.
Jamon Holmgren:
Oh yeah, our conference React Native-
Robin Heinze:
The first one maybe.
Jamon Holmgren:
Yeah, the tooling and everything around GraphQL is super cool. We're going to be talking about that some more for sure.
Robin Heinze:
Of course, the QL makes me think of SQL which was where I got my start programming.
Jamon Holmgren:
Yeah. I remember some of the experienced developers that were skeptical of GraphQL were like, "Oh they reinvented SQL. Yay." That's not totally true. Tell me when you're using SQL from the client, then we'll talk.
Robin Heinze:
But if you know what SQL is, that's a really good way to try and understand what GraphQL is. You can write a query to get exactly what you want, but from your API.
Eve Porcello:
Yeah, totally. And you can use both of those together. So some people think GraphQL's here to kill everything. Here's this idea that we're here to kill REST. We're here to kill SQL. We're here to get rid of everything you know and love. And that's not really true. You can use it with everything.
Robin Heinze:
Surprisingly, everything is not black and white.
Eve Porcello:
Shocking. I agree.
Mazen Chami:
Talking about killing REST, that leads me to my question about when would it be attractive to replace REST with GraphQL and why?
Eve Porcello:
To build on what I just said about not killing REST, I think a lot of the most successful REST to GraphQL migrations have started with GraphQL wrapping around REST. And sometimes people feel like that's enough, we should stop there because we're getting everything we need out of that. There's nothing that says you have to get rid of REST in order to use GraphQL.
Eve Porcello:
However, nice replacement is just to think about all of your various end points. So instead of thinking about endpoints with REST, we're thinking about queries and with REST, we get these huge payloads of data back as JSON. And sometimes that's a good thing because we're getting the data that we want. But GraphQL allows us to be a little bit more granular about exactly what we need. It also helps us from this is a React Native podcast from a component perspective, thinking about how a query maps to the data requirements of your component.
Eve Porcello:
So you don't have to fetch all this extra data. You don't have to make as many different HTTP requests. You can just be really specific about what you need. And I think GraphQL or not, the vibe lately with data fetching in our components is how about we collocate the requirements of the data alongside the UI and GraphQL is just a no brainer there. And I think even if you don't use GraphQL, I think that's a good pattern to think about.
Mazen Chami:
Yeah, I've used it in a React Native app and I really like how when you're on a certain screen and you only want to pick let's say we're on the profile page. You want to pick first name and last name and email. You can pretty much tell your GraphQL API only return this, but knowing that, I guess we're talking about a user profile here, but your user JSON could be fairly large with tokens and other data, which for a mobile app can really bog that down and make a very intensive call.
Mazen Chami:
Do you ever see GraphQL being the default choice over REST or do you still see them kind of working hand in hand?
Eve Porcello:
I think that right now there's a migration to GraphQL happening where if you are starting from scratch on a project, people are selecting that from the start. I think that that's been a change since it was announced in 2015 where all of the React enthusiasts of GraphQL, the GraphQL enthusiasts in general, would just kind of make it happen at their company where they would wrap whatever they needed to or just push it through.
Eve Porcello:
But now people are seeing that, "Hey, Netflix is using this. PayPal is using this." Big companies are making big bets on GraphQL and it feels like a stable enough technology that it doesn't feel as scary to implement from the start. So I do see a lot of people reaching for that as they're building new things in a way that's exciting. It hasn't really always been like that.
Mazen Chami:
So what are your favorite GraphQL JavaScript clients? I know there's a lot out there. I could list a couple, but Apollo comes to mind and Urql. What are some of your favorites and what would you recommend for a React Native app?
Eve Porcello:
I have used Apollo client the most. I've worked in that Apollo stack for the most part, but I know that folks really, really, really like Urql a lot too. So that and React Query are a couple of dark horses that are coming through and saying, "Hey, we're a really powerful solution as well." So those are great. Also, Relay is really awesome. I think actually I looked this up yesterday, that Relay and GraphQL were released on the same day at React Conf and so they're always associated with one another as these Facebook technologies for data fetching.
Eve Porcello:
When Relay came out, I didn't really get into it because I felt like this is a little bit too complex. I don't know what's going on here, but I've revisited it. And it feels like the new Relay is really cool.
Eve Porcello:
So I would say that's really worth investigating in a way that I wouldn't have recommended maybe a couple years ago just because I want people to like GraphQL. I don't want them to be freaked out by it. So ultimately I think Apollo client is really great for my needs. Basically you use hooks to fetch data and I know that may be changing and React as well over the course of the next couple years. But at the moment, I found it's really cool and you can use it for queries, which get data mutations, which change data and then subscriptions, which are really cool in GraphQL too, which let you work over web sockets and fetch data in real time. So all are supported and they're supported in others as well, but I feel very comfortable using that pattern to fetch the data.
Robin Heinze:
Do any of those also double as your state management or persistence layer?
Eve Porcello:
It definitely can. So Apollo client has these two pieces. It gives you caching. So caching is really important obviously for a situation where we don't have end points anymore. It was easy to cache REST data because we just have the end point. But now we're caching queries, what is this mayhem? So Apollo client gives you a nice cache for that, that allows you to persist and React Native and React for the web have different versions of that. But you basically get that as well as your network interface. So anything you need to communicate with that GraphQL API there's it's called an Apollo Link for that. So it's a link you would use for HTTP requests or for web sockets or for offline. And so it gives you a lot of the things that you have to think about without having to think about them as much, which I like personally.
Mazen Chami:
Yeah. And I believe Apollo has also a component architecture where that component makes that fetch and I think that's also something pretty cool. So I guess going through what you mentioned, it's more about what your app needs at the end of the day. There's so many clients out there that could do the work for you.
Eve Porcello:
Totally. And I think that all of them share the patterns of associating a component with a query and caching that data. So if I'm your user example from before, if I'm asking for first name, last name, and email address, I can store that in a cache, persist that cache, and I don't have to keep asking for it because sometimes it feels like with the GraphQL, are we just making a thousand HTTP requests? What are we doing here? So a cache is super important and something that Apollo gives you out of the box, Urql gives you, Relay gives you because it's so vital to making your app not be a total dud.
Mazen Chami:
How well does GraphQL translate to React Native? I know it's mainly React basis. Do we need a native layer or is it just pure JavaScript that we can hook up to our React Native app?
Eve Porcello:
It's pure JavaScript that you can hook up to React Native. So if you have come from a JavaScript more web based background and you have to create a React Native application, you'll find that with Apollo and Relay and Urql, a lot of those patterns that you're using, a lot of those tools you're using functions down to the packages you're using. It's all the same. So this is really nice for creating... All you're really doing with GraphQL is creating those queries and creating the connection to your GraphQL API, that's the client part of it. The schema and all that stuff lives on the back end. But as far as how that works with React Native, it's all pretty much the same.
Mazen Chami:
Are there any pitfalls or anything we need to keep in mind while we're hooking it up to a React Native application?
Eve Porcello:
In general, few things that can be tricky with GraphQL on the client in general is just what you said. So state management and where did we keep this cache? Do we persist it? How long do we persist it? When do we kick out the old records? When do we fetch again? These are all decisions that you can use the defaults, but at some point you're going to have to get in there and be more granular about how you want that data to be re-fetched. And also pitfalls are error handling.
Eve Porcello:
I love GraphQL. I don't necessarily love GraphQL error handling because everything seems to give you either it's all broken or it's all good and you'll get a 200 and you won't have any data, and you'll feel like I hate my job, but there's a lot of cool error handling techniques and tools. There's GraphQL errors, there's some new Apollo client configuration options for version three, which came out fairly recently. And those are things to look a,. But I always feel like we could go a little further with those error handling features.
Robin Heinze:
To be fair, I feel that way about most REST APIs that I've ever used.
Eve Porcello:
Yeah, totally. So we bring a lot of the same problems from REST into GraphQL.
Robin Heinze:
My last client didn't return anything except 200 for-
Eve Porcello:
Good. Yeah. That's great. That feels good.
Jamon Holmgren:
It sounds like the problem isn't really the technology.
Eve Porcello:
Totally. Yeah. We may need to look bigger, think bigger. Yeah.
Jamon Holmgren:
It's those backend devs. I can say that, I was a backend dev. Yeah. And there's no really one size fits all solution to a lot of those things like caching like you said, you have to be thinking about how people are using your app and what their expectations are and how you're communicating that on the front end. And we've all used apps where they've done it poorly and you're just like, "Oh really? Why are you still showing this old data? I just updated it or whatever."
Eve Porcello:
Yeah. All those decisions don't go away so we have to continue to think about those things.
Robin Heinze:
Besides error handling, is there anything about GraphQL that would make you not choose it or certain situations that would maybe make GraphQL not an ideal choice?
Eve Porcello:
I think that there can be a tendency if you have a database to want to map that database one to one with GraphQL, I always feel a little bit of anxiety about that when I hear about it, just because mapping your database one to one with GraphQL gives you all of the imperfections of your database just in GraphQL now, and then you don't get a lot of the benefits of adding that layer.
Eve Porcello:
So what I would recommend is and this is tricky because sometimes it feels really good to just automate the process of generating schema based on a database because that is super fast and that's something that you can do with a tool like Prisma or something like that. I would always recommend that even if you do use a tool that auto generates a schema that you take the time to look at that schema and ensure that your clients actually need the data that you're modeling in that schema because you know how databases go.
Eve Porcello:
They've been around maybe for a while and there have been some quick fields added that maybe are not in use or maybe they're not ideal or they have wild names that make no sense. So I think GraphQL, and I guess programming in general if we're really striving to be good at our jobs, is all about communication. And those one to one maps can sometimes communicate poorly.
Robin Heinze:
See, this is why I don't trust automated things completely. And you still need the human to decide what has value and what makes sense.
Jamon Holmgren:
Robin, are you saying that just because I told you to use GitHub Copilot?
Mazen Chami:
I was about to say that.
Robin Heinze:
Yes, I am.
Eve Porcello:
This automation stuff. We can't trust it. What are the robots doing?
Jamon Holmgren:
Oh, wow. Yeah, we’ll have a revolt. Yeah. In databases, it's always easy to add columns. It's much, much more difficult to remove them and that's something that sometimes you don't have a lot of control over. And so the backend team's doing their thing and it just accrues, corrupt, but that's the cool thing about... And I mean, you can do this with REST too, where you transform the data into what you would expect it to be, things are like that.
Jamon Holmgren:
But I guess with GraphQL, in my opinion, you look at it and it's just the inherent nature of it makes you want to transform it into something that is useful to the client because that's what it's doing. I's really serving the client side of it so much more so than maybe the backend. It's client first, which I appreciate now, even though I did back in for many years. It totally makes sense that the client is driving that forward because it's closer to the user and what does a user need. There's also security implications with dumping all the fields over. Some of the stuff shouldn't be shown on the client so don't send it along.
Eve Porcello:
Absolutely. That can be really scary. And I think what you said about databases having to remove a field or a column is really tough, same with GraphQL. As soon as you add a field to a GraphQL schema and a client starts requesting it, that client will demand that field from now on. And so that will break your queries if you're asking for it.
Eve Porcello:
So really thinking through the schema and what is actually required for the client can be really useful. One of the ways that you can do this is to literally create wire frames of what your app or your website looks like, associate those components with a query. And if you're building a schema that has a bunch of different fields that have no representation in any of your UIs, then really think about what you're trying to add.
Jamon Holmgren:
Speaking of the back end, I was doing a live code streaming with Jesse Martin from Hasura this week, in fact. And of course Hasura and others like Prisma are these really easy, almost Heroku-like backends for GraphQL. They have their own databases. Hasura, I think, uses Postgres and whatnot. And they integrate them in a really cool way. You can edit them in a browser and things like that. I think that's really cool. What are your thoughts on services like that, platform as a service type things like that?
Eve Porcello:
I think they're great. I think Hasura is really pioneering in their subscriptions and what I mean by that is the real time data use cases. So I think everything they're working on over there is really exciting from a user perspective, because they're thinking how do we get this data as fast as possible to every client? Which is super cool.
Eve Porcello:
So on a similar line, Prisma is really great too. I think that if you are holding your data in a database, these can be really powerful tools. Both of them operate from a resolver first of approach, which just means we're thinking about the data first before we think about the schema.
Eve Porcello:
Apollo is schema first where you create schema to model your types. They go the other way where they're thinking, how do we create functions that return the data and then develop the schema from that? And I don't think one is better than the other. I think both have their place. Prisma has worked with some huge, huge companies, and so have has Hasura.
Eve Porcello:
They're modeling data for these big banks and places where these databases have existed for a really long time. So I think putting GraphQL in the picture is yielding a lot of performance benefits for these huge companies. And so that's the different approach there, where thinking about functions first versus schema first with Apollo, but both are really powerful in the right situations.
Robin Heinze:
You just mentioned performance. Are there any sort of performance gotchas or pitfalls? I mean, are we going to be seeing any bandwidth concerns on mobile with a lot of different requests? I know that comes up as a concern quite often.
Eve Porcello:
Yeah. I think the tendency can be sometimes we'll get working on a great UI, right? We're building our cool app and we start with a really small query that fetches data for a small part of the UI and we get a lot of performance benefits because we're not overfetching.
Eve Porcello:
Over time, sometimes those queries can get larger and a page might need, I don't know, 20, 30, 40 fields. And maybe those fields are pulling data from a bunch of different places. So performance wise, we always have to think about where's the data coming from? How long is it taking? What is the most critical data that we need to display? And as your queries get bigger just by the nature of how your page has growing data needs, there might be times when you find little performance bottlenecks.
Eve Porcello:
So a couple tools for that, that you can look at, number one is there's a tool called Apollo Studio. And Apollo Studio is free for a lot of their features and then paid beyond that. We know what software is, that's how it works, but I'm explaining all subscriptions. But essentially this gives you in addition to schema check-ins and things like that to work better on a team, it gives you metrics for how fast certain fields are performing.
Eve Porcello:
So if you have a UI that feels like, "Oh, this thing is loading super slow. I wonder why?" You can look at that and see that the email field is taking X number of seconds to load and you can start to track that stuff down. Another thing that's really exciting, particularly for React Native developers and front end developers is that we have defer and stream coming to the spec really soon. So defer and stream are these GraphQL directives that we can use to incrementally load data.
Eve Porcello:
So quick example of what that is defer is like lazy loading in a query. So let's say we have some fields at the top of the page that are super important for the user to see right when they load the page. I can load those fields first and I can defer the rest to load in the background so that it feels like my page is working and that's data is coming later. So that's defer, we can incrementally load our data that way.
Eve Porcello:
Similarly, there's something else coming to the GraphQL spec called stream. So stream allows you to, let's say we're loading a list of something, a list of posts. We can load the first three posts and it makes it look like, "Hey, this app is fast. This is cool." And then we can load the rest in the background. So as the queries get bigger, that performance feels like, "Oh, this is getting trickier because we are waiting on a lot of fields." But defer and stream are going to change a lot of that. And those are going to come very soon to the GraphQL spec and then will be implemented by all these different clients and servers.
Mazen Chami:
I love that feature. That sounds like it would be very beneficial, from a UI, UX perspective and even just from the performance, right?
Robin Heinze:
That's awesome.
Eve Porcello:
Yeah. It's very sensible and super exciting. So I'm always looking on the repo like, "Let's go, I want this." But people are donating their time so they can take their time. But yeah, it's great.
Robin Heinze:
I always love hearing about performance tooling too. Especially stuff that's visual or very easy to use because performance is so often something that people forget about or don't think about or avoid thinking about because they don't know how to even begin. So it's really nice that they're tooling built in. Down the same vein, testing. I know API testing usually has always been traditionally a pain. Are there any good tools around testing, unit testing, regression testing GraphQL APIs?
Eve Porcello:
A lot of the testing tools are the testing tools of that language with GraphQL. So GraphQL has all these implementations and various languages. You don't have to use JavaScript to build a GraphQL client or server, but traditionally you would test a GraphQL API just with Jest or React Testing Library or any of those things. GraphQL lend itself particularly well to testing just because you can test for, let's say you send a query, send an HTTP request with these fields. I expect to get this data back.
Eve Porcello:
That's very easy to think through how that would work and that's a pretty cool thing. As far as specific GraphQL testing libraries, I haven't seen a whole lot of that. Please correct me if I'm wrong. If anyone knows of any, I will steal them from you and use them. But I tend to see folks using their favorite testing library that already exists and using that for GraphQL testing.
Eve Porcello:
I will say that for mocking data there are a lot of great built in tools that you can use. So GraphQL schema is just a list of all of your APIs types, right? So if I have a user and I have a query called all users, it just returns a list of those users. A user is a specific type that has an ID and it has a name that's a string and it has an age that's an int, et cetera, et cetera.
Eve Porcello:
That lends itself particularly well to mocking. So if I'm working on a React Native app and the backend engineers or whoever's building the GraphQL API, they haven't set up the data sources yet. We can still use that schema and mock the data. So Apollo server has mocking tools. There's a package called GraphQL tools that has mocks. And there's a ton of these where you can load some fake data into your prototype and you can get building on that and actually create those queries and then worry about wiring up the data later. You don't have to be held up by the process by which you have to connect all those different data sources.
Robin Heinze:
That's awesome. I feel like mocking data is usually the most time consuming and frustrating part because it's always really brittle, so that's cool.
Eve Porcello:
Totally. So literally when you create it an Apollo server, you could make it one line of code, but usually if you're making it look nice, it's three. And then you can just pass into that constructor a schema and then you can say mocks true. And you got mocks, you're done. You can create your own custom mocks, which is fun as a whole thing. But essentially, you don't need to. You can just get going with mocks colon true, you're done.
Robin Heinze:
Three lines of code, let's not get out of hand here.
Eve Porcello:
I know. We should shorten it. I mean, that's a little excessive. I agree.
Jamon Holmgren:
My question is can you get GitHub Copilot to write it then it'll be way easier?
Eve Porcello:
Definitely.
Jamon Holmgren:
Robin's shaking her head.
Eve Porcello:
She's like, "Enough is enough."
Robin Heinze:
I come back from leave and all of a sudden the AI's taken my job.
Eve Porcello:
Yeah, exactly. Just trying to run us all out of our careers.
Mazen Chami:
I'm a big fan of TypeScript so I know you mentioned earlier that GraphQL does a good job of translating over your types. I'm guessing what that means is when you create your query, you set a type for that query. So, we talked about user, first name, last name, string, and then age is a number, does that automatically translate into the app? So once I do my use query fetch, so whatever application, let's use Apollo for example. When I get my data back, will that automatically translate down for mean TypeScript?
Eve Porcello:
So you can use your schema to actually generate types using tools like Apollo Codegen and there's GraphQL Codegen from the Guild. They're a very cool organization doing a lot of great open source work. So check out the Guild. The little pitch, I have nothing to do with it. But I think that because we have this type system plugged in, baked into our API, you can use code generation tools to generate types based on that. So that can be then used in your components to ensure that the types in your component are matching the types in your API.
Eve Porcello:
So that's one way you can do it. There's also the flip of that. So if you already have a typed UI, you can create a schema from that, which is cool. So Babel-Blade and some other tools for going the other way. Essentially, we're trying to create types all the way down and that's something I always tell people who are not that excited about GraphQL but love TypeScript is that, "Ooh, you can use everything for code generation and do a lot of cool automated work to ensure that those types are really reaching deep into the stack and making sure that you're..." That sounded creepy, but making sure that... You know what I meant. Making sure that the application is as strictly typed as possible end to end.
Jamon Holmgren:
That's pretty cool. Awesome. And last thing here, we are running out of time. I could ask you questions all day, but what resources would you recommend for people wanting to learn more about GraphQL? Obviously your book, Learning GraphQL, O'Reilly Media, but do you have other resources as well?
Eve Porcello:
Yeah, definitely. Howtographql.com is an old classic, not old, but a classic. Old in GraphQL term so three years old. And you can there learn full stack GraphQL for free. There's a bunch of cool tutorials there. Hasura has some wonderful tutorials on their website. I would highly recommend those. Those are overlooked in favor of others, so definitely check those out. There's a React Native tutorial that I just looked at yesterday that was recently updated. So that's a cool one there.
Eve Porcello:
I would also recommend Apollo Odyssey. So Apollo Odyssey is another free learning that you can look at to put together your full stack application. They're working on one for Apollo Federation where you can create GraphQL microservices that's coming soon. So there's a lot of free, great resources out there on GraphQL and graphql.org has some links to all of those as well if you want to check out the official documentation.
Mazen Chami:
When I was first getting into GraphQL, I did go through howtographql.com and they did a very good job of explaining it and that was also my intro to TypeScript. So I did it all in one and that was really good.
Eve Porcello:
Yeah. If you're looking to learn TypeScript, I feel like learning GraphQL and TypeScript together makes a lot of sense because some of the vocabulary translates unions and interfaces and things like that. So a lot of cool stuff.
Jamon Holmgren:
And obviously by Eve's book, that is the place to start I think. Go check that out. We'll have a link to it in the show notes. That's where to start learning GraphQL. Very cool. I'm going to have to wrap up here, unfortunately. So if you'd like to nerd out more about React Native of course, check out my Twitch stream, rn.live or youtube.infinite.red. I'll probably be doing some GraphQL stuff, more stuff because I obviously Jesse on and we'll have other guests. You can also join our Slack Community at community.infinite.red. There's a lot of GraphQL people in there and check that out. Where can people find you? Robin, by the way, welcome back. Where can people find you online?
Robin Heinze:
As always, I'm @robin_heinze on Twitter and I'm actually tweeting again. I took a break from tweeting, just like I took a break from working.
Jamon Holmgren:
Aren't those the same thing?
Robin Heinze:
Yes.
Eve Porcello:
The ultimate hard work is tweeting. Yes.
Jamon Holmgren:
Yeah. If you look at my Twitter thread, that's what you think. Yeah. Welcome back. It's great to have you back. Mazen, where can people find you online?
Mazen Chami:
@mazenchami.
Jamon Holmgren:
Perfect. And Eve?
Eve Porcello:
You can find me @eveporcello and at moonhighway.com.
Jamon Holmgren:
Perfect. And you can find me @jamonholmgren on Twitter. You can of course follow our Twitter account React Native Radio it's @ReactNativeRdio. Thanks so much Eve for joining us today. It was awesome to have you on and just learning more about GraphQL.
Jamon Holmgren:
We're going to have to have you on again, hopefully, if you are up for that. As always, thanks to our producer and editor, Todd Werth, our assistant editor and episode release coordinator, Jed Bartowski, our social media coordinator, Missy Warren, our designer, Justin Huskey, and our guest coordinator and official musician, Derek Greenberg. Thanks to our sponsor, Infinite Red. Check this out at infinite.red/reactnative. Special thanks to all of you for listening today. I really appreciate it. We all really appreciate it. Makes this worthwhile. Appreciate also all the love that we heard people asking when Robin's going to be back. Reminder, we are hiring careers.infinite.red. See you all next time.