The Changelog: Software Development, Open Source - REST easy, GraphQL is here (Interview)

Episode Date: September 26, 2018

In this special rebroadcast of JS Party, Jerod and Suz talk with John Resig about how he's using GraphQL at Khan Academy, some of the mistakes and successes using GraphQL, John's feelings on jQuery, and community Q&A.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com and we're hosted on Linode servers. Head to Linode.com slash Changelog. This episode is brought to you by Vedri, a hiring marketplace that connects job seekers in tech with the hiring managers from top companies in the U.S. And I had a chance to talk with Brian Levy, VP of Product, about one of the most memorable and impactful things about the Job Seekers experience on Vetteri. Every candidate on Vetteri gets assigned their very own talent executive who guides them every step of the way.

The talent executives is an internal team that works with candidates as they're coming on the platform, helps them fill out their preferences. We get on the phone with job seekers and talk through their backgrounds and what they're looking for in their career. And then once job seekers are on the platform, we help them look into roles and companies that they're interviewing with and talk through offers that they get on the platform in order to make sure that they get tailored offers that meet their requirements and their career goals. It sounds like you're holding a candidate's hand through the whole process. Yeah, definitely. Working with a talent executive is essentially having a personal career

coach who can help you think through how does the job relate to your career goals, like what should I be asking for in an offer, what should I be doing to prepare for an interview? Essentially what a career coach would do. So it's often a very isolating experience. Vetteri has found a way to ensure that job seekers aren't alone in the process. Yeah, that's exactly right. And I think that it's really something that we hear a lot from job seekers on Vetteri is that working with a talent executive is often the thing that is most memorable and most impactful about their experience on vetery is that they have someone to bounce ideas off of who can help them think through

their career goals and decide is this the right company for me and if it is how am i going to land this job all right take that first step head to vetery.com slash changelog to learn more and get started also our listeners get a 500 signing bonus when you find your job through Vetteri. Once again, that's Vetteri, V-E-T-T-E-R-Y.com slash changelog. Hi, everyone. Tim Smith here, senior producer at ChLog. This week, we're bringing you a very special rebroadcast of JS Party, where Jared Santo and Suze Hinton talk with John Resnick. They covered how he's using GraphQL at Khan Academy, some of the mistakes and successes using GraphQL, his feelings on jQuery, and had John answer some community questions. Ah, yes, the sound of those beats means it's time once again for JS Party. Now, if you watch The Office, you already know that the first rule in roadside beat sales is that you put the most attractive beats on top.

The ones that make you pull the car over and go, wow, I need this beat right now. Those are the money beats. Special thanks to BMC, that's Breakmaster Cylinder, for helping us put the money beats right up top. My name is Jared Santo, and I'm happy to be here today. We have Suze with us. Suze, sit and say hi. Hello, coming to you from sunny Hawaii. Suze, you're in Hawaii, and I just got all jealous. Please tell us why. I'm very excited. This is the first day of my vacation. So I'm going to have a JavaScript party with y'all and then I'm going to go and have a party on the beach. That sounds better than what I'm going to do next for sure. I'm very excited. I haven't like gone on a big sort of travel vacation since 2011.

So I'm so freaking excited. Very cool. We appreciate you joining us from Hawaii and waking up extra early to kick off this party with us. But you had to be here for John Rezik. So special guest today, John Rezik. Y'all know who he is. He's here to talk about GraphQL. How is it? Why is excited about it? Why he thinks it's the new rest? John, thanks so much for joining us. Well, thank you so much for having me. So let's just get a little bit of a catch up with you and what you're up to these days. We know you've been working at Khan Academy for a while now is that still your day job and and what you've been up to yeah yeah so yeah I've been at Khan Academy now for a little over seven years and yeah so still

working there I'm these days my my role is as a front-end architect so thinking a lot about the you know systems that we're building and you know uh you know thinking about hard problems about like you know what sort of things do we need to have in place and to ensure that we can you know write stuff quickly and be scalable and but then additionally you know working on things like um you know sort of our like our design system and stuff like that um so it's it's pretty wide ranging but it's all very you know front and focus yeah in that i uh i really enjoy it i think yeah i think being there seven years is probably testament to that yeah i really really like it

it must be so cool to see how academy has changed as well in both product and technically over the last seven years. I think that's really a wonderful opportunity to have when you're so happy somewhere that you actually get to really be there to influence it, to evolve, but also just watch the audience change over time too. Absolutely. I mean, when I started, there was, I think, three, like I was the third engineer. And it was very, you know, the whole team was incredibly small. And then I forget how many users we had at that point. But, you know, at this point now, we have, you know, tens of millions of users every month from all over the world. And so the challenges of scaling up from those tiny beginnings up to where we are now has been very monumental.

And so I've really enjoyed, at least for myself, the technical challenge of working on these problems. But also, I really appreciate the sort of impact that we're having. Being able to bring educational materials to people all over the world for free. That's something that I feel very good about. So a little bit of insight into some of that impact, at least anecdotally with myself and my family. We're homeschoolers and we use Khan Academy extensively. And so we're very grateful for it. It's been instrumental in teaching our children.

So thank you very much for all your work there. Oh, fantastic. I'm glad to hear it. You're very welcome. Seven years, a long time in internet years. Like that's eternity. It must be very satisfying to keep you there that long. Yeah, it definitely is and it's i think it's nice because you know kind of as you know kind of kind of kind of me has grown

