Ep. #5, GraphQL At GitHub

Brian Douglas: Welcome to another installment of JAMstack Radio. Here I've got Ryan, once again.

Ryan Neal: How's it going?

Brian: And I've got Kyle Daigle.

Kyle Daigle: How are you?

Brian: Kyle, do you want to introduce to the actual audience who you are and what you do?

Kyle: Yeah, sure. My name's Kyle Daigle. I'm Platform Engineering Manager at GitHub. I run the team that deals with internal and external APIs. So, if you've ever integrated with GitHub or used any integration that works with GitHub, that comes through my team.

Brian: Cool. Then what I found, I went to the GraphQL Summit, which this actual podcast episode is going to be about. I went to it yesterday, and I actually learned that your platform team basically owns all the REST API for GitHub. Is that true?

Kyle: Yeah.

Ryan: That's a big-ass API.

Kyle: Yeah. We initially started years and years and years ago with the REST API, and that was built, I think, maybe a year after GitHub was started, somewhere in there. And then there has been a platform team ever since.

But recently the team, I think maybe in April or so, we started serving our own customers, meaning GitHub engineers, as well. Whereas before, you're only ever dealing with external integrators. Which is huge.

I mean, there's a quarter million OOP applications, and a bunch of integrators, and millions and millions of people that use the REST API.

Now we serve both audiences. It's not just outward looking. It's also internal looking.

Brian: When you say internal-looking, for GitHub engineers, are they building their own projects to help coincide with the GitHub platform?

Kyle: Forever, we've really used our REST API to do a lot of the chat-apps tooling. So, QueueBot, for example, our chat bot, that calls into the REST API. We have a bunch of internal tools that also call into the REST API. Up until recently, that's been what we've done.

Of course our own engineers build side projects and little chat bots and whatever, that can do that sort of stuff, but we're sort of looking towards the future now, and thus the GraphQL Summit. Wondering, "Okay, can the platform actually be a platform for our own engineers instead of just external?" And then letting our own engineers fend for themselves, and then hope they can get everything that they need, performantly, and have it actually work.

Brian: Without burying the lead too much, you guys recently switched to GraphQL as your thin layer. So instead of using REST, using GraphQL. What does that even mean?

Kyle: If you haven't had a lot of experience with GraphQL, the big difference is primarily that a REST endpoint, you go to a URL, and then the payload body is completely controlled by us. Whatever we give you is what you get.

So you might say, "I want to go to a repository/github," we send you this enormous payload, and you probably just wanted to know how many open issues there are, or who owns this repository, or whatever.

With GraphQL, what's really interesting is you get to ask for just the data that you want via a single endpoint, and then we just give you that data. And it's shaped the same way. It's basically just a query language. And then the response has just the data you asked for.

From GitHub's perspective, it's really great because, just thinking externally at first at least, we're calculating so much data that never actually gets used by integrators. Integrators don't want 400 counts in 72 different fields about who touched this when. They generally want one item.

But we're over here processing all this data all the time, and GitHub scales. Simple things like counts can get very expensive to compute. And so we keep delivering that, and nobody wants it, and GitHub's really sensitive about breaking REST APIs. We give it out and we want it to work forever and always, unless there's an absolute, very important reason to change it.

The difference being now we can go, okay here are all these same expensive fields, but you're only going to ask for them if you absolutely need them. Which saves us a lot of processing time, but also it helps the integrator get the data in the format that they want so they're not beholden to however we decide. It's a structure all the data. They can decide that on their own.

Brian: Yeah, which is interesting. I actually played around with the GitHub GraphQL API tool, or whatever it's called. I started handling by trying to find out open-source projects and data based on that.

Honestly, I've never played with the GitHub API that deeply before. It's just mainly like, "How do I create a repo?" or "How do I get repo data?" That's it. But then I start looking at the data and seeing how users are not really associated that closely to repos.

For obvious reasons, you don't want to be able to scrape every single contributors' emails, so stuff that's not easily accessible through the API. And I can see how many rested endpoints I would have to hit to get the data that I want to basically manage.

What I'm trying to do is manage my own open-source projects that I hopefully want to contribute to and get involved with. And I could totally see how many rested endpoints I could actually hit, and I'm actually pretty grateful for it being in GraphQL, and not having to, "Hit that, hit that, hit that." It's actually this structure by query, and that's it.

