Noel Minchow: Hello. Welcome to LogRocket. My name's Noel. I'm a dev here at LogRocket. With me today is Peggy Rayzis, senior director of developer experience at Apollo. I hope I got all that right. How's it going, Peggy? Peggy Rayzis: It's going great. Thanks so much for having me on the podcast. I'm really excited to chat about Graph QL and Apollo with you today. Noel Minchow: Nice. Yeah, we're big Apollo and GraphQL users here, so I'm excited to talk as well. I guess, yeah. To kind of get us rolling, can you just tell us a little bit about who you are, how you found yourself at Apollo, and your role there? Peggy Rayzis: Yeah, absolutely. So I lead developer experience at Apollo, and my org's mission is to inspire and equip developers everywhere to be successful with Apollo. And so we tackle that in a number of different ways. We have the education team, and they make sure every release ships with complete approachable documentation, as well as build out our learning platform, Odyssey. And so they're all about educating developers at scale. We also have an in-house video team that's under the developer experience org, because video has been a really big focus for us since the pandemic, obviously. And then we have developer relations, and they're all about helping developers at scale. They're out there in the community, listening to their pain points, and then either crafting content or code solutions in order to help them. Noel Minchow: Nice. Nice. Yeah. Sounds like you guys have a lot of avenues kind of at play at once. That's awesome. Yeah. We kind of... We understand. So maybe, I guess, to contextualize a little bit, I'm sure most listeners are familiar, but can you kind of set the stage? What is Apollo? What's it trying to do in the kind of the web client space? Peggy Rayzis: Yeah, so I think I'll kind of just start with like our north star and the problem that we're trying to solve, right? I think modern app development is complex, right? Developers, increasingly, to build features have to connect to a number of different data sources, whether it's a REST API or a database or GRPC, or maybe even some legacy infrastructure like a mainframe, right? And so then once you get all of that data in the form that you need, then you have to connect that to an increasing number of clients, whether it's a web app or mobile apps or IOT. And so it's really difficult to do that and keep pace with the change of innovation and everything that's constantly being asked of us developers. And so that's really where Apollo comes in, and we aim to simplify that process by helping developers build a super graph. And so a super graph is a unified network of all your data services and capabilities. Peggy Rayzis: It's a new layer of the stack that sits between your clients and your back end services. And it decouples that front end and back end development for you. It lets you delete a bunch of really complex data fetching code, and ultimately, it helps you get your ideas out into the world that much faster. Noel Minchow: Nice. So is this super graph kind of an aspiration of, or a goal maybe, of Graph QL in general, or is it like an Apollo target specifically? Peggy Rayzis: I think it's an opinionated way of doing GraphQL. So GraphQL, if you've used it before, it's just a spec, right? It's incredibly flexible. It's a language for communicating about data. You can implement that in a number of different ways, and a number of different programming languages, right? You can use it for service to service communication. You can use it as a layer over your database, right? There's plenty of kind of startups tackling that space, but we've been doing GraphQL for a really long time, right? It's got to be seven plus years at this point. And we've worked with, you know, thousands of developers and companies trying to do this at scale. And what we found is that the most effective way to implement GraphQL is to build out that super graph. And so there's a couple of principles kind of underlying the super graph. Peggy Rayzis: We believe it's one layer, right? You don't want to have multiple different layers, because then you're going to continue to do that data transformation on the client and have to write all that code, but we don't want it to be a monolith, right? It should be a modular architecture that's built into parts. And so Federation is kind of the underlying open technology behind the super graph that allows you to build out your super graph, your GraphQL schema in modules. And we also believe it should evolve over time, right? Products needs are constantly changing, right? We, as developers, have to be super flexible and adapt to that. So a lot of our super graph tooling makes it really easy for you to constantly change your schema. I mean, some of our customers are publishing changes to their super graph 30, 40 plus times per day. And so yeah, one layer, build it in parts, evolve it over time. Those are the three principles for the super graph. Noel Minchow: Nice. Yeah. So can we kind of break this down into the specific tools that you guys kind of maintain and send out into the world? So we have the Apollo server, is that really where most of the super graph work is happening? Peggy Rayzis: Some of it yes, but not all of it. So Apollo server is our JavaScript implementation of a GraphQL API. It's kind of, really our first sub graph framework. We call those kind of modular schema that make up the super graph, we call them sub graphs. And what's cool about Federation, which is that underlying graph composition technology, is you can use Apollo server, it works great, but you don't have to. It actually supports over 20 different languages and frameworks. So we have sub graphs that are compatible in Java and Kotlin and Python and Go and Ruby, right? You can choose whatever stack that fits your needs. Noel Minchow: Gotcha. Gotcha. But the Apollo server, the JavaScript server is open source, right? That's all available. Is this tech driving the super graph also open source and readily available? Peggy Rayzis: So, some of it is, yeah. So Apollo server is open source. Federation, the latest version of it, it is open source available, but it's licensed under ELv2. Noel Minchow: Got it. Got it. That makes sense to me. So, I guess can companies then, if they want to run super graph, can they do it themselves? Is that a way that you guys do it, or do you really want to be kind of hosting it and managing it? Peggy Rayzis: Yeah, absolutely. So you can absolutely use all the parts yourself and run it yourself. We also can manage that for you. A lot of folks have success doing it either way. Noel Minchow: Cool. Yeah. And then just to kind of help us get the whole landscape painted here. So then there's also the clients that you guys work on. How do those kind of play into the picture and help developers? Peggy Rayzis: Yeah, so we have several different clients, and they are open source libraries that help connect your super graph to your app. So we have Apollo client web. That's our most popular one. That's like 4 million weekly downloads, very widely known, especially by react developers. We also have iOS and Kotlin clients as well that are powering some of the largest mobile apps in the world. So a lot of us know us for our web stuff, but the mobile community in the GraphQL space is small, but mighty, and growing as well. Noel Minchow: Yeah. Nice, nice. That's awesome. I guess kind of one curiosity that I had, or maybe just kind of interesting concept is, I feel like developers coming from a REST background, we didn't really have as strong of a presence in the REST ecosystem as Apollo has established kind of in this GraphQL paradigm. Why do you think kind of being in this space of having an opinionated way to implement this standard has manifested in the way that it has here? Why didn't this really exist to this extent in the REST kind of era, and now it is coming to be? Peggy Rayzis: Yeah, it's a good question. It's one that maybe I don't have the exact answer to, except to say that I think the reason why Apollo has really resonated with developers is because we have always relentlessly focused on improving the developer experience and making folks lives easier. You really see it in kind of everything that we do, from our documentation to our learning materials. We want it to make it really easy for you to learn our technology from our open source libraries, right? We want it to be really delightful to build with our technology, and then our SAS as well, right? We want you to be able to ship it to production and give you the confidence that you need to be able to run that super graph safely. So I think maybe what's different now is just, from the rest to now, the GraphQL ecosystem is really just focusing on the needs of the app developers and championing them, and including their perspectives in everything that we build. Noel Minchow: Yeah. Nice, nice. That's an awesome answer. Do you think the paradigm itself has led to that at all? The way, the implementation of GraphQL has to be done on the back end is kind of pushing developers towards using a tool to help them more so than was going on with REST? I feel like often the case with REST was, a dev would come in, they'd use some server framework. It would give your REST API endpoint, REST endpoints. You would use them. It was kind of the... that was kind of all of the consideration you'd give to it, was like, "How are my objects shaped? I'm going to expose them as closely as I can via REST, and that's all I really think about it." Do you think that having another layer of kind of abstraction to figure out in the middle has pushed devs towards looking to another tool? Peggy Rayzis: Oh yeah, absolutely. And I think the interesting thing about GraphQL is it's primarily kind of this backend technology, but a lot of the interest for GraphQL comes from the front end developers, right? They hear about Apollo client, and they're like, "Okay, I want to delete all of my data fetching code and remove all of this complex Redux, hand spun data, fetching code for my app." And so they start kind of investigating that and falling down the GraphQL rabbit hole, and diving into the abstraction layer, and then having to suddenly learn about these backend concerns, like data modeling, putting together your schema, and then connecting it to the data sources. So, yeah, I think in order for GraphQL to succeed and for product developers to be able to implement it successfully, you need to have that great developer experience and guide them towards sensible defaults and giving them a path and making the right decisions to build a resilient performance super graph. Noel Minchow: Yeah. Do you ever see that as a challenge, just kind of in the GraphQL community in that it is a backend tool that has been really kind of shaped and requested by the front end people, developers? Peggy Rayzis: Yeah. I think... and it's certainly getting better, but certainly in the early days, I think when product developers were trying to adopt GraphQL, they were often met with a lot of resistance from the backend teams. They're like, "We already have these great REST APIs. Can't you just use these?" But I think once the backend developers understand that it's actually really healthy and good to build that GraphQL schema collaboratively up front, right? And before you start building, let's map out our data and write that schema. And then the backend developers can then build the resolvers and connect those to the data sources in a performant way. The front end developers can use that mock schema to build features independently. Then it decouples that fronted and back and work and really accelerates product development. Peggy Rayzis: I think once the backend developers feel included and see that in action, then a lot of their concerns start to go away, but it's definitely an uphill battle in the early days. I also think there is kind of a lot of maybe misconceptions early on. You would see a lot of GraphQL verse REST blog posts, right? They're always trying to pit these technologies against each other. I think that's sometimes what we do in order for clicks or to stimulate interesting discussion, right? But GraphQL is actually really great as a layer over REST. It's not like picking one or the other. It actually works really, really nicely kind of just as a layer over your REST API. So I think maybe some of kind of the early blog posts pitting the two technologies against each other, making developers think that they had to rewrite their entire systems and all their rest APIs when that's really not the case, I think that might have led to a little bit of confusion as well. Noel Minchow: Yeah, totally. Totally. Yeah, so that kind of leads me to an interesting question. Talking about the super graph and kind of having an even more, I don't know, regimented way of architecting the interface with your data, do you think that adds to that kind of hurdle at all? Like, "Okay, we're going to start writing GraphQL, and we're also going to do it in this manner so the model exists in this way." Do you think that is another, I don't know, little bit of rope that the front end is asking of those backend people. Peggy Rayzis: I don't know if it's a little bit of rope, more, I think actually the backend engineers really gravitate towards the idea of a super graph, because now instead of having a GraphQL monolith, a single point of failure, you have this distributed graph that's written in parts, and you can enforce healthy separation of concerns, and each team can kind of iterate on their slice of the graph independently. So I would actually say that the super graph gives backend engineers more confidence in the stack, as opposed to just building a GraphQL monolith. Noel Minchow: Nice, nice. Awesome. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple podcast. All right, back to the show. Noel Minchow: I'm curious there... I guess how... Say you're a new company getting started, and you're trying to figure out how you want to start moving data to the front end, or maybe you got a pretty basic API right now, and you're like, "Oh, we got to level this up and make it a little better," how do you recommend that those groups kind of go in and architect their data exchange layer? Presumably, we're using these tools, but how do they begin? Where do they do that modeling? Where do you start? Peggy Rayzis: So what we always recommend is start with the schema first, and maybe just pick one rest endpoint. Don't get too crazy. Don't try to stuff everything in this first GraphQL schema. You want to just take a very isolated use case, one endpoint, and build a really small schema around that. And so then once you have that schema, and both the front end teams and the back end teams agree upon that, then you want to just write some resolvers, connect that to the rest data source. And then once that's built, then you can connect that to the client, and it should be a really simple, straightforward process. So that's what we always recommend, is start small, start with one sub graph. Don't feel like you need to build five sub graphs right off the gate and all this complex data modeling and stuffing everything that's in your REST API into your schema. It should really be built upon your use cases and demand oriented, as opposed to maybe just autogenerated or stuffing everything inside. So, start small, iterate over time, and it'll kind of work itself out. Noel Minchow: Yeah. Nice. I guess. Okay, I'll bite a little bit here. I would postulate that many backend devs would be skeptical, that it will just kind of work itself out. If we're making bad design decisions here, we could be really messing ourselves up in the future. Are there any concerns that you... anything you would say, make sure that you are accounting for X, Y, Z, or anything that you'd ensure that, or want to recommend to backend teams to ensure that they're not going to wind up in some kind of, pinning themselves into a corner in some manner? Peggy Rayzis: Yeah, so I think obviously you got to be aware of the N plus one problem. You don't want to be, you know, inadvertently making too many downstream requests to your backend services. So Apollo server ships with a really nice abstraction called data sources, which has a built in resource cash for your REST APIs to alleviate that problem. There's also some more advanced libraries like data loader that you can use to solve that issue. A lot of our SAS actually helps with some of this, right? So you have Apollo Studio and you can wire up traces. So you can see exactly how long each of your resolvers are taking to resolve, and you can diagnose those performance issues before they become a problem in production. And once you have those metrics wired up, another really great way to have more confidence in your super graph is to be able to prevent breaking changes. Peggy Rayzis: So we have a feature that actually is free now, as of last month, so everyone should use it. It's called schema check. So it actually uses the live traffic against your API to make sure that any changes that you're making to your graph, whether that's adding fields, removing fields, making something nullable that used to be non-nullable, right? It'll check all of that against your production traffic and give you a thumbs up or thumbs down, integrate really nicely into GitHub with the PR process. And so that will also give you confidence in changing and evolving your graph, making sure that the changes that you're making aren't going to affect production. Noel Minchow: No, that's pretty cool. So is that schema check then helping ensure that, if there's a change that you need to publish to the front end before you start making back end changes, like you were doing that, I guess that order of operations of changing your graph is done correctly, where you're not going to end up with requests that start failing if a client's got an old version or something? Peggy Rayzis: Yes, yes, absolutely. And that's super important with mobile, right? Because with mobile apps, an old version could be on someone's phone forever, right? So you can kind of monitor the different clients that are making those requests and the percentage of each version, right? We have client versioning, so you can kind of pinpoint exactly which version of the client is making those requests. And yeah, just makes that process super seamless so you don't have to worry about shipping a breaking change to production. Noel Minchow: Nice. That's awesome. Yeah. And on that kind of that first tooling you mentioned where we can use the studio to go and figure out where the resolvers are slow and what's hanging you up, I can speak to that firsthand. We've used that all the time, and it's like, oh, this is super, super handy. Peggy Rayzis: Nice, nice. Noel Minchow: It's so easy. It's so often the case, there's just one errant resolver that's just going off and doing its thing. You're like, oh, obvious bug here. So, it's so helpful. Peggy Rayzis: And I think there's actually some really exciting developments happening with the GraphQL spec to kind of address some of those issues. Now with defer, you'll be able to kind of use that directive to indicate that it's okay if that data isn't here yet, defer that until that request comes back. So it's just another way that we'll be able to optimize and fine tune the performance of our GraphQL APIs. Noel Minchow: Nice. Yeah. That's interesting, and maybe a good segue. Does the defer logic, does that bubble all the way down to the client? Are clients aware of those, like, "Oh, this data maybe coming back later"? Peggy Rayzis: Yeah, so you would actually market on your query that you're making from the client, and you would just put that at defer directive next to the field that is slow. And so obviously you'll kind of need to handle those states within your app, but then that will propagate down to your sub graph and be able to kind of wait or defer until that request comes back and then send that chunk to the client. Noel Minchow: Nice. Can you give me an example of when that would be like useful? Peggy Rayzis: Yeah, absolutely. So like I mentioned, one of the use cases where GraphQL really shines as just connecting all of these disparate data sources. And a lot of our customers, particularly retailers, have had tremendous success actually connecting the super graph to their mainframes. So say you have kind of a really slow API or your mainframe technology, and you know that that field takes a while to resolve, you can just mark that defer directive on that field and you don't have to worry about waiting on that data to come back to send the rest of the response back to the client. Noel Minchow: Nice, nice. Awesome. While we're talking about the client, what other kind of cool stuff is on the short term roadmap for the clients that you guys are working on? What cool new front end tools are coming soon? Peggy Rayzis: Yeah, we have some new hooks coming in Apollo Client. I'm not sure if it's the next release or the release after, but use fragment and use background query are two new hooks that client developers will be able to use on the web. We just added some improvements to the mobile clients as well. So Apollo iOS is nearing the 1.0 release, and then also Apollo Kotlin added support for Kotlin multiplatform, as well as some caching improvements. So a lot of exciting developments happening to the client to just make that client developer experience even better. Noel Minchow: Nice. I guess, is there anything in particular that using Apollo client and Apollo server, using both of those versus just using server and writing your own client or using some other one? Is there any cool benefit to using both the devs might be stoked for that? Peggy Rayzis: Any cool benefits? Well, we have the client registration feature. So if you use Apollo client, and you also use our SAS Apollo studio, you can then register your versions of the client, and then those versions will show up in the metrics. So that's a really handy feature. The truth is, we built these tools to be very modular, right? You should choose the stack that fits your needs. We want you to have a great experience, whether you're using just client, just server, or both. So all of them are pretty modular and interchangeable. Noel Minchow: Nice. Nice. Yeah. I guess more broadly, is there any other kind of cool stuff on the horizon for you guys, if you want to talk about, or even changes to the standards that are coming down the pipe that you're excited to see? Peggy Rayzis: Yeah, absolutely. So one of the new super graph technologies that we just launched recently is the Apollo Router. And so previously, kind of the mechanism for taking that request and distributing that to the different subgraphs, that was Apollo Gateway, which was kind of a special version of Apollo Server, and so it was written in type script. And so we heard from a lot of our customers that either they weren't comfortable deploying node in a production environment, or they just kind of wanted a single binary. And so we built the Apollo Router. And so it's a really high performance rust router with sub millisecond latency, and it's just super cool. The team building it is so amazingly talented. And so we recently just released that into GA, and so I'm really excited for everyone building a super graph to get their hands on it and start using it, because it's really cool. Noel Minchow: Nice, nice. That's awesome. I'm somewhat surprised to hear that there were, I don't know, you guys had had customers or just users you were talking to that were hesitant to deploy a node router, but they're big Apollo people. That's surprising to me. Peggy Rayzis: Yeah. I mean, like I said, there's a lot of enterprise customers running a Java or Kotlin stack, so the languages are across the board. Obviously, the Gateway works really well, it's horizontally scalable, a lot of our really large customers are using it in production, but it's great to have the REST router be another option for folks and be able to open some more doors for people to adopt the super graph. Noel Minchow: Yeah. Nice, nice. So I guess, yeah, kind of my last line of question on this topic then is, for devs that are just starting to get into the space, they're mobile devs that are interested in making the switch, or they're web devs and they just haven't really had a reason to jump into GraphQL at all, anything you'd recommend for them, or anything you'd point them at? Peggy Rayzis: Yeah, absolutely. So definitely check out our learning platform, Odyssey. You can find it at apollographql.com/tutorials. And so we're really, really proud of Odyssey. It features 30 to 45 minute short courses. They have two to three minute short, snappy videos, along with code challenges to test your knowledge. And it's a really gentle, but complete introduction to the Apollo platform that will give you that real world practice. And so it's been around for, I guess, a little bit over a year now, and thousands of developers have completed these courses. We're really proud. So whenever a developer takes a course, the feedback survey gets sent to a slack channel, and we read every one. And the course quality rating is 9.5 out of 10, which obviously developers are a critical bunch sometimes, so to be able to achieve that and give them that really great experience, we're so proud of it. So, definitely check out Odyssey. The team that builds it is phenomenal, and you'll learn GraphQL and Apollo and have fun along the way. Noel Minchow: Nice, nice. That's awesome. Yeah. So then I kind of wanted to segue a little bit from that into your background. How did you find yourself in this kind of dev experience role at a kind of pseudo open source company? What did that look like? Peggy Rayzis: Yeah, it was an interesting journey. So prior to working at Apollo, I was an engineer at Major League Soccer, and we were a small team over there with a lot of different apps that we were responsible for. We were bringing the mobile app in house and building that with React Native. We also had this real time match experience app on the web. And so we did the whole rest to GraphQL transition over there, and it was incredible. We deleted these back in for front end services. We deleted all this Redux code, we could support the web and mobile apps with a single code base. It was incredible. And so I wrote a blog post for the Apollo blog on our experience, and then that kind of led to me being hired at the company to work on Apollo client as a open source engineer. Peggy Rayzis: And so I did that for about a year, worked on local state management, as well as kind of onboarding to Apollo client. And I was doing a lot of dev advocacy work kind of on the side. I was traveling to conferences and giving talks about Apollo client. I was doing workshops with some of our very first customers. And so my role just kind of gradually morphed into more of a dev role. And then adoption grew and grew, the team grew larger. And then the manager ended up leaving to take another role, and so they kind of split the open source team into two, and then I became the manager of the developer experience team and kind of gradually built it up over the past four years. So it's definitely been a interesting and fun and exciting journey, and yeah, I'm just very thankful for the experience, and also excited about our future. Noel Minchow: Nice. Did you guys have... Was there much of a focus developer advocacy team or group or anything in Apollo before that, or was this kind of the inception of it? Peggy Rayzis: This was the inception, yeah. It wasn't really... Everybody was kind of doing it on the side, writing blog posts and tweeting and stuff, but it wasn't anyone's full responsibility. And I think just that focus on open source and developer communities has always been a part of the company's DNA. Before it was Apollo, it was called Meteor. And Apollo... So Meteor was a popular JavaScript framework about seven plus years ago. And so Apollo started off as an experiment to rethink what the data layer could look like. And so they chose GraphQL and built the client and the server around it. And so Apollo was really a small team inside Meteor. And then as adoption grew and grew, the business pivoted, but open source and community have always been true to our roots, even before Apollo was the main focus. Noel Minchow: Nice. How do you think that kind of open source background or origin story affects how you guys think about dev and dev advocacy and stuff? Peggy Rayzis: I think it affects nearly every part of the company, right? I think every function, whether it's developers experience or marketing or product, we all realize that developer trust is so important to the company's success. And it takes years to build that up, and you can lose it in an instant. And so that's why it's really important for us to constantly be listening to developers, taking an account their feedback and trying to solve their pain points, and really champion them and give back to them, right? That's why we built Odyssey and made all of our learning experiences free. That's why we put on GraphQL summit, which is our big conference that we do for the GraphQL community. It's why we sponsor and encourage the development of these other sub graph frameworks in different languages, right? We're constantly trying to give back and empower our developer community, and it's core to everything that we do. Noel Minchow: Nice. Do you think it's easier to get feedback in general, than say you were a totally closed sourced proprietary software company? Peggy Rayzis: Yeah, absolutely. I mean, because a lot of the technology stack is open source, we're constantly getting feedback in GitHub issues and discussions, and getting poll requests as well from contributors looking to improve the software. So I think open source is definitely the way to go if you're building a modern dev tools business. Noel Minchow: Nice. Okay. Last kind of tricky question then. How do you balance that feedback that you're getting and poll requests that you're getting, or those issues that are getting a lot of traction on GitHub or whatever versus the work that you're trying to get done to keep the business growing in afloat and all that jazz, how does that balance play? Peggy Rayzis: I think they go hand in hand, right? Ultimately, what's going to improve the business and the experience for, the customers running the super graph at scale is also going to improve the experience for developers who are just getting started. So I think ultimately, improvements to the product and the commercial side kind of a rising tide lifts all boats, if you will, and also helps the community. At the end of the day, regardless of whether a feature is free and open source or enterprise, we're just trying to make developers lives easier, and so that feeds into everything that we do. Noel Minchow: Nice. Awesome. Yeah. Cool. And I just... It's cool to hear those kind of answers from people in roles like yours, where it seems to just be able to be done largely just cohesively. It just kind of all works, right? Having an open dialogue with the customers at a much more intimate level, if we can call GitHub communication intimate, then it is... and it's cool to hear that is able to be turned into improved products for the community. Yeah. Anyway, is there anything else kind of in Apollo at large that's coming up, or has been driven by recent developmental requests that you're excited to see? Peggy Rayzis: Let me think. Noel Minchow: I know we've talked about a lot already, so if not that's okay. Peggy Rayzis: Yeah. I feel like I've mentioned all of the big ones, at least the ones that I can talk about publicly. I think there are a lot of other exciting things coming that I can talk about publicly, but I would like to give a shameless plug. If you are interested in learning about the future of GraphQL or participating in the future of GraphQL, we're hosting GraphQL summit the first week of October in San Diego. Our CFP is open. I'm not sure if it'll be open by the time our episode airs, but there's going to be plenty of amazing talks, plenty of really exciting Apollo product improvements that we're really looking forward to sharing, and also product improvements from other GraphQL leaders in the space as well that I'm sure will also be talked about. So yeah, come to summit. I'd love to see you there. If you see me there, say hello. I love meeting GraphQL developers and sharing what we've learned with them. Noel Minchow: Awesome. Cool. Well, I guess, yeah. Thank you so much for coming on and chatting, Peggy. It's been a pleasure. Peggy Rayzis: Yeah, thanks for having me, Noel. It's been so much fun talking GraphQL and Apollo with you. Noel Minchow: Of course, of course. Yeah. Take it easy. Peggy Rayzis: Thanks. Speaker 4: Thanks For listening to PodRocket. You can find us @podrocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple podcasts. Thanks.