like i've i certainly feel like i've grown a lot too um i think one of the reasons why i decided to work at con academy in the first place is in in i guess this may come up later, but like when I joined Khan Academy, I stepped down from jQuery. Like I left the project and yeah, I left it in good hands, but like I was deliberately wanting to move on to be able to, you know, work on a product, you know, actually getting to, you know, ship something and get it out and out to users and, you know, have that sort of flow and that process. That's something I've been really

enjoying and really relishing. You'll be able to have excellent teams with people who are really good designers, engineers, front-end and back-end, QA people, and just being able to work on and ship really high-quality stuff is...

I don't know it's it's a lot of fun so that's something that you know uh i i feel like we haven't always been able to do that certainly back in the beginning it was much more loose and just you know everyone had to do everything but now we're you know we're larger ish and we're still less than 200 people but we're certainly a lot more professional and we're you know writing things that i'm very proud of that's the dream so john we have you here today not to talk about jquery but talk about graphql so con academy was a early adopter of react and now you have dove head deep into graphql you're so excited about it that you have a graphql guide which is a

seems to be an in progress but has some meat there book that you're writing with Lauren Sands Ramshaw. Tell us the backstory in the introduction, which we'll link up in the show notes, the introducing the GraphQL guidepost. You give kind of the insights into how GraphQL was exposed to your team there at Khan Academy and then some of the transition of like getting into it. Can you tell us that story? Sure. So at Khan Academy, I guess we take a very, I think, different approach to architectural decisions than maybe most organizations. So

like my role is I'm a front-end architect. I'm the front-end architect. But like, I don't dictate anything about what we do or what we should be doing, what technologies we should be choosing. I sort of see my role as a facilitator. So then if people are interested and excited about things, my job is to help them define it and refine it and get it to the point where we can start using it so for graphql that was a thing that had come up in a number of sort of a number of our front-end guild meetings where we we have these you know bi-weekly discussions with all the front-end folk there and we get to talk about things we're working on or interested in and graphql had come up a number of times people People had gone and seen different talks on GraphQL or read blog posts and started to experiment with it inside projects. And it was at that point that we were like, hey, this is pretty interesting. I think early on we were

looking at a number of different technologies like GraphQL, it's an interesting relay, and then Apollo came later on. And just all these different things were like, okay, how are these playing together? How are these interacting? And how is this compared to what we're doing right now with our REST APIs? And, you know, at least for us, you know, like we have a lot of REST APIs, both public and private. And maintaining them was a real project. And it was really hard for us to kind of understand sort of the data requirements that we had and that were that were

you know exist across all these different apis um so we we were we knew we were kind of interested in graphql but we needed to kind of understand whether or not this was going to work for us so what we ended up doing was a sort of uh a number of experiments um we we we hold hackathons at con academy and so during the hackathons we did some experimentation with trying out uh uh you know graphql on parts of our website and this was just you know it was not intended to ship it just obviously it's hackathon You're just doing something just to see if it works. But in that process, we're like, hey, this is pretty cool. So sort of the next phase of that was I was on the classroom team last year.

And so the classroom team is all developing products for teachers and students and in a classroom setting. And in there, we were going to be redesigning and redeveloping a number of our products. And I realized this is actually a really good opportunity to experiment with using GraphQL. Because since it's a greenfield opportunity

where we don't need to be relying upon existing REST APIs necessarily, we would be writing new ones anyway. So let's use this as a chance to define a GraphQL architecture, implement it, and start using it for these new products. So in doing so, it ended up working really, really well. As we were using this, we were just like, Hey, this is amazing. It's so much easier to use.

And then like we started talking, we on the classroom team started talking to other teams were like, okay, this is actually really legitimate. And we started to get other teams to kind of like start experimenting with, with their architectures. And then eventually, after a few months of this, we all kind of decided that this is actually what we want to be doing. That GraphQL is fundamentally so much better

than what REST has provided for us. So we were willing to put in the hard work of moving over, rewriting a lot of our APIs and all that. So this is still very much an ongoing process. We sort of have a mandate

now in place where we're using GraphQL for all new things that we're writing. And we're starting to convert existing things over to use GraphQL. But it's going to be a lot of work. So we'll see. I don't know when the day is going to arrive

that 100% of our rest of our APIs are gone and we're using GraphQL for everything. I mean, frankly, we're not even to that point yet with React. we still have some pages lingering somewhere on our website that are using like jQuery and stuff. So like, uh, we, you know, there's the process of cleaning out technical debt is a long one, but, but yeah. About how many REST APIs are you talking about here? Do you have like, you know, give us an order of magnitude, hundreds, thousands, I mean,

dozens. I think an order of magnitude, maybe like a hundred ish would be my guess um yeah and stuff and stuff that is both you know public and private so it feels like yeah the graphql guide is aimed to be that missing manual that you didn't have when you went through this with khan academy which is awesome because now other people can learn from this journey that you've been on. And I think it's also really refreshing for you to say that, well, this is an ongoing journey. And, you know, because a lot of people feel that they have to do everything all at once and that can be really scary. So I think that I really appreciate that you wanted to go back and actually then create this missing manual. Is that sort of the thought process you had? Yeah, I think it's a couple of things. One is having a missing manual. Is that sort of the thought process you had? Yeah, I think it's a couple of things.