Ryan: Doesn't a lot of GitHub's API actually embed the extra responses? Like, it'll embed the user objects in the repo or the owner, and the organization as well, to kind of cut down on that?

Kyle: Yeah, most API responses have the thing you're looking for, and then if it is related to a repository, it'll send the repository down. And then it'll send the actor, if that's relevant, or the owner if that's relevant. Some user object as well.

The REST API does cover most of that. But whenever you want to do something that's even mildly cross-cutting, if you're trying to use the REST API to manage your issues, for example, because you're doing an open source project. If you know the repository, if you're building it as a one-off, you can go, "All right, I know this repository somewhat. I'm going to go to my repository/issues, and then you'll get that data.

But then if you want to look at that particular issue, you're going to have to go in one more level. And then if you want to look at labels or milestones, "I wonder what other things are labeled this way?" you've got to go into another level, and then if you're an integrator, you definitely don't know that first step.

You don't know what you're looking for quite yet. You're probably enumerating, "What are all the repos that Brian has access to?" Instead, you're going down another list. I think REST definitely has its place, but for our use case working externally, definitely,

GraphQL gives us so much more flexibility to let integrators just choose the data that they want, and us not have to compute this huge amount of data that you probably aren't even using.

Ryan: Could you have done some of that with just passing, when I've made some REST endpoints, I pass some parameters that are like, "Give me these and only this part," and it lets me empty out a lot of the struct. Is that something that you guys considered doing?

Kyle: Yeah. JSON API kind of works that way, along with others, there's a bunch of things that sort of allow you to say, "I just want these key" or "I want this relationship to come alongside it." That works well, but it still is multiple-endpoint driven, so you're still managing a multitude of endpoints.

You have repositories, now you just want the key. Or I'd have repositories and then I want the owner. That still works, but then we're still sort of defining the meta structure of what you're allowed to get at.

The thought that I had, especially when we started working on GraphQLs is, "What new things will happen when we don't presume that everyone wants to start off a repository?" I mean, there's an assumption there that you probably want to start at a repository, but what interesting things could happen if I say, "No, start add an issue," or "Start globally at a label." Then what happens?

Which, I could never do with REST because I would have to go, "Okay, let's build an endpoint and hope someone goes and tries it." And it has an overhead. But with GraphQL we're able to basically just create a type, as long as we expose it the right way, you can get whatever data you want in whatever format.

So that hasn't really been proven yet. The early access for GraphQL is still super early, but I am hopeful that there's going to be really interesting uses in a public way when we're not accidentally driving your integration via our API design.

Because, if you think about them, almost every API drives integrations by its design. Dropbox's API only wants you do do a certain amount of things. Every API I can think of, Instagram, you name it, they all have sort of an idea of how they want you to use it.

If you want to subvert that, it's basically impossible, or you have to go and scrape a ton of data, stick it in a database and then essentially build your own API around that. So, at least with GraphQL, it's a lot of hard work on the other side, on the internal side, too.

But at least with that, from a business perspective, if we're able to create more interesting, or, excuse me, allow others to create more interesting integrations using it, then it's worth the cost.

It's worth the technical complexity that GraphQL can introduce versus a more simplistic, REST-based, endpoint-driven API.

Ryan: I was thinking about that when I was thinking about this topic, and one of the issues that I was thinking is you're letting other API users call into your back end, and that logically can map directly into your MySQL calls, eventually. How do you protect against: 1) bad actors and 2) somebody writing in a really abusive query?

Kyle: We kind of have a couple different ways that we're doing that now, and some are reused from our REST endpoints. We have rate limiting. We have that right now, same as the REST API, but we also have consumption-based limiting. We can calculate how long your request was taking. If you consistently take a lot of time per request, we'll start to push you back and say, "You can't really do this. "

That's all mapping the old way to the new way. GraphQL's a lot more interesting because it gives you the ability to calculate, hypothetically, the cost of the query before you run it. And so there's a couple different ways that people do this right now, and we're sort of still experimenting on how we want the external API to be limited.

But right now we can calculate the complexity of any given field, and so if you say, "Hi, I want this viewers login." Okay, well, "login" is just a simple column in a table, and so that might cost "one." If you want to do a search, well, we're going to have to go to elastic search. We're going to have to get the results, we're going to have to go to the database, whatever. That might cost "10" per item that you're expecting to get back.

