REST easy, GraphQL is here featuring John Resig

Sure. At Khan Academy I guess we take a very different approach to architectural decisions than maybe most organizations. My role - I’m a front-end architect; I’m THE front-end architect, but 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.

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. For GraphQL, that was a thing that had come up in a number of our front-end guild meetings. We have these 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 had gone and seen different talks on GraphQL, or read blog posts, and started to experiment with it in side projects… 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 and GraphQL seemed interesting. Relay and then Apollo came later on, and all these different things… And it’s like, okay, how do these play in together, how are these interacting, and how is this compared to what we’re doing right now with our REST APIs?

At least for us - 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 the data requirements that we had and that existed across all these different APIs.

So 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 number of experiments. We hold hackathons and Khan Academy, so during the hackathons we did some experimentation with trying out GraphQL on parts of our website. This was not intended to ship; obviously, it’s a hackathon, you’re just doing something to see if it works… But in that process, we were like “Hey, this is pretty cool.”

[00:11:08.11] So the next phase of that was I was on the classroom team last year… The classroom is all developing products for teachers and students, in a classroom setting. And in there, we were gonna 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, 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.”

In doing so, it ended up working really well. As we were using this, we were just like “Hey, this is amazing. It is so much easier to use.” Then we in the classroom team started talking to other teams, and we were like “Okay, this is actually really legitimate”, and we started to get other teams to kind of like start experimenting with their architectures.

Then eventually, after a few months of this, we all kind of decided that this is actually what we wanna be doing… That GraphQL is just 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. 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 gonna be a lot of work… So we’ll see. I don’t know when the day is gonna arrive that 100% of our RESTful 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 we’re using jQuery, and stuff… the process of cleaning up technical debt is a long one, but yeah…