One is having a missing manual. Well, I think there's a couple of things, which is that I think when we started using GraphQL versus now, there was just a lot more documentation and tools now than a year and a half ago, which is the reality of pretty much any new technology um but the additionally i wanted i was i was very interested in getting people excited about this technology like i was and am and so like i want i wanted to not only have there be a good resource for people to use,

but also just that I feel like there's some work to be done to even convince people that GraphQL is interesting in the first place. I'm convinced. But yeah, so I think part of the book is like, you know, explaining and looking at REST APIs, looking at GraphQL and looking at the benefits that GraphQL provides. So, yeah, so that's, yeah, that's where my heart and mind is at. It's always interesting seeing large software companies adopt these new technologies, especially when Facebook came out and announced GraphQL and released it. They had already had a successful track record with React, but then they also had Relay, and they wanted everybody to use Relay. That hasn't panned

out quite as well. But with GraphQL, I think you had early signs of success when GitHub decided that GraphQL was worth them investing in. And now we see Khan Academy, especially yourself, John, writing a book about GraphQL. That's going to, I think, sway a lot of people to, if they were just saying, yeah, no big deal, to take a look at it. Is that some of your intention? And then why would you necessarily want that to be the case so that it has a a brighter future i so i think one of the things

that has been most changing for me and again like i have i will say that i just have an extremely heavy front-end bias API mechanic you can have. And so at least for me, the more GraphQL that's out there, the easier it's going to be for developers, front-end developers especially, to interact and use different APIs. When we use GraphQL and we're developing new products, the rate at which we can iterate and prototype is so much faster than with REST APIs. At least with how we had our REST APIs designed,

you would specify your data requirements on the server side and say, okay, we need to get these fields from these models and pass them up into, you know, a JSON object and send it up to the client. And whereas with GraphQL, you're defining your schema. You're saying, okay, this is your model

and what properties exist on it. And then on the client, you're saying okay these this is your model and what what properties exist on it and then on the client you're specifying and it completely changes everything now instead of having to do some server-side like if you want a property that's missing you have to change some server-side code with the rest api then go to the client and then you, and then change what the fields you're getting. Whereas now with GraphQL, you can just do all in the client. Since everything's been specified in the schema, you can just say, hey, I need the username here. I wasn't getting it before, but now I want it.

You just add it in, and there it is. So in that way, your ability to iterate is so dramatically improved. And you can just get stuff out very fast. And so that's great for us. We're working with designers, and we're doing a lot of testing in schools. And we can just try stuff out, get it out there, experiment, get the results back, and just keep iterating again and again. So, yeah, I think that's something that's worked out very, very well for us. This episode is brought to you by Raygun, who just launched their APM service.

It was built with the developer and DevOps in mind. They're leading with first-class support for.NET apps, also available as an Azure app service, and have plans to support.NET Core, followed by Java and Ruby in the near future. After doing a ton of competitive research between the current APM providers, where Raygun APM excels is the level of detail they're surfacing. New Relic and App Dynamics for example are more business oriented where Raygun has been built for developers and DevOps. The level of detail provided in the traces are amazing, the flame charts are awesome, and allows you to actively solve problems and dramatically boost your team's efficiency when diagnosing problems. Deep dive into root cause with automatic links back to source for an unbeatable issue resolution workflow.

Learn more and get started at Raygun.com slash APM. Once again, Raygun.com. So as you've been doing these iterations, has there been anything that's popped up that you didn't expect to run into with GraphQL? Like such as the way you write schemas or even just like how those queries end up connecting on the backend? Or is there any sort of little pearls

that came out of it that you can share with us today? So I will mention that at least at Icon Academy, we... So I think we're probably different from most shops that use or would be using GraphQL, which is that our backend is on Google App Engine and we use Python for our backend. I suspect that probably a lot of people who are using or would end up using GraphQL are going to be probably with a Node.js backend of some sort. I don't know what platform they were running on. So yeah, I think some of the things that we learned were sort of about the differences in server-side implementation. And I think there may be some things that we are maybe a little bit envious now.

I've been seeing the exciting news and stuff coming out about Apollo Server, for example, and all sorts of really interesting caching mechanisms and things like that that are there but you have to be using apollo server and kind of have it integrated in your stack whereas for us that would be challenging to do um and uh so yeah i think so yeah i don't know i i don't have a good answer this at this point point, other than to say that, yeah, I suspect that if you're sticking in no JS land,

you're going to have a really good time. And if you're kind of skirting out the edges, like we are, like with Python and Graphene and things like that, you can definitely make things work, and we are. It's just that it's going to be a little bit different. And at Khan Academy, we're also starting to experiment with Kotlin as a server-side language.

And I'm not sure what their GraphQL story is like, but it can't be better than what's happening in Python. I can almost guarantee that. So yeah, anyway, I think the, yeah, that's something that we've been learning and actively learning. But yeah, at least in my side projects where I've been using GraphQL,

it's been very smooth sailing and I've enjoyed that. That's great. Is this something that you're covering a little bit more in your guide as well? Yes, absolutely. So yeah, covering many of the different client-side implementations and many of the different server-side implementations. We do have a bias towards sort of the primary stack, I want to say,

where a Node.js backend and a frontend that's using React. Because I think that's something that a lot of people are probably going to be using who are using GraphQL. But we do cover a lot of the other options as well. Because that's the nice thing about GraphQL is that it's relatively generic. Nothing about GraphQL dictates that you have to be using React or using Node.js.