And so you can do complexity costing. Which, with some things like Sangria, which is one implementation of GraphQL, the Ruby version has this where you basically can say, "For these types, these fields cost a number." And then you can say, when you get the query, you can go through and say, "All right, they're asking for all these fields. Let's add up the overall complexity."

And then we can say, "Ah, you asked for a query that's going to cost 200 complexity. You can only spend 150 complexity. We won't run the query." And so that's one way that it can be done.

There's also depth. Presumably, every time you go in a level, you're going from a user to the users repository, or repository to the issues. The issues creator, to the creators, back to repositories, because you can just keep going down and down and down with GraphQL, and so some people minimize by depth.

So, you can only go five levels deep before we're going to stop you. That's not particularly ideal. I don't really like that one, but it's something that is sometimes necessary, based on your implementation. But I think we're trying to get somewhere between those two.

I believe it was Facebook who was telling me they cost primarily on keys. So basically, the number of fields we return back to you. So, "We can only return back to you 100 fields, 100 key values."

Ryan: Regardless of how deep they are?

Kyle: Exactly. Because, generally speaking, there is a cost in just calculating those, regardless of how much data you have to go get. The processing and going through, "This is the query. We're going to go to an AST, and then we're going to start populating it with data, and then we're going to go deeper, and then we're going to go deeper, and then we're going to go deeper."

That takes a lot of time, and it's mainly CPU. It's not database, like most endpoints you would think are. But the key calculation is another way. So I think we're definitely interested in leaving the quintessential REST you can call 500 times an hour or every 15 minutes or whatever, and go to something much closer to cost.

The trick with that is how do I let integrators know how much something's going to cost so they can plan on whether they're allowed to make this many calls?

Ryan: Without just making the call and having it get rejected?

Kyle: And then all of the sudden be like, "Oh, you can't talk to us for an hour." You know, that's not a great way forward. We're still sort of investigating, and that's what we're hoping to, having been the first major public GraphQL API, no one really knows. Because when you're internal, it's different.

When you're internal, I can say, "Before you go to production you have to run the query," and we can just say, "Nope, we're not going to run that query." But externally, I have no idea what you're going to send me. So we're still trying to figure out what the best practices are in talking with folks at the GraphQL Summit on what's normal, what's worked for them internally. Or if they have an API that's small, or what's worked with them externally as well.

Brian: So, can we dig a little deeper back up? It's always fun to talk on the podcast about code and implementation, but I'm interested to hear more about how you guys implemented GraphQL to your current setup. Because what I first heard that you guys are doing, I was like, "Oh, how are they doing that with Rails?" I though GraphQL was a fancy JavaScript thing.

Kyle: Yeah, it definitely is easier if you are in JavaScript, only because when Facebook released it, they released their reference implementation in JavaScript. And so a lot of the tooling, and if you're at GraphQL Summit, a lot of the examples were all in JavaScript.

We're Ruby and we do other languages. We have Go, we have C, we have C++ and stuff like that. But it's not something that we rush to. Generally speaking, we start in Ruby and then we leave it when we need to.

We luckily found a really great open-source maintainer, Robert Mosolgo, who wrote GraphQL Ruby, which is the Ruby gem that's an implementation of, or I guess a re-implementation of, the JavaScript implementation.

It follows the spec and it's basically just a way to pass in a query. And then he has built a really great DSL that allows you to say, "Okay, I want a user object, and a user object has a login, and that matches the username from the underline records." We relied really heavily on this open-source gem, and we also have used some open-source work from Shopify.

Shopify released GraphQL-Batch, which is a way to avoid going to the database over and over and over again. You basically batch up your requests and then send those out.

Ryan: Like, from different users you get 10 people asking for it?

Kyle: If you're going through a query and you're saying, "I want to get Kyle's repositories," and then for each of his repositories, "I want to know the last person who commented," or whatever, when you say the last person that commented, it's going to iterate through all my repositories. So, in a normal, without any sort of batching or loading, it's going to go "Select from comments where ID is 'one,'" and then it's going to go "Select more comments where ID is 'two.'"

What batching does it is uses promises to basically go through and say, "Okay, I know Kyle wants comment "one," I know Kyle wants comment "two," I know Kyle wants comment "three." And they go through all that level of the tree, and then once they finally need the data, because, say, maybe I want to know who wrote the comment or when it was created.

