As API architectural patterns go, GraphQL — which is most definitely not RESTful — is the new darling on the block. More and more enterprises from Github to the New York Times to PayPal are working with the technology which was invented at Facebook.
But similar to the early days of RESTful APIs, it’s a little bit of the wild wild West when it comes to the frontier of GraphQL. Tools do exist. But its not like there’s a flood of them on the market. However, as of the time that this article was published, there is one company that got the early jump and that’s nearly synonymous with the idea of standing up GraphQL APIs; Apollo GraphQL.
So, when the opportunity came along for ProgrammableWeb to do a podcast interview with Apollo GraphQL co-founder Geoff Schmidt (the video, audio, and full-text transcript appear below), we didn’t hesitate to get him on the docket. We were also sure to include our in-house GraphQL expert Bob Reselman; author of one of the most comprehensive guides to GraphQL that you’ll find on the web.
In the interview, Schmidt, Reselman, and I spend a fair amount of time talking about what GraphQL is (for those of you who are not familiar with it) and then where Apollo GraphQL fits into the landscape. As can be expected, Schmidt is a huge fan of GraphQL and loves to espouse some of its advantages over REST as an API architectural pattern. He touts GraphQL’s ability to do in API fashion what Structured Query Language (SQL) once did for databases; the ability to respond to a single query with related data that spanned multiple tables. Surprise! They’re both query languages.
All this said, across the API economy, REST is still the predominant architectural style followed RPC (and in particular, the XML-RPC flavored variants of RPC). But who knows. That may not be for long as more and more companies discover the virtues of GraphQL.
Before the interview was over however, we talked about language independence (Apollo GraphQL is primarily Node.js-based but modules in other languages can be used) and eventually fell onto the topic of GraphQL federation (a new capability for Apollo GraphQL). In a nutshell, GraphQL federation implies that the data that makes up a graph can come from multiple sources, each of which — in very microservices fashion — is administered and managed by different teams or departments.
To hear about everything Schmidt had to say about GraphQL and Apollo’s approach to helping API providers and developers working with GraphQL, be sure to watch or listen to the podcast below.
Video Podcast: ProgrammableWeb's David Berlind and Bob Reselman with Apollo GraphQL co-founder Geoff Schmidt
Editor's Note: This and other original video content (interviews, demos, etc.) from ProgrammableWeb can also be found on ProgrammableWeb's YouTube Channel.
Editor's note: ProgrammableWeb has started a podcast called ProgrammableWeb's Developers Rock Podcast. To subscribe to the podcast with an iPhone, go to ProgrammableWeb's iTunes channel. To subscribe via Google Play Music, go to our Google Play Music channel. Or point your podcatcher to our SoundCloud RSS feed or tune into our station on SoundCloud.
Full Text Transcript of Interview with Apollo GraphQL co-founder Geoff Schmidt
David Berlind: Hi, I'm David Berlind, editor in chief of ProgrammableWeb. Today is February 14th, 2020, Valentine's Day, special day. We love developers here on ProgrammableWeb's Developers Rock podcast, and today we have two very special guests with us. One of them is Geoff Schmidt. He is the CEO and co-founder of Apollo GraphQL, and our other guests is one of our authors, that is Bob Reselman, he writes about GraphQL and other advanced API technologies. Geoff, welcome to the show.
Geoff Schmidt: Well thank you so much for having me. Excited to do this.
David: And Bob, welcome to the show.
Bob Reselman: Hi. Thanks again David for having me, again.
David: Yeah, well we love to have you here Bob, because you're such a great writer for us. For those of you who haven't read some of what Bob writes on ProgrammableWeb, we strongly recommend doing it because he writes all the technical details about things like GraphQL, which is the subject of our call today. Bob, in fact, authored what I believe to be one of the most comprehensive guides to GraphQL for us on ProgrammableWeb. It's easy to find. If you just Google GraphQL on ProgrammableWeb.com you'll find it. So I want to start with you, Geoff. Geoff, you're the co-founder, as I said earlier, and CEO of Apollo GraphQL. What is Apollo GraphQL?
Geoff: Well, Apollo is a way to build a data graph inside your company. To talk about what a data graph is for a second. Now let's think about API technology and where it's coming from and where it's going. The world's gotten a lot more complicated. The apps that we build have gotten a lot more complicated. There was a time when building an app, well you might have a web server, it might talk to a database, you might access that app through a web browser. Pretty simple layout that was easy to understand. Now there's a lot more moving pieces. It might not just be a website. In fact it's probably not, it's probably an iOS app, probably an Android app. You might have a lot of different channels you use to reach your users. It might even be a voice assistant. It might be something IoT related. It might not even be a first-party property. You might want to reach your users through partnerships, integrations. Why should your first-party app be the only way people access your services?
And what's behind those apps is a lot more complicated too. It's not just a web server and a database. You've probably got a bunch of microservices. Increasingly you might have other SaaS APIs you're pulling in, lots of different data sources, multiple clouds. Whereas traditional API technologies like REST and SOAP grew up in a point to point way of thinking, where if I want to talk with you, we dig a ditch and we bury a cable and now we can talk. The data graph is more like a telephone network where you can dial any number and connect to anyone you need to, because if you think about it, you've got many different microservices or many different data sources. You've got many different things that want to consume those services.
So what you need is a more flexible way where instead of having to build a new API Endpoint, a new REST endpoint for every use case, every combination of data, every screen in your app, every time you want to Fetch a different group of things in a different combination, the data graph gives you GraphQL which is almost like SQL for database, because it's a declarative language for saying... I don't have to write code anymore to fetch a particular combination of data. I can just describe what I want declaratively, I can use GraphQL to express my needs, and then you can have a query plan or a resolution engine that's able to go fetch the data wherever it may be and assemble exactly what you need.
So it means front end developers don't have to ask the backend for new endpoints. It means you can build new products really quickly, new features really quickly. It means your partners, if you have a public API, it means that suddenly those people can build much more rich and complex products. It also means your apps are faster, you're putting less data across the wire, they're more secure because your security isn't dependent on all this handwritten code. So there's a lot of benefits to rethinking the way we think about APIs in this much more connected, many to many world. And that's what the data graph is all about.
David: I want to just stop you there. Obviously you mentioned SQL as former way of doing this, SQL, GraphQL, they both share the QL, the query language bit. There are some similarities there. In the old database world, if we wanted to get a whole bunch of data from multiple connected tables, now what we're talking about is getting a collection of data from multiple connected microservices all at once with one query. That's one of the big advantages of this API technology, GraphQL, is that instead of going out and fetching the data from each of those sources independently and then tying together when you bring it back, you can, with one query, go out, get the data, to the extent that it's connected to each other across all those microservices, with one query and bring back all that data in one fell swoop. Is that correct?
Geoff: Yeah, you've got it exactly right. If you think about it SQL revolutionized databases. Before SQL, your query planner wasn't a piece of software. It was a human being. Every different use case, you'd have to write a bunch of custom codes that joined data from here, joined data from there, and that didn't scale. That didn't scale as early as the early 80s. And what's happening now is the emergence of a similar model for "how you get data out of the cloud?" So SQL is about, "how do I get data off a disk?" GraphQL is, "how do I query all these different services in the cloud?" for all the same reasons that we wanted to move to a declared a paradigm with databases back in the 80s, there's now this move to this declarative query based paradigm in how you talk to microservices and talk across the internet to data sources and backend services.
David: Understood. So now we know what GraphQL is. We've talked about it a little bit here and described it to some extent. I'm sure there's more to it. What is Apollo?
But then there's also a complete graph management platform. So as you go from one or two developers using GraphQL to multiple teams across your company, and you need to solve those problems of "how do we scale all of our workflows and how do we scale security? What's our practice for as we go from a couple of people using this to a vision about how we're going to roll this out across our whole company and have truly one connected graph?" We've got your back the whole way there, and it's used everywhere from small project startups who are just getting started with GraphQL, all the way up to companies like Expedia that are building one data graph across, I think, 20 plus brands across the whole Expedia group portfolio. Or Airbnb where Apollo is going to power all customer experiences or runs the front page of the New York Times. Powers a lot of stuff at PayPal. It's a very scalable solution to getting started fast without having to get too much politics or buy-in, but scales all the way to the most demanding use cases at scale both in terms of query volume and also in terms of the number of developers who are working on it.
David: Well, I'll say it's also one of the most famous solutions in the GraphQL niche of the API economy, because you can't talk about launching a GraphQL API without Apollo coming up in the conversation. At least that's my point of view as the editor in chief of ProgrammableWeb, where we to think of ourselves as the journal of the API economy. The two are almost synonymous with each other. In fact, off the top of my head, I don't know of another solution that I can recall by name that does what Apollo does for GraphQL, and another solution that also does the same thing for GraphQL. It's like you guys were the first ones there doing this, and there's really nobody else that's risen to the same stature that you have risen to in providing this technology.
I think back to the days of Java where there were a whole bunch of different vendors providing Java solutions, J2EE servers. There was Sun, of course, who invented Java and then there was BEA and IBM. But off the top of my head, Apollo seems to be the one that's definitely got the early jump in terms of being the go to platform for providing a GraphQL APIs. Bob, I want to go to you. You've obviously written a lot for us and I think, if I'm not mistaken, Apollo is primarily running on Node. What have your findings been in terms of other GraphQL platforms?
Bob: There are. There are other platforms out there, but before I go forward with the other platforms, I need to comment on Geoff's modesty, because he's being very modest actually about what GraphQL does. In particular with regard to SQL, one of the benefits that GraphQL brings to the arena is that with SQL you've got to know a whole lot just to get something simple done. Select this field, this field, this field from this... do joins, jump around, turn around three times. And you have no intrinsic way of discovering what those data structures look like. GraphQL brings that right to the forefront. So the concept of a join is completely irrelevant in GraphQL, and you can do what's called introspection, which allows you to inspect the complete type system of the data structure. And that's really, really powerful.
The other thing that GraphQL brings to the table is this notion of subscriptions. Of really realtime messaging. Whereas databases have triggers and you can get around... They're there but they're not first-class citizens. You got to know a lot, you've got to register a procedure around the trigger. GraphQL, it's really just as simple as registering to a subscription as you would any other message, brokerage architecture. Very, very powerful. And what it does is it creates this notion of what's called a hybrid Microservice model. Whereas in some world you might have REST, which is intrinsically synchronous, or you might have RabbitMQ, which is intrinsically Asynchronous. But bringing them both together into a unified programming and consumption experience is pretty special, and GraphQL does a good job with it. And I've got to say, Apollo does a really, really good job of making that happen.
David: So all of the demonstration code that you've built that people can come and experiment with on ProgrammableWeb was all built using Apollo, isn't that right?
Bob: Yes. Yes it was. It was all built using Apollo. It's straightforward. You have to be careful. I don't want to burst your bubble, Geoff. You have to be careful. But again, Apollo does a good job of saying, here's what you need to be careful about. And let me give you two use cases where one needs to be careful.
The first one was really the Monet project that happened over... I think it was at Netflix or Facebook, I forget, I have to look it up. But what they did is they combined all their microservices together, all their services together under a single GraphQL interface or GraphQL graph. And what happened was is that they had some significant performance problems, and the performance problems really had nothing to do with GraphQL, the specification or any of that. It had to do with they were keeping all the services in their same distribution model.
So for example, service A's coming out of India, service B was coming out of East Elbonia, service C was coming out of Mars. So even though under GraphQL you have one trip to the network, behind the scenes, there's still all this multiple network latency going on. What they did to solve the problem is they brought all the data into a common data center. So latency, we have to always be aware of latency. Pay me now, pay me later. The other thing that we have to be aware of when we're using GraphQL, and Apollo points this out, they're really good about this, is that when you start using subscriptions, you have to be very careful about choosing your message brokerage architecture that's going to back those subscriptions. The one out of the box, it's good for learning and good for experimentation, but it doesn't scale. And again, Apollo mentions this, so we need to be just aware of that.
There are other ones, there's a net solution, there's a Java solution, there's a Python solution, Ruby solution. All people are going out and saying, "Look, if you want to create a GraphQL experience, you have different languages. Remember GraphQL is a specification only. It does not dictate implementation. But I like GraphQL. Hey, you got me.
David: For developers who are listening to this and who want to experiment with GraphQL, they're not tied to going to Node.js, which is the platform for Apollo. They can go to one of these other platforms. Going back to you, Geoff, knowing that, are you going to stay focused on Node.js as your platform of choice or are you going to be offering the same functionality that you're providing on Node.js on other platforms?
Geoff: So GraphQL's a whole ecosystem and the Apollo platform really embraces that whole ecosystem. So yeah, I think you're referring to Apollo Server. Apollo Server is a great way, if you're a front end developer, to build the data graph quickly in your company. And the great thing about it is, it's not a silver bullet that's going to solve every performance problem you have, but it is almost certainly going to be better than what you were doing yesterday. So it's a step forward. And sure, as our apps, as our architectures get more complicated, we always have to pay attention to data residency, latency, and the scalability of our backend systems.
And then the other component is... We also have Apollo Gateway, which is a component that when you have all these different backend services, what's the query planner that stitches together? What's the ingress point going to be where that query comes, so it can get fanned out to all those pieces. And then on top of that, there's Apollo Graph Manager, which is, now we've got this increasing number of people on this platform. Just like when I'm writing a program, I want to have source control. I don't want the code to just be defined by whatever is on my laptop. I want to have a way of seeing Versioning, I want to know what's true, what's the production, what's my process for changing and managing this.
One of the first things you find you want in a graph is a server that has all your schemas on it. What's the definition of my graph? I have many different teams that are... With REST APIs, you might change that API a couple of times a year, if that. With a graph, you can be changing your graph multiple times a day. And because it's designed around a much more agile practice for how we can continually evolve and refine the graph, because we can have much better workloads and tooling, that's possible. But you start to need a server that has all your schemas, you need to be able to manage, how do we secure our graph, how do we federate all these different graphs together? That's Apollo Graph Manager, which is totally language agnostic. We really embrace the whole GraphQL ecosystem. It's not all going to be written in Apollo, but I think one of the reasons why Apollo is so popular is that it really has this perspective of integrating many different GraphQL data sources, and that's why even as there is a lot of other super exciting things happening in the GraphQL ecosystem, Apollo is really about how you get all that stuff into one graph so you can have the benefit of all of it.
David: When I look at GraphQL, I am reminded a little bit of some of the RPC technologies that came before, because on the client side you have to have some basic awareness of the Function or the procedure that you're going to call on the server side. And I believe those procedures are referred to as resolvers. So one of the questions I was getting at was, well if you have to write these resolvers, these procedures on the server side to do some amount of processing, some procedural stuff, transformations, whatever it may be, are you saying that Apollo Server is flexible enough that if your language is Java, I can go out and get the Java Framework, develop my resolvers there, and plug them right in underneath Apollo Server alongside of the other Node.js platform that you're already running on? Is that how that works?
Geoff: Exactly, yeah. If you want to use Node.js to write resolvers, you can use Apollo Server. If you want to use Java to write your resolvers, you can use GraphQL Java, pick your language, pick your GraphQL Library, and it's all standards-based, and then you can combine all that together with Apollo Gateway and you've got one cohesive data graph. Different teams can use different languages and it can all plug together seamlessly into one shared graph that you have one point of view on. And it's amazing. The really cool thing is the graph acts as an abstraction layer. You can browse this connected map of all your data. It's all beautifully documented. The Documentation's always up to date. It's always complete. A far cry from what we've experienced with some other API technology in the past. You can make anything on the menu and get it and you don't even necessarily need to know. Today this could be a monolithic Ruby on Rails app for example, and tomorrow this could have gotten factored out into five microservices, some in Java, some in Scala, take your pick, and you the user, you the developer of that iOS app or that web app, aren't affected by that change. So that's the power of putting this abstraction layer and this language we're talking about our data into our architecture.
David: Yeah, that's always been the benefit of API technology in general, is that the client is sufficiently decoupled from the server side of the equation, giving you that flexibility and all sorts of other benefits. We won't go into them here. I talk a lot about them in our APIs 101 videos. But I want to come back to... You were talking a little bit... You mentioned this word, so I want to go back to that, which is federation. When you're building big graphs... And by the way, I just want to... Also for people who are still trying to wrap their heads around this, a real good example of a graph that all of us probably have seen and use on a daily basis is inside of Facebook and any application we use, whether we're going through the web front end or through our mobile app on iOS or Android. This idea that everything is connected in Facebook, you've got friends and you're connected to those friends, and there's pictures that those friends have and you can look at those pictures and those pictures are tagged with other things. That's the graph we're talking about. What do you mean by federation and where does that play a role in all of this and what is Apollo doing to help people with that problem?
Geoff: So typically the way the graph starts in a company is there's a product developer or product development team and they say, "Hey, we have to pull data from many different sources. What if we could stand up a graph so that we have flexible access to all these different existing data sources?" And you can do that very quickly and very easily. What you find is at some point, that sometimes you're a victim of your own success and it starts to get popular and suddenly there's a lot of people that want to use this graph you've built and suddenly you also find, "Hey, a lot of the people that provide backend services, they want to get their services onto this graph too." You end up with this situation where you've got this one code base, it's your graph server, whatever language you built it in. It's getting more and more complicated. You've got this problem where everybody owns it, nobody owns it. It's becoming this central point in your architecture.
And you look at this and say, "Hey, I love what the graph does for me. But I don't want to create another model within my architecture, with this graph server." So what a federation lets you do is it lets you say, "Hey, instead of there being one code base, and one team that maintains the graph, let's divide those responsibilities up over any number of different teams." So maybe I'm going to build the recommendation service and you're going to build the inventory service and you're going to build the payment service. And each of these services can be... They can have its own schema in the graph and they can have foreign key references, so each service, the product service can reference the inventory service or the user service can reference the comment service.
You can have good separation of concerns. So each service can handle just their own concern in terms of the data and the mutations they expose to the graph. But it can all appear as one cohesive graph to the end user through this federated architecture. So that gives you the benefit, on the user side, on the consumption side, of looking at is if it was this one beautiful centrally planned graph, while also having the ability to implement it in pieces and decouple the development cycle of each of those teams, which is necessary once the graph grows past a team or two, because what you find is people see a lot of value and benefit from this and they want to scale it across their company and they need a viable model for how they're going to build and deploy that. So that's what federation is all about.
David: Yeah. And of course the common thought on microservices architecture is that this should be Decentralized out to the departments so that you have departmental responsibility for the various services. It shouldn't be a central IT department to wrestle all of this to the ground. If you're responsible for customer data, then you provide the schema and the services for getting customer data into the larger graph. And if you're the one who provides product data in another department, you deliver that. And that division of responsibility works really well for the more advanced organizations today that get the advantage of a microservices based culture. I think that seems to be where things are heading.
Geoff: Yeah. And the graph can provide you a very smooth path to that. So you can start with one graph, it's just built by one team. It's very simple and centralized and you can easily pull out pieces and federate it as you see the value in it, and as it proves itself to you.
David: But what does Apollo do? Do you have a separate offering that ties the whole thing together? Or is that part of Apollo Server? What do you—
Geoff: We created the Apollo Federation Standard based on working with quite a few large organizations who were getting to this point. So we provide both Apollo Gateway, which is a federation gateway, so it solves the problem of... GraphQL in many ways is fundamentally about what's the interface between your data center and the outside world? So you're going to have any number of different ways you might stretch your APIs inside your data center. You might use GRPC, Thrift, REST, you might have some Service Mesh architect, any number of different ways you can do it. But what's the abstraction we're going to put on that for the outside world? You need a gateway so when those queries come in you have a way of having a query planner, effectively, that says, "Hey, this is query, I'm going to figure out which services it touches and I'm going to figure out the right order to call the services. How do I turn this query, which expresses the user's intent, into a set of operations I'm going to perform on those different backend services?"
We provide a public gateway, which is a complete open source federation implementation that has a query planner, all the stuff you need, and we provide Apollo Graph Manager, which has federation support, because the key problem you have to solve is... Look, now we're going to have all these different teams who are all building their own part of the graph. We want to give those people complete flexibility and complete agility to just go build their piece and not worry about it. But if you think about it, we're actually tackling a pretty complex problem here because if the product service and the inventory service, they both reference each other, we need to keep those things in sync and we need to keep the user in sync with what's happening.
So, Apollo managed federation is a feature in Graph Manager, so these services teams, as they're developing their services right inside their Continuous Integration pipeline, they can check to see am I staying in sync with the other services, that gives you the confidence to ship multiple versions of your service a day. Knowing the product service is going to stay in sync with the inventory service, it gives you the ability to say, "Hey, I've changed some of these services. I'm going to roll this out to the production servers. I'm going to take all the schemas, check them for consistency, find any problems, validate it against production traffic." "Okay, you changed something. Is this going to break any clients?"
If it's going to break a client, "Hey, can look at the last 30 days of production traffic and say, 'this is going to break an iOS app that we shipped two years ago in India. what do you want to do about it?'" And then take all those changes and roll them up into a deployment of the new version of Apollo Gateway with the new configuration, new query planner inside of it. It solves all those problems for you in a seamless and automatic way, which means you don't have to go build all that stuff to manage your graph. You can just get back to building your app, go back to building your applications, and it's a very fast and easy way to roll this out.
David: I could talk to you forever because it sounds you've understand GraphQL better than anybody on the planet. You guys have had the early mover advantage in terms of providing a great platform so that people like Bob can go off and deliver GraphQL APIs. Bob, one last question for you. When you are writing our big GraphQL series, you didn't know anything about GraphQL when you got started. How bad was the learning curve or was it pretty simple? Were you able to get up and running pretty quickly? That's something that other developers are going to want to know about.
Bob: The learning curve was not arduous. It was okay. It was okay. It took me a a while to wrap my head around some concepts. The big one was really was pagination, was handling pagination, and there's a very particular way you have to do it. Because it is fundamentally stateless, you make one trip to the network and you get back your data, you have to have a way of communicating back to those servers about what your pagination state is. And it took me a little while to get my head around that. There were some other things. It's in the article, I think I point them out in the article, things that I had to pay a lot of attention to. It wasn't, "Oh my God, how did I get here and when is this going to go away?" Actually, it was quite enjoyable. It really was, and it really allowed me to think differently.
David: Well, great to hear. Hey Bob, thank you very much for joining us.
Bob: Happy to be here.
David: Yeah, that's Bob Reselman. He is one of the authors of many of our technical series on ProgrammableWeb, and Geoff Schmidt over there at the Apollo headquarters. I want to thank you very much for joining us.
Geoff: It's a pleasure. Call me anytime.
David: Yeah, we're speaking with Geoff Schmidt there. He's the CEO and co-founder of Apollo. Geoff, where can the developers and everybody else who's watching this video find you guys?
David: Bob Reselman has of course written many of the technical articles that you can find on programmableweb.com. For ProgrammableWeb, I'm David Berlind. I want to thank you very much for joining us. If you want to find more videos like this one, you can come to programmableweb.com or you can go to our YouTube channel at www.youtube.com/programmableweb, and there you'll not only find this video but a whole bunch of other ones that we've recorded, so feel free to go up there, share the videos if you like. If you want to come to programmableweb.com and find the version there, we also add the full text transcript of everything that was said as well as the audio only version so that if you just want to listen to the audio, you can. In fact, you can get that audio by downloading it from iTunes or Google Play Music as one of our podcasts from ProgrammableWeb's Developers Rock podcast. Thanks again for joining us. We'll see you at the next video.