And what's interesting is that we're using Python on our backend, and on our frontend, we're actually going through old pages of our site and replacing REST API calls or GraphQL calls. And some of those pages are older. They aren't using the latest you know apollo and all these wonderful frameworks um so but we've kind of you know created little shims where we can stick these graphql calls in and so it's yeah you you can really make it work um you know wherever you want it to run no matter what technology stack you have so yeah i think i think that's something that's um that's nice. And I think people don't necessarily always realize that.

I can speak a little bit to the backend ecosystem because just as part of my work at Changelog and Changelog News, we obviously keep our thumb on the pulse of what's going around in as much of a polyglot way as we can. And I would say in the last 18 months or so across many of the different ecosystems,

I mean, Node was very early and often in terms of tooling and support for GraphQL backends. But I've seen a lot of advancements in the Elixir ecosystem, in Ruby, as well as Python. So there's just a lot going on and a lot of the different backend technologies are racing to get their tooling and support for building GraphQL APIs as solid and quality as they can.

So you've definitely seen a groundswell of support across different ecosystems. So John, what else from the front end? So this is obviously where you focus. And so a lot of your, you graph QL was just so much better, like so much better than rust from your guys' perspective. So I guess just, I know you've mentioned a few pieces of it, but maybe a chance just to sing his praises and enumerate all the ways, you know, let me count the ways that graph QL has won you over on the front

end. Like what's the biggest wins and how many are there? So I mentioned rapid prototyping, but I think one of the things that so shocked me about, uh, uh, graph QL was that when you have your queries defined on the client or, you know, your JavaScript code, um, you can statically analyze the queries. So the benefit of this is that we have linting rules set up where if there are any changes to

a GraphQL schema or something like that, and it's going to cause one of our queries to break, and it'll produce an error about that. Now, the cool thing about this is that it allows us to refactor our APIs, our GraphQL, in ways that were never possible with our REST APIs. Because with the REST API, Because with the REST API, at least the ones we had, it was just like, okay, here's a JSON blob. We don't know what data is

being accessed or how it's being used or where it's being used. So therefore, we don't know if it's ever safe to remove any data. If we want to rework our API and be like, can we delete this data can we rework this schema etc it's just it's an it's a huge very frustrating

project whereas with graphql um you can do that static analysis and just be like and i and i we've done this where you're like oh shoot i want to rename this property to be more descriptive. So you rename it, you run the linter and you get a nice little list there of every file that's breaking. Now you go through, make, change those names and you're done. And so like the refactoring process seems like that. It takes minutes as opposed to, well, hours and things just breaking in weird ways that you can't quantify. So this is something that is, for me, when I saw that, I was just like, okay, that makes all this worth it. It's the sort of thing that is truly important.

And now I think one of the technologies we've been using a lot at Academy additionally is flow, with flow types. So the nice part is that if you have, you know, this GraphQL data come in, you can define the flow types for the graph to all data structure, then you can sort of trace a whole path through your application. So again, if we change the name of one of these props, I can just go change that in the flow type definition. And now I can see every single place in my application that's breaking as a result of that. So this sort of stuff that, again, it's making refactoring possible in ways that really just weren't feasible before.

So this is something that really things that have excited me from a front-end perspective about GraphQL, I think I've really enjoyed the Apollo client-side implementation. and it makes it really nice to really understand things about like loading states uh error states all this sort of stuff and i a good side effect of this is that it encourages you to write your react components in a way that are very robust to changes. Because your data could be in a loading state or an error state. You have to account for that. And I feel like in a Rust world, it's very easy to write something where you're just like, oh, we're going to get some data, and then never handle the data failing. And in the Apollo world, I feel you you kind of have to do it like it's it's

defined explicitly and especially if you're using things like flow types um you know like you can verify you you have to make your code more robust um which is good it's it's better coding practices frankly and and so that's something that I've also really enjoyed is that like, I feel like the quality of the components that we're building that use GraphQL are just better than what we were building in Rustland, because we're able to enforce these really good practices from the start. Speaking of like sort of enforcing things from the start, I had a question just about backend data and setting up databases and things like that. You're obviously on a journey where you're taking like existing data structures on the backend and you're getting it to work with GraphQL. Is there anything that people should do

differently if let's say they know immediately from the get-go that they're going to be using GraphQL? Do you have any advice on how backend developers could set up their databases and their data structures in the first place on the backend in order for it to be as easy as possible to work the GraphQL? I know that it's obviously like a very generic technology, but are there any sort of nuances in there that you can share? That's an interesting question. It's not something I've had a ton of experience with honestly but the in as i've played around with grep tool and and

extremely with it it's i guess it it's really felt like it's pretty it is able to handle lots of different cases and lots of different database styles or querying mechanics. I think generally it does work better or it's a little bit better suited to just sort of document-centric databases. When I've gone through and implemented GraphQL on top of MongoDB or something like that, it's really, really simple. It couldn't possibly be much simpler.

And it's a little more work for something like if you're doing it on a SQL database or something. But again, it's not insurmountable at all. So yeah, I think the... Yeah, unfortunately, I don't feel like I have very good advice here to give specifically. And I wouldn't be surprised... This is something I haven't done much research into at this point,

but it wouldn't surprise me if there are people building just databases designed for GraphQL at this point, or all-in-one type of deals that are designed for, you know, performance and cash and all these sort of things from the get go. So you don't have to roll them on your own. But that's something I haven't done a lot of research into at this point.