Then those all run in a single query where it's going to, say, select from comments where ID is in this list of IDs. It's very similar to Data Loader, which is something that Facebook wrote. And again, it's in JavaScript. And so this is like a Ruby implementation that's similar but not exactly the same to how Data Loader works.

Brian: GraphQL just came out, a technical preview, a month ago. Was it pretty painful to start this project so soon after it was open source?

Kyle: I thought it was going to be, but not really. I sat down, I want to say, in March. I had spoken with our VP of engineering at GitHub and we had talked kind of hypothetically,"What would the next version of the API look like?" And I remember saying, "Well, I think it needs to be more workflow-based."

Right now, REST APIs are very specific to objects. But I think people don't work that way.

They work through workflows. They want to accomplish something. I had seen GraphQL, I had a friend who was really into JSON API, and so I had looked at some of that. But the VP of engineering had done some work in GraphQL in his previous job, so he said, "Why don't you go try putting together a GraphQL proof of concept and just see."

So, probably within two weeks, I had a really great GraphQL proof of concept that was so compelling. And to be totally fair, thanks to the open-source community, because starting from scratch would have taken a lot of time, but being able to use the open-source code to do the query processing and setting it all up, after two weeks it's so compelling.

One of the tools that they have is GraphiQL. Which is like this IDE for looking at GraphQL queries. We had it on developer.github.com for the GitHub GraphQL API, and so I built this thing in Ruby on Rails inside our giant GitHub monolith app, and then put an extra endpoint into the REST API that was like, "Oh, if you call this, you're going to get GraphQL instead," and then pulled up this GraphiQL IDE.

And you start using it and it's the most magical thing in the world, because it just all of a sudden clicks. You're like, "Oh my goodness, I can go from this repo to this user, back to the repo, back to a different user, and link all the way down." And then you can look at the queries that it represents, and I maybe made three queries.

It's not as bad as you think it is. I mean, you have to build it that way, but I wouldn't even say right now that it was particularly difficult. It was just sort of like wrapping your mind around both GraphQL and Relay, because Relay adds a bit of standard onto GraphQL, if we're talking about collections of objects and standards for getting single objects via global ID.

Relay sort of adds some stuff onto GraphQL, and we decided to use that because it's pretty standard now. But by doing that, I mean, in my GitHub Universe talk I said, "Whoa, it's true." One of the few times I think where it felt just magical where an API just felt magical. So I was really excited.

It wasn't really difficult. The hard part was basically figuring out how to think like that, after me building REST APIs my entire career, where it's very linear and kind of flat, and having never seriously worked in a graph database. Because the people at GitHub that have done a bunch of graph database work thought, "Yeah, no, this makes sense, it's good." It's not a big deal, but for the rest of us it takes a little bit of time to learn and understand how all the different pieces work.

Ryan: You talked about changing the way you think about it, and I've built a lot of APIs and a of use RESTful logic. I start with my data model on the back end, and then I think, "How the hell is somebody going to use it on the front end?" Design some endpoints, follow some REST standards. How is that different? Because I use that to figure out writing that middle layer. What's different in GraphQL's world?

Kyle: The purpose, if you talk to the folks from Facebook, the sort of TLDR of their origin story, is they wanted to help the News Feed team build the News Feed, and so there's kind of two ways to think about that. They go to the News Feed team and say, "What's all the data that you possibly need, and we're going to put it in this endpoint."

Or they basically say, "Okay, what types of data do you need, and we're going to build that in a way that let's you decide how you want it." And so to me, that's what's really compelling about GraphQL. And I don't know that GitHub internally has seen that promise quite yet, as we continue to add more and more of GitHub's objects into the schema.

But again, the really interesting thing is, you add all this data into your GraphQL schema and then you go to an application engineer, a product person, a designer even, and you're like, "What are you trying to build?" And they'll say, "Oh, well, I want to make a new dashboard on GitHub," or whatever. And now they have a way to get out all that data that's relatively non-technical.

It's basically, "Okay, I want a user - user{," and then the IDE says what you want. The IDE says what you want, and you're like, "Huh, I wonder what a user has?" And you click in, it tells you.

