StepZen and Eve Porcello: A Conversation About GraphQL

Originally posted on StepZen.

We recently sat down (had a Google Meeting 😉 ) with Eve Porcello, author of O'Reilly's Learning GraphQL, co-creator of Moon Highway, educator, and all-around GraphQL expert. It was delightful to hear Eve's take on the state of GraphQL, and we know you'll enjoy it too.

Eve: Early on it was a bunch of React developers who had heard about GraphQL at React meetings and conferences. That group of people became the first wave of GraphQL evangelists because those two technologies worked really nicely together and it felt like an easy win for React developers to have GraphQL as part of the stack. But now, with widespread adoption, people are really coming at GraphQL from all sorts of different angles. It was really relegated to the JavaScript space for a while, but now everybody can really benefit from GraphQL, so there are tools exploding in all different areas, bringing a ton of different people to the table. Because of where GraphQL fits in the stack, frontend developers need it, backend developers need it, anyone who really deals with data is now dealing with getting that data from a GraphQL API. So it's interesting how many people it touches.

Eve: Yes it's similar.

Eve: That's a really funny idea! That makes me want to write a blog about that and see if I can pull that off. We'll talk about that at some other time.

Eve: I think it's more company-based. I think companies have either chosen to adopt it or not, and I'd say at big companies-- large, large enterprise companies, there's so many people involved in that migration that it takes a while. As I said before, there have usually been a couple people who are really stoked on GraphQL, but rolling it out to the whole organization is a bigger project. There's such a shift in how you design an API, how you think about data and things like that. So I haven't noticed certain industries as much as certain tech companies that have the budget to take on the R&D cycle, but I've seen a lot of smaller companies using it as well. It's kind of all over the place.

Eve: Yeah! GitHub was the first to make it seem ok to go down that road. You'll see a company that's in a certain industry adopt it, and then other companies follow suit, like AirBnB did, then Expedia went really hard on GraphQL as well. It's funny how the competitive edge of GraphQL is showing up-- I'm interpreting the situation, of course, I don't know that that was the influence.

Eve: I think that problem is just trying to figure out, in a world where we have data in so many different places, how to get it into different user interfaces in some type of way. There's a move from monoliths and microservices, and lots of people created thousands of services. Then everybody who started working at that company with thousands of services was like: "what is going on? I don't know how to access that data." So GraphQL infuses a nice layer of organization in between.

With GraphQL, the typical architecture involves a single endpoint. The single endpoint can act as a gateway and orchestrate several data sources, but the one endpoint still makes organization of data easier.
In this discussion of REST drawbacks, it's important to note that many organizations use GraphQL and REST together. Setting up a GraphQL endpoint that fetches data from REST endpoints is a perfectly valid way to use GraphQL. It can be a great way to incrementally adopt GraphQL at your organization. ¹

Eve: That's probably one of the more common ones I think-- early on in the GraphQL story it was like "You have to get rid of REST, burn down your REST APIs", but Twitch is one of the first ones that comes to mind as one of the first to wrap their endpoints in GraphQL, and you can pick up a lot of speed from a performance perspective, because you can still cache data with your REST APIs but it means that you basically just write a schema and then fetch data from those REST endpoints, and then your frontend developers can write queries to get the data that they need. It basically 'protects' frontend developers from having to know the ins and outs of a bunch of different APIs-- they can just access all the data in one place.

Eve: Exactly. That's exactly what you can do. The frontend developers literally ask for what fields they want, and they don't have to worry about where the data is. It doesn't matter to them really-- they jsut want to make it show up. Similarly, the backend devs can jsut set it up so the resolvers fetch data from where it should be. Adding that extra layer is a nice division of duty for people.

Lucia: So that's _how people adopt it. What do you think are the big struggles in the adoption of GraphQL?_

Eve: Organizational shifts and communication is a really big one. That gets overlooked when making a technology decision. Onboarding folks is really tough, because people think "GraphQL is really cool, and when people use it they'll feel like me." And I think people do feel like them eventually, but there may be some resistance at first. The sales story and the communications story about GraphQL can tend to be tricky because you're having to get so many people on board, and the shift from REST to GraphQL is not that daunting, however it is a shift, so that's a big piece of it.

Eve: Companies that have done particularly well with this are creating internal working groups to spread the good word about GraphQL. They'll have training events, they'll have best practices, meetups internally just to communicate that this is what's going on, and that they're hoping to do this-and-that. That helps a lot. Just taking their time. We've talked about incremental adoption-- not trying to be like, we'll roll this out at the end of the month. Take more time and be more intentional about how that rollout goes and it'll yield better results.

Eve: I think it makes a lot of sense there. It's always this story of taking everything apart, making it really small, then duct-taping it back together. GraphQL is the logical query language for that in that you can pull data from all these different data sources, all your different APIs, or your Cloud services that have your data, GraphQL really makes sense as a way of gathering all that together. GraphQL and Gatsby together, for example, people were like "What? This is wild. How are we doing this?" but it ended up being a really good decision because it makes sense to keep everything small, your requests small, and GraphQL helps facilitate that.

Eve: Totally.

Eve: I think the GraphQL Foundation stuff is pretty interesting. There's a foundation now that gathers all these companies and vendors that use GraphQL. I think it will transform the way GraphQL works in the future. It's not just a Facebook thing, an Apollo thing, or a Prisma thing, instead it will be this community-based thing.

Another future thing is GraphQL Protocol. There's a blockchain implementation that uses GraphQL request. That will make sense too, because all these transactions take so long, and GraphQL makes sure that you request only the fields that you need, so it will speed things up. Ask Nader Dabit about that. It's a cool new area where GraphQL is going.

Eve: The foundation kicked off in 2019 I think. It's responsible for managing the spec, the specification document that describes what's in the query language, the schema language, and all that stuff. That group of people decides what is in the language moving forward. It decides how GraphQL should have a community. GraphQL is fairly stable in that they try not to ship breaking changes. Instead, it's very additive, so they'll add cool things but not take them away. They're working on the defer and stream interfaces now. The defer and stream directives-- what that means, in short, is how to make queries faster. Instead of being like, "Hey give me all that data", and hanging out to wait for it, you get a stream of that data coming back, and you display certain fields, and other fields later.

Eve: It's basically, on the server side, there will be kind of a node.js interface for dealing with a file as a stream rather than a whole response. It really has to do with lists-- say you have a list of 100 books, you can specify how many books you want back initially, maybe 5, then it will stream you the rest in little chunks. Just like Netflix, right, when you don't download the whole movie, instead it'll just stream you little chunks of that. On the client it has to do with the query language. You'll say "Stream these fields" and the client will support those directives. It's more of a frontend developer tool for specifiying what information is most vital to display, then prioritizing that stuff. Then the libraries will take care of the rest. It will take a while to move into the spec, which is good, they're not throwing whatever they want in there, it's more of a formalized process.

Thanks for sharing your time and your valuable perspective, Eve! So many great insights, and perhaps this is the simple truth about GraphQL in a world exploding with data:

I think that problem is just trying to figure out, in a world where we have data in so many different places, how to get it into different user interfaces in some type of way.