Yeah, I think there's a certain, you know, I think you're very lucky if you are actually entering now and you're starting something from scratch, which generally isn't always the very common case, right? Like unless you're a startup that just exploded onto the scene right now, you're going to be dealing with like transitions and things like that, which is very similar to what you're going through at Khan Academy. But it's good to know that there are some sort of cases or situations where it is a lot easier to get started immediately. That's cool to know. So from the front end perspective, and I've had a few of these conversations,

we can link up a few old changelog episodes, but not even that old. We had a Prisma and GraphQL episode just this spring even about GraphQL and talked to about it with a lot of people. And it seems like from the front end, it is demonstrably and maybe even say objectively better in terms of, like you said, prototyping, speed of development. I didn't realize this point about refactoring, which is really cool. But it seems like on the back end, building the back end,

dealing with caching dealing with perhaps uh inappropriate or like poorly crafted queries it's like that's kind of where the there be dragons are i know you've been very much on the front end of the con academy team but has that been a real issue like it is put differently like is the back end team or the people who are doing both as excited as you are? Or is it like the frontend is driving this and the backend is just along for the ride? Yeah, so it's interesting. So I think a couple of things that I want to caveat the work that we've been doing with is that so far we have not exposed our GraphQL stuff publicly.

So we have not replaced our public REST APIs with GraphQL yet. That's going to be a process in and of itself, but we are not letting people write arbitrary GraphQL against our servers. I would be...

I think that's something... If I'm not correctly, GitHub allows people to do that. I'm very curious to hear about how they do that in a way that they feel safe. But the, you know, we, at least so far, that has not been a priority for us. Now, additionally, one thing that we do is we have lots of monitoring and logging for all of our GraphQL queries. So we track the performance of every query. We track this performance over time. And then we have alerts for when queries are being especially slow. So then that way we can look

at them and be like, hey, this query is taking like five seconds. That seems excessive. What can we do to make this faster? And then so we can, with this data, we can delegate this to the teams to work on and approve. But at least so far, what's interesting is that initially the,

the front end team, we were championing this. We're like, we really want this to make our lives easier. And like, but I think that an interesting part about, you know, the graph you all switch here is that the backend team now is very excited

about this change too. And one of the reasons for this is that it dramatically simplifies the backend because previously we would have okay we have a rest endpoint and you know we're getting some information about a teacher and their students or something like that um and within that single rest endpoint is many different queries you know data being transformed and mutated and like all this of stuff, and then it gets mushed back into a JSON blob and put out. This code ends up being pretty complicated. It's hard to look at and reason about,

and especially when you have a number of endpoints that are doing very similar things, but just getting data or displaying the data in slightly different ways. But whereas in GraphQL land, since you define a schema, just a generic schema, this is the sort of thing that pretty much anyone can do. You know, like front-end engineer, back-end engineer,

it's relatively easy to write these schemas. And then once you have that, you don't really have to worry about the logic of mutating this data into a good form. GraphQL just takes care of that for you. So in a lot of ways, it's made a lot of our data structures much, much easier to understand. And the backend team has been excited about that because it's reducing the surface area of the application. So now they can just look at one place and be like,

well, the only place where this data model is being used is in this one GraphQL schema, and that's it. And we can just look at that one place and understand how it's being used entirely, as opposed to trying to hunt around the application to all the different REST APIs that could be using this thing. It's very, very complicated.

And so, yeah, so I think this is something that they're seeing as a way to reduce the amount of code that we have, the amount of service area, and just simplify things overall. That's interesting. I find myself often, so I often do small teams or sometimes team of one style projects.

So very often I'm the consumer of my own REST APIs. And so I only have to nag myself for slightly different data or a new endpoint, right? But I still have that mental back and forth of like, oh, I guess I need the data this way. I'm going to go add an endpoint or adjust an endpoint to massage it to be better. And I have worked in a situation where I was contracting

to build a backend API for a startup that had multiple devices, right? So they had an iOS app as well as a web app were the first two. They weren't quite successful enough to make it to their eventual Android app situation. But in that circumstance, it was me, a contractor, working on theck of development speed there, it is the integration point between those two actors. And the slowdown when they are waiting on me or vice versa was troublesome. And I could see where if it was a GraphQL API with a well-defined schema, that a lot of the stuff that they were waiting on me for, waiting on backend for, they wouldn't have to wait. They would just change the way the query worked. And as long as the schema supported that, then they would have been off to the races.

And so have you felt less communication lag or maybe tension between, I don't know how big your teams are, if you have walls and whatnot between them? I know some companies have very strong walls between teams. What are your thoughts on that? Yeah, so one thing I'll mention briefly is that we do have a front-end team and back-end team, and we do have people who are full stack. But the thing is, additionally, we're pretty porous.

Front-end people are making back-end changes. Back-end people are making front-end changes. That's the way it should be, right? And so we aren't one of those super strict organizations. I think some people just may have preferences of just doing front-end or back-end. And as a result, they do less. But yeah, I think one of the things that's been interesting is that even in cases where a front-end engineer has had to go in and add in an additional field to the scheme um i would say that it's just easier to do in general even compared with how we had things previously uh so even even in the worst