To me what's really, really interesting in comparison to say, going, "Okay, what are your requirements? I'll build a REST API that can meet those requirements." Now we say, "How can I describe a user? What does a user have?"

A user has an avatar. Okay, so now we have a user object and an avatar object. Well, what else has an avatar object? Okay, an avatar object can exist on OOff applications. It can exist on organizations, so on and so forth, and then we don't know what the next requirement is going to be.

It's really interesting for me to let the product people, whether those are engineers, designers, project managers, it doesn't matter, use GraphQL to build the application.

We're not sitting there and sort of being arbiters of how to get out data. We're saying, "Okay, no, here it is. Are you missing data? Then let's add it in." And then some other companies, we haven't done this yet, but a lot of other companies and people who use GraphQL use mocking pretty heavily to allow product engineers to go, "All right, I think I need a new object that looks like this."

And so they put it in, and then, "This is going to be a string, and this thing's going to be a number," and then they let the mocking basically fake that while they wait for their version of a platform team to actually implement it in the database and make sure it can scale and whatever.

So you're able to build these features without having to wait for the underlying implementation, or having to do it yourself, because again, when you're at a big scale even a simple thing like "I want to add a new table or a new column."

I mean, you're looking at it nine ways to Sunday, and "How many indexes does this need? And should it be here?" So GraphQL, I think, really enables the front-end people to basically come up with cool ideas and not be held down by, "Okay well, this active record query, how is this going to perform?" That's pushed down much further, and GraphQL can help them build more interesting products.

Brian: To add to the Facebook use case, GraphQL came out in 2012, around the time Facebook became public. And so Zuck basically said that their implementation for mobile was really bad, and so the problem was they had to rebuild their mobile from ground up to make it better. They used GraphQL to do that.

So, rather than be stuck within the confines of the Dashboard, the Facebook News Feed looks like on web, they're able to rethink the way how to get data on the actual mobile client using GraphQL because of that.

So there was no limitations based in API. Plus, another thing that, actually, Lee Byron actually mentioned, that you build your API based on how you get it. So with GraphiQL, which, it's funny spelling, not a lot of people realize it's Graph-I-Q-L, but they call it GraphiQL.

Kyle: They're really proud of that pun, I will tell you.

Brian: A lot of people. Because only one person who presented yesterday said it wrong, multiple times. Anyway, besides that, with GraphiQL there's the completion of just typing in queries. That's the one thing that I was basically sold on, to be able to just type in "user" and then to get an idea of like, "Oh, so the user has this stuff."

I can just kind of figure out by queries without ever going to the GitHub documentation directly, and saying, "Okay let me just traverse through all this stuff and try to see what I need." No, it's actually, it's just going to show you within GraphiQL, which is amazing.

Kyle: And there are ways to bring that to REST. There's things like Swagger, and we used JSON Schema for a while. That can get you there, but it always feels so additive. You have to remember, we still build REST APIs, and so new features come out, we build them in GraphQL.

And then, generally speaking, now we build them in GraphQL, and then we back the REST endpoints with GraphQL so that way we don't have to run two implementations. But that's not true before GraphQL, right? The application engineers will go build their feature, and they would come back a couple weeks after the feature went out, and then they would build the REST endpoint.

And then they would go build the JSON Schema that says, "Okay, this response should have these objects with these types, and... oh wait, this didn't quite work." It's so great with GraphQL just to have it so baked in, instead of thinking, "Okay, what is this? Is this ever going to be null? Well, it's null right now so it's probably going to be null." Then you put it in, and then you don't really think through, "Do I have a data problem, should this ever be null?"

I think that was really compelling, is it's not like GraphQL was the first thing to ever do all these things. It's just really really thin, but the things it does well, it does really really well.

Ryan: You guys said you back your REST endpoints on GraphQL, not the other way. Did you start going the other way, though?

Kyle: We didn't, only because we knew we wanted to use GraphQL internally. So we needed to go as close to the database as possible. We had to back everything by MySQL. Ultimately active records still, in almost all cases, but a lot of people who do move to GraphQL do back their initial GraphQL implementations with their REST API or a microservice REST API or whatever.

The whole point is that you don't have to jump headlong in and write everything to the database directly. But because we are using it internally in process, in the web view and externally, we couldn't afford to go out to our own API to load our website.

Ryan: Performance.

Kyle: Yeah, it wouldn't be good. So yeah, no, we didn't do that. But I know a lot of people do that, where they might already have microservices or they might already have a REST API, and they want to give GraphQL a chance.

And so they basically just do what we described. You put it up and you make a multitude of calls to your own API to populate it, and you send it out. So it might not be horribly performant. Depending on what language you're in, you can do threading or make multiple calls at the same time. But for us, we definitely just go straight to the database.

Brian: And then to make Ryan jealous just a little bit, about GraphQL Summit yesterday and that he didn't go.

Ryan: Yeah, rub it in, thanks.

Brian: I'll just answer my own question, but I was actually really impressed with the turnout of the community. I'm actually really bullish on the open source project all together. What was your opinion of the actual conference itself?

Kyle: I thought the same exact thing. There were a lot of people there. I think what's interesting is that the number of people that were speaking at that conference were big-company people.

Do you know what I mean? Normally, you would expect to go to this young technology conference and it's 14 startups of which three you've used and the other 11 you don't know about. But in this scenario it was both.

I mean, it was like, big companies, huge companies. Credit Karma was there, Conde Nast was talking about what they're up to. As well as hackers and small companies looking to use this. So I was really surprised by that, because to be totally honest, I expected it to be much much smaller, newer shops willing to take the risk.

But I think what you're finding is, and I don't want to take too much credit for this, but

when we decided to ship GraphQL, a big part of it early was, 'Let's beat the bushes and see who comes out.'

You know, if GitHub gets nice and loud and says, "We're building an API that's public in GraphQL and here it is today and it's super early and doesn't work particularly well, but here it is." All of a sudden all these companies aren't afraid to come out and talk about it.

Shopify, for example, they got right up on stage and they're like, "Yeah, our whole mobile app is built in GraphQL, even though we've never really talked about this publicly before." It's really interesting, and that's what we wanted, because in order for our, again very selfishly, in order for our API to be particularly successful, the community needs to know what GraphQL is.

We can't just be like, "This is the new thing, get on it," and hope that everyone rushes over. So, by doing that, I think we're going to see, like Lee Byron, one of the co-creators said, we're going to see a lot more tooling. We're going to see a lot more open-source clients, a lot more companies using this. Which will help the overall adoption, which will make it much more comfortable for other companies, Facebook included, potentially, to launch a public GraphQL API. Because that's definitely something that's lacking right now.

It feels early, it feels like a cool thing to use GraphQL. And to be totally honest, I would love to get rid of that as quickly as possible. Because when something becomes uncool, then it's serious.

You can actually use it and trust it. Which is part of what they talked about at the GraphQL Summit, with Lee talking about RFCs and how they're going to move towards a six-month chain schedule.

So, I'm excited. I was really excited at the Summit to see just how serious this is already, and I'm hoping that more companies will feel comfortable coming out and saying, "Yup, our web app is backed by GraphQL." Because right now it definitely has a JavaScript focus and a mobile-client focus.

And I would love to say, "Nope, we're a Ruby shop. We call it in Ruby, we process it in Ruby, we use it in Ruby." I know of other companies that are about to go, "Yup, us too," and so I'm excited to watch that happen over the coming months into next year.

Ryan: You talked about, a little bit, Swagger and things like that and how it's new and emerging and really starts putting some of the structure in place. With REST there is some really good structure. You have very strong opinions about how to build a REST API. It's still emerging. Is there any leaders other than you guys, for lack of a better, on the best practices around building a GraphQL API?

Kyle: Yeah, the folks that put the conference on yesterday. Apollo, they definitely have a lot of tools and they can help with that. I think if you look at graphql.org and you look at all the libraries that people are doing, that's a big part of it.

I think what you're finding now is that if you go to GitHub and search for, I forget the exact URL, but the GraphQL project itself, there's RCFs and a bunch of people, small companies, big companies, interested people submitting RFCs.

And they're trying to push GraphQL forward, but I think what we're also acknowledging is that this is also a serious technology now. We're out of the sandbox. We're not just sort of messing around with what our options are, and they're trying to make sure that what gets added to GraphQL is needed in GraphQL, not suggested in GraphQL. Because, really,

GraphQL, what I find so compelling is, it's so thin. There's so little there.

You can read the spec. You can just sit down, grab a cup of coffee and read the whole thing, understand it and be good to go. So I think we won't see a ton of people really pushing GraphQL forward because it's a type system.