case um where a front-end engineer has to make back-end changes frankly any any of our engineers is capable of that from our most junior to senior um and i think that's something that is it feels empowering you don't have to wait and rely upon you know getting a you know a more senior engineer or back an engineer in to go work on this but i think i think the thing is that the far more common case is just like oh we're just missing this field but it already exists in the schema so we just add it in and now we're done. That's the sort of thing that is, yeah, the velocity impact is tremendous. And of course, that's helping the individual engineers so they don't have to go to the back end or wait on someone else to finish it. Whatever the case might be. So yeah, it's, it's been pretty great.

This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started at linode.com slash changelog. Pick a plan, pick a distro, and pick a location. And in minutes, deploy your Linode cloud server. Get $20 in hosting credit that's four months free. Once again, linode.com slash changelog. And by Rollbar, catch your errors before your users do. Resolve your errors in minutes. Deploy with confidence. Move fast and fix things like we do here at changelog because of Rollbar. Catch your errors before your users do. Resolve your errors in minutes. Deploy with confidence.

Move fast and fix things like we do here at Changelog because of Rollbar. Head to rollbar.com slash changelog. Once again, rollbar.com slash changelog. So John, we have some really cool community questions from our JS Party slash changelog community for you. So we're going to read some of them out to you on this segment. So the first question is from Dan McLean. He says, without subscriptions, what's the benefit of GraphQL over REST?

With HTTP2, you get muxing of connections, so the limit of open connections is higher, somewhat negating the benefit of grouping queries. And the pain point comes when one of those queries is slow in that group, causing your whole payload to be delayed until your slowest query returns, which is arguably worse than firing off 10 REST requests. So I think the first part was the question, which is like, what is the benefit of it over REST if you don't have the HTTP bottlenecks, it seems. So this is less probably about the user experience, I guess, on the surface layer? Yeah, I think, so there's a couple things. One is that GraphQL queries don't necessarily have to wait until everything is done before returning.

Like, I know that, like, Apollo and, like, with, like, Apollo Server, you can do, like, like, you can start to return data in batches. So you can get some of the initial layers of requests and return those and keep returning more as you get deeper and deeper. So it isn't necessarily the case that it's an all or nothing proposition with GraphQL.

Certainly the simple implementation would be all or nothing. But looking at a lot of the different tech stacks that exist now, like Apollo Server, they're much more robust and can handle incremental data. So, and I think the... I guess that's sort of the question about performance. So I think one of the things that is certainly a little bit tricky, it's one thing that's trickier with GraphQL

than with traditional REST APIs, is that I guess typically with traditional REST APIs, especially ones that aren't authenticated, it's a lot easier to do client-side caching or not client-side, but like, you know, browser-based caching or, you know, caching at an edge cache or something like that. Whereas with GraphQL, since typically you have a single endpoint, it's hard to do caching at that level. So usually what you end up having to do is

either having a different sort of client-side cache in browser. And we use Apollo, and in that case, it caches the data that we've requested. And if it looks like we're going to try re-requesting data that we already have, it just pulls from that cache data so we don't have to send off another request. And then additionally, you can do caching on the server side, but it's lower level at the software level.

So you can see that you have certain queries coming in. And if you know that certain data is always going to come back, you can just return that cache response. So yeah, I think there are definitely ways of improving the performance and improving the caching of GraphQL. I think one of the things, though, is that it's just going to work in a different way than what typically happens with a normal Rust API. So I guess as a side question or follow-up for that,

I guess it's more of a side question. Dan says without subscriptions, but he's now assuming that we all know what subscriptions are in the context of GraphQL. Can you explain what subscriptions are? Sitting here trying to explain and explain what I mean, you know, essentially you can subscribe to a data source and get, you know, periodic updates and, you know, being able to, you know, so that, you know, as more and more data comes in, it gets updated with that additional

data. The subscriptions are a little bit different from what I was describing before with the Apollo server, which is like a single query, but then the data that you're returning is complex. It's coming from multiple different queries, subqueries, and stuff like that. And in that case, that is coming back,

could potentially come back incrementally as the data is ready. Whereas a subscription is more like you would use a subscription to like implement like a chat room or something like that. Or like, you know, like where there's lots of updates coming in or like, you know, a stock ticker feed or I don't know, something where you have like, you know. So it's more like a real-time connection that gets pushed data from the GraphQL server? Yeah. Yeah, yeah. So that's more what the subscription is rather than the other thing I was describing.

Gotcha. Very good. Okay, next question from the community. This one comes from Dylan Shiman, who listeners may remember from the Dojo episode back on JS Party number 25. Dylan says, so jQuery, that's like a query language for graphql right um yeah it's funny because yeah dylan and i go way back because we were um you know he was working on dojo i was working on jquery like like all of us you know i guess yeah at this point old-timer javascript framework folk you know like yeah so in our chat room he mentioned that you guys have been trolling each other for years so he thought

that would be appropriate um but i think it's funny it's like one of those things where like we you know at the time it was like it felt the competition felt intense or at least where it's just like oh man we're trying to like change things and get recognition and like all this sort of stuff. And like, um, and then, but then like as things have changed and as the world has changed and everything, we're just, we're kind of, now we just look back at those times. We'll be like, Oh yeah, that was, that was a thing that was happening. And, uh, but yeah, no was a thing that was happening. But yeah, no.