It's very clear how it should be parsed, and then Relay starts to add some more complex things on top of it. There's nothing stopping us or someone else from going, "Okay well, we're going to make our connections different, and they're going to look like this," or whatever. It's all still valid GraphQL.

It would be backwards compatible, but it's a standard. I don't know of a ton of places where there are people sort of pushing things forward independently, but I think with Relay and, maybe in the future, we might see more companies sort of glomming around.

Some of these ideas should go back to GraphQL, connections being one of the things that just primarily an idea of relay, how you get a multitude of different objects, or objects having a global IDE. Those are all relay ideas, but I think you might see GraphQL going, "These are so good, these should just be part of GraphQL."

But at the same time, there's nothing stopping me from just doing that right now if I wanted to. That's what makes it so interesting in comparison to sort of having to convince Rails, like, go to DHH and say, "Well no, this should work like that," and he's like, "Well, no."

With GraphQL, because it just feels so un-opinionated, in a way, both extremely opinionated and un-opinionated at the same time, it's very easy for people to just go, "All right, I'm just going to build it like this and let the clients use it." And with the GraphiQL IDE, it's pretty easy to kind of feel your way around to figure out, "Okay yeah, I understand what these people are trying to do with this."

Brian: Yeah, I use the GraphiQL without much research going into it. I just kind of hit, I first went to the GitHub open source. What do you guys call it, the GraphiQL thing?

Kyle: GraphQL Explorer.

Brian: Yeah, GraphQL Explorer. I hit the Explorer and I just kind of poked around. I was like, "Okay, I finally got my key." And I just looked at my repos and then I looked at Netlify's repos, and then I looked at other people's repos. And I was like, "Okay, I understand. I can navigate through it pretty easily, and I didn't read anything before going in."

Kyle: And it's cool from a documentation side too, especially coming from a REST background. You normally are building it and then documenting it as a second step.

Ryan: Eventually I document it.

Kyle: Some people do actually document it first and then go implement it. But there's nothing saying that your documentation matches up. There's a big problem for us, even at GitHub.

Developer.github.com, the REST docs don't always match reality. It's because they just fall out of sync. Just like comments fall out of sync and code, but with GraphQL, because the types are intended to have descriptions, the fields are intended to describe themselves, because they're typed, and types can inherently have descriptions, it's very easy to auto-generate documentation.

And so we both use the GraphiQL IDE. But we also have a separate script that builds the docs for the site, and those are just all automatically generated. And it's amazing because, normally it's like, you make a change at a REST endpoint and there's seven other places you have to go let the world know that you made that change. But now we can just do it all automatically.

Brian: Cool, awesome. So I'm actually pretty impressed. I'm going to transition to picks, but I think that was a really good conversation. I think it definitely piqued a lot of people's interest. So hopefully through this podcast more people will jump on the bandwagon.

Kyle: Yeah, and send feedback in. I'd love to hear more, for sure.

Brian: Awesome. You guys have even a developer platform too. Which is pretty active about different GraphQL stuff, as well.

Kyle: Yeah, if you go to developer.github.com, we have links to our forums and everything. You can go on there and add your comments and questions. The engineers are the ones that actually answer them. So it's actually really compelling for us to get that feedback directly.

Brian: Very cool, awesome. So, transitioning to JAMpicks. JAMpicks are everything we're jamming on, anything we're interested in, keeping us going, from work life, home life, fun life. So I'll let you go last since you are the guest.

Kyle: The newest one.

Brian: So, Ryan, did you have any picks that you wanted to share?

Ryan: The thing that's been haunting me has been Halloween coming up, actually. I'm putting together a costume, and for the first time going to have to do face makeup. I tried putting this ghoul makeup on, and it was terrible. I look like I'm from ICP, and I was like, "Oh, we're washing that off immediately." So I go home at night and try to stare in the mirror and see if I can do makeup and not look terrible.

Brian: Wait, what's wrong with ICP?

Ryan: Everything. Let's just be clear.

Brian: For the listeners, I doubt anybody got that reference if you're not around the age of 30: Insane Clown Posse.

Kyle: I wasn't going to say anything but I was with you.

Brian: It's a rapcore band around the Limp Bizkit age. So cool, you've been practicing your makeup.

Ryan: Yeah, me and Halloween, I get really into it. I have an awesome costume put together.

Kyle: I don't know that I've ever practiced my Halloween art, though. I feel like that's a huge commitment to that.

Ryan: I had to make all this rope stuff, and so I was hand braiding ropes and everything like that.

Brian: Well, this is San Francisco, where people wear their costumes all day. And there's 13% children in the city.

Ryan: So more dogs than children, right?

Brian: Yeah, more dogs than children. So why people are going out on Halloween in their costumes all day, I don't know. But it's the city where you never grow up.

Awesome. My pick actually is going to be a project called React Music. It's a library that, if you're familiar with 808s and sine waves and all that other stuff, all of it is basically math and code.

Someone has built this project, Formidable Labs, I think, is the company that actually put this together. I'm not sure who specifically put it together, but it's out there and it's awesome.

So with React, it's all component-based. You can actually throw your components, you can throw your 808 component on there, and you can add in an array based on how many beats.

So if it's an eight count, you can throw your beats where your snare and your high hat is, and it's pretty amazing. I just saw a talk on it literally before I walked in here earlier today, and it's amazing. I think I'm going to make a beat this weekend. Maybe cover a song. And maybe I can share it with the world, eventually. Highly recommend React Music.

Kyle: That's awesome.

Ryan: You're going to have to also mix it with the Netlify guitar that we have now.

Brian: Oh yeah, after you tune it. I'll play some AcousticaElectronica.

Kyle: Were you able to watch the Mac announcement today?

Brian: Oh, I missed the Mac announcement. I saw screenshots, but I also saw screenshots two days ago.

Kyle: Yeah, the TLDR spoiler alert. On the Touch Bar, they spent a three- or four-minute segment of a gentleman DJing, just using the Touch Bar. So I highly recommend, given your interest in creating your own beats, that now if you buy the new Mac, you're good to go.

Brian: I'm sure implementation is probably not going to be that cool at all.

Kyle: I don't know, he did it live, it looked legit.

Brian: Yeah, I can just imagine myself scratching my keyboard at an EDM concert. Hold on guys, it's going to work. My hands are sweaty.

Kyle: Awesome. Mine would have to be, I don't have a lot of free time, I have a kid and it's Halloween season, so fall. I live in Connecticut, so I live in New England, so we've got apple picking and pumpkin picking and a much higher percentage of, children up there.

But before I came out here I was able to check out Battlefield 1, new video game. So, Battlefield 1, if you're familiar with Battlefield, it's been one of the big war games. Mainly in WWII, and now they're bringing it to WWI. It's actually really interesting.

I'm big into story games. I'm not big into Call of Duty or anything like that because there's no real story there. And this is the first time that, apparently, Battlefield has really killed a really good story. So I only just started playing it before I came out.

But it's the thing waiting, playing, go home, say hi to everyone. Be like, "Hey, I'm home now, and I can sit down and keep playing." It's pretty cool, I think it just came out last week or something like that.

Brian: Pretty cool. Yeah, I wasted a lot of my sophomore year in college on Battlefield 1942. Which is the WWII version, but probably much crappier. I'm a big fan of Battlefield games, but I definitely have no time either.

Kyle: The neighborhood kid comes over and sees I have an Xbox, a PS4, I have a PC. He's like, "You have all those?" I'm like, "Yeah, I have them." He's like, "When do you get to play them?" I'm like, "That's the secret of being an adult, you have money to buy all the things you wanted as a kid but you never have time to actually do any of those things." I feel cool and I get to play video games once every three weeks.

Ryan: My Xbox has a thick layer of dust on it right now.

Kyle: It's the adult dust.

Brian: Yeah, that sounds disgusting. But on that note, I just want to conclude the podcast before it gets any weirder in here. Kyle, thanks again for showing up and talking about GraphQL

Kyle: Yeah, thanks for having me.

Brian: I'm definitely excited to see what GitHub is going to push forward. Especially in this community, but also in future communities as well. You guys are doing, GitHub Universe is pretty impressive, as far as all the stuff you guys laid out. And definitely integrations are a big part of GitHub Universe, so I'm really happy to see that, because Netlify's an integrator company, as well, in GitHub.

Kyle: More to come, for sure.

Brian: Much appreciated. So, thanks again. And listeners, keep supporting the JAM.