I think I will mention though, he's jokingly saying this jQuery thing for creating GraphQL databases, but back when I named jQuery, my first name was jSelect, just for JavaScript select. But the domain was taken, JSelect, and just for JavaScript Select. But I couldn't, the domain was taken, so I didn't choose that. And I saw that jQuery was available, but

there was an open source project called jQuery, and it was like a Java library for doing SQL queries or something like that. And it looked like it hadn't been updated in a while, so I was like, okay, it's fine, I can just use this name.

The domain's available. I'll get the domain, and I can use it. And then I remember at some point late... Oh, sorry, was that you? No, no, keep going, sorry. At some point in the future, the person running the open source project got in touch with me and was like,

hey, you're kind of using my name. I'm like, oh, sorry. I thought the project was dead. I didn't realize that it was like still going on um but the thing is that like yeah obviously i i i feel pretty certain that like yeah uh web-based jquery is far more popular than the jquery java sequel querying thing but yeah i did feel a little bit bad about that. This is such a classic

naming problem. You know what I mean? Like, is the domain available? Is there already a project called this? You know, these days it's like, is the name taken on NPM? You know? Right. The age-old programming problem is naming things and cache invalidation. And I'll buy one errors.

Okay, soylan does actually have a serious question following up on his troll which actually plays into some of the stuff you're talking about there john about jquery so uh he says he's curious to find out what you think of jquery's place in js history now do you have regrets with the project would you go back and focus more on architecture type problems with jquery before things got out of hand for people trying to build large apps or do you see it as a good bridge for people from the days of old to the vDOM based dev? I do see it as a relatively good bridge. I mean it's certainly of its time where you know jQuery was so DOM centric like you are creating dom elements,

manipulating those elements directly. Certainly, whenever I do stuff like that these days, it feels very antiquated. And I think the...

I don't know. I don't... Personally, I don't have. I don't personally, I don't have regrets about not doing architectural things. And it's not because I feel like I

missed out. It's that at the time, I made very deliberate decisions not to work on that. We knew that J.A. Carter was not it was not it was opinionated in some ways that you know this is ways of querying Don Melvin's and things but like it was not opinionated about how you built your application you could build it in any way you wanted you could use jQuery in that context but we weren't dictating how that should work. So I think the, I'm okay

with this. Like I, and like, if you look at like React, and I think, you know, as mentioned earlier that, you know, we were early adopters of React at Khan Academy, but we were, I believe the first organization outside of Facebook to adopt React. And React is so dramatically different from the jQuery way of doing things. I don't think we could have ever have iterated on jQuery to the point at which we arrived at React. It's just a fundamentally different branch of the evolutionary tree.

And frankly, I feel like React is a lot better for the kind of things it's trying to do. And, you know, these days, as a front-end dev, I feel like I'm much, much happier trying to build the complex things that I'm trying to build than I was a long time ago. And it isn't necessarily because of jQuery, it's just because that we as an industry have dramatically changed how we're doing things and what we're willing to consider to be acceptable. And I think it's such a, the industry is growing up.

And a part of that is, you know, having, you know, a lot of these frameworks that take care of things for you. So yeah, I don't know. I don't, yeah, I don't have regrets about it. I think jQuery was great. It did a very good thing for a lot of people and yeah i certainly enjoyed using it and and really that's

when i first created it that's all i wanted i just wanted a framework that would uh solve my problems um um so yeah but the um yeah no i'm. I sleep fine at night. As you should. Our next question comes from Louis Montez. It relates a little bit to Dan's question earlier. So it's about like REST versus HTTP and the advantages outside of that. So they ask, since we've had things like JSON RPC

over WebSockets for years, how much of the GraphQL as the new REST, quote unquote, comes from REST being typically tied to HTTP while GraphQL is transport agnostic? I think that's a great point. They're asking, is the query language itself the killer feature? Yeah, I think so. I mean, I think the query language is really good because a lot of the features that I describe are benefiting directly from that.

Being able to specify the query on the client side, being able to do static analysis, all these sort of things. So that's certainly a benefit i think addition additionally you know having a schema defined on the back end you know so like you have the scheme on the back end the queries in the front end and like those two together really make graphql what it is um so yeah i don't i don't think the transport layer, frankly, as I'm developing and using GraphQL, I don't think about how things are, how it's getting to the client necessarily. That's not my primary concern.

My primary concern is more about, okay, what data am I requesting? Is it the data that I need? So yeah, and I feel pretty good about that. So yeah, I think, so just to answer your question, yeah, I would feel pretty good about that. Yeah, so they, yeah, I think, so just to answer your question, yeah, I would agree that probably the query language itself combined, but then combined with,

you know, the schema definitions is really what makes GraphQL special. That makes a lot of sense. Next question comes from Chris, aka Canada Uni in our js party chat room that chris was just talking about an aeropress project uh to learn apollo stack with graphql we were talking about coffee during the break so uh chris very much into that conversation uh chris has a thought a question and a concern so i'll kind of give them to you in that order uh the

thought is it was really easy to set up a Node server with the new Apollo server. So good to hear that. The question is, when should someone not use GraphQL? So, I mean, personally, this is my opinion. I don't, I'm not convinced yet about using GraphQL for a project where you are the only developer working on it. If you're just building a thing for yourself and you're doing the front end and the back end and

everything, you can probably get some benefit from GraphQL, but I think there's going to be diminishing returns. I think you're going to get the most benefit from GraphQL when you're on a team of engineers and you're trying to all share and use the same API. Additionally, I'm also not sold about using GraphQL for a public-facing API. I know there are people who do it and more power to them. It just seems like an unnecessarily complicated thing to implement, especially

since you're letting people run semi-arbitrary queries against your data. That's the sort of thing that you need to be very, very vigilant about. So yeah, I think those are two things that, at least

to me, I still have questions about. And yeah, at least the more common case of having a team of engineers working against a single GraphQL endpoint, it's amazing. It couldn't be better. And in that way you know rest is really uh it looks a bit inferior finally chris shares a concern which maybe you can just react to or not they say sometimes it feels like there is too much magic making it challenging to troubleshoot sometimes maybe that's just with ap. Um, but that has been my experience. Hmm. Interesting.

Uh, I'm trying to think of like issues that we've hit as we've like used Apollo stuff and we have it at some, I think the, the issues that we've had have been more like when we're like upgrading, um, like moving from one version to another and things start breaking in ways that we don't understand.

Um, this is how it only happened maybe once or twice. moving from one version to another, and things start breaking in ways that we don't understand. This has only happened maybe once or twice so far. And it just requires a little bit of debugging and trying to figure out how a different state is moving around in different ways. I think usually issues like that are happening, if they happen at all are happening in like the very complicated parts of our application um so maybe that also kind of speaks to us that that we should just be our application should be simpler but the uh and then therefore be easier to reason about. But yeah, I don't know much about it.

So our last question is from Rasmus Hansen. And they ask, what are some common mistakes people make when working with or implementing GraphQL? I feel like I don't have enough data looking at like what people, like people at large, what mistakes they've made. I think the, I feel like there were mistakes that we made. Yeah, we would love to hear that. Yeah, personal anecdotes would be amazing.

Absolutely. I think one of the, I mentioned earlier about how we have like tracking set up now for the GraphQL queries to know how long they're taking. And that isn't something that we had initially, nor was it something that came out of the box. figuring out which queries were taking a long time and why, and, or even understanding which queries might get slower given the different parameters that get passed to them. So that's the sort of thing that is,

I'm not sure it's a mistake that we made other than that, like as we were using GraphQL, we were kind of realizing that like we just didn't have the information that we needed to write good queries and so we kind of built an additional layer on top to like do this analysis um talking about other mistakes that we made i think well i should say one mistake that we I feel like we didn't make and, uh, but like we could have is that we didn't adopt GraphQL too early. Um, like I think now is now is probably, um, you know, the best time to be adopting GraphQL. Uh, you know, we adopted a year and a half ago you know it was certainly rougher i think if we had

tried to adopt graphql when um it first like started coming out and being all buzzwordy and all that uh we would have had a real hard go of it and so i think i think from a mistake perspective like my takeaway from this is that like if i'm starting a new project today i'm just going to go straight to the latest and greatest things like i like i'm going to use apollo and both the front end and back end personally and and because like their full stack just kind of it takes into account a lot of the edge cases that exist. So I think it would definitely be a mistake today to kind of like roll your own thing from scratch. There's really no reason to do that.

There's a lot of good frameworks to take care of this for you. So I think that's probably my main takeaway right now. That's great advice. Well, that rounds out our community question and answers. Thanks to all the awesome community members who submitted those questions. Thanks, John, for hearing them. Final thoughts from you, parting words, John, before we let you go? Oh, I don't know.

Well, thank you so much for having me. It's been nice getting to chat about this. And yeah, I guess a message to anyone who's listening is, yeah, definitely check out GraphQL. I think it's pretty great. I think it's, at the very least, worth some time investigating. And yeah, I think that's about it. But yeah, thank you. And also, if people want to check out your GraphQL guide that you're currently in the works with, they can actually get the beta right now, right?

So if they go to graphql.guide, is that the best place for them to start? Yep, yep. You can go there. You can preorder and get access to the full beta book as we're working on it. Yep. Both online and e-books as well. Yeah, I'm excited. I see that it's compatible with Kindle.

And because I travel so much, my Kindle is my best friend. That's where I get all my reading done. So that's great. Excellent. Very cool. Well, that is our show, Suze. Thanks so much for joining me all the way from Hawaii. Hey, go hit the beach and enjoy your vacation.

Will do. It looks like no one is there right now because it's so early. So I'm very excited to get out there. Thanks for having me. Yes, please enjoy. And one last word before we let y'all go, we will be at JSConf. So look for the JS Party t-shirts. Look for many of our panelists. I believe Suze, will you be there? Yeah, I'll still be in vacation mode. So if you see me wearing lots of tropical looking attire, it's because I've just come back from Hawaii, but I would definitely be there and I'm very excited. Awesome.

Very good. Suze will be there. K-Ball will be there. I believe Nick and I think Firas as well. So we plan on having stickers. We plan on having t-shirts. Might be first come first served on those. And then also there will be a live JS party

from the JSConf stage, I think on the first day. So stay tuned for that. If you are going to JSConf, hit us up. We would love to connect with you. And that is our show for this week. So thanks so much for everybody. And we'll see you next time. All right, everyone, thank you so much for listening. You can find more episodes of JS Party at changelog.com slash JS Party rate recommender review the show wherever you listen to podcasts. Thank you. On Linode servers, head to linode.com slash changelog. Music is by the incomparable Breakmaster Cylinder,

and the show was edited and mixed by myself, Tim Smith. Thanks for tuning in. See you next week.