Ep. #11, Exploring GraphQL Through Apollo

Brian Douglas: Welcome to another installment of JAMstack Radio. We've got Sashko.

Sashko Stubailo: Hello. I'm the tech lead on the Apollo Open Source team.

Brian: And then we've also got Jonas on the line, calling in from Taiwan, is that correct?

Jonas Helfer: Yeah, that's correct. Usually, I'm in SF. Hi, I'm Jonas. I work on Apollo Client and some of our other Apollo open source projects at MDG.

Brian: Cool. Let's, like, let's jump right into that. The listeners are probably really interested in knowing what Apollo is. So can one of you guys explain what is Apollo? Just give us the Cliff Notes, and then we can jump into even more questions after that.

Sashko: Yeah, that's definitely a good first question, because I feel like you always go to websites and they don't tell you what the thing is, right? Yeah, the idea behind

Apollo is an overarching name for a set of different tools we're working on to make GraphQL easier and better to use.

The main concept is that we think GraphQL is a really great technology. It's really well designed. But the ecosystem of tools around it is not super mature yet. So we're trying to fill in the gaps where we think we can have the most impact. The biggest tool that we're working on that I would put the most effort into and a lot of people are using is Apollo Client, which is a JavaScript GraphQL client that works with pretty much every UI library, including React, Angular and Vue.js.

Then we have some server-side tools and also, we're working on native mobile clients. So we have a Apollo iOS client, and then also some production commercial services like Optics, which is a tool that lets you inspect your server-side GraphQL API in production.

Brian: Cool. GraphQL is an interesting topic, because we just had an episode on GraphQL with Kyle Daigle from GitHub. He talked a bit at the GraphQL summit where we met, and they also talked at GitHub universe. I guess my questions is, how are you guys so forward thinking about GraphQL, when GraphQL only came out of developer preview in August? Like, were you guys already working on something similar prior to this? Like, how are you so far ahead of the curve, I guess is the question I'm looking for an answer for.

Sashko: We just completely think GraphQL is the right solution to the kinds of problems that it's solving. We were at some of the conferences and stuff when it was originally announced, and we found it pretty intriguing. In parallel, a lot of us have worked on Meteor in the past, as well. Meteor has a very sophisticated data system. The way we got super interested in GraphQL was, we were trying to bring the principles of that data system to a wider variety of front ends and back ends.

The part about GraphQL that appealed to us the most was that it solved a lot of the problems we've seen before in data loading system. Specifically the ability to fetch a lot of related data in one request was something that came up over and over again and not too many systems had solved.

The other thing that's really important is that GraphQL is a specification and not a specific library. So it's open to implementations in a variety of languages, a variety of back end data stores and a variety of client technologies.

It was something that we felt comfortable really investing in because it didn't limit us to any particular set of those things.

Brian: How does Apollo Client integrate with GraphQL at this point, then?

Jonas: Apollo Client, as the name kind of says, is a GraphQL client. We've written in typescript so it's used by people mostly in the browser, but also for React Native. What the GraphQL client helps you do is, send requests and cache those responses on the client. Because unlike post-requests, for example, which don't give you a lot of information about what data you're getting back, you actually know what part of the tree you're requesting because the GraphQL request contains that information.

So what you can do is, across different requests, you can cache content. And if you make a similar request that overlaps with something that you already have in the cache, then Apollo Client can serve that from the cache before it hits the server. Or when you make a second request, it can update a part of the cache that was requested by a first request, and thus keep your UI consistent. That's pretty much the main purpose of Apollo Client.

Brian: Cool. I peeked at GraphQL a year ago, I guess. I went around after the React conference. I know they've kind of led with Relay. How would GraphQL and Relay stand next to each other?

Jonas: Relay is actually more comparable to Apollo Client than GraphQL. So while GraphQL is a specification for the query language, Relay and Apollo Client are GraphQL clients, which means they help you send GraphQL requests and keep your UI consistent and integrate that with UI layers. Relay, for instance, integrates with React. It has its own Relay router. Apollo Client integrates with React, Angular, and I think people have also made integrations for Vue.js and Polymer now.

So Relay is more like Apollo Client than GraphQL.

Using GraphQL alone without a GraphQL client gets kind of tedious

Because then you're still just at the level, essentially, of sending post requests and having to do all the hard work yourself on the client with making sure that your UI stays consistent if you do several requests that send back overlapping data.

Brian: You kind of led with this, Sashko. There's not a lot of tooling with GraphQL at the moment and Apollo is kind of solving that problem, kind of pushing the space forward. Is that correct?

Sashko: Yes. Apollo is basically informed by a lot of the needs we heard from people that we talked to, back when we were initially investigating GraphQL. One of the first things we did was talk to dozens or maybe even 100s of people who'd used different data systems, had used GraphQL in the past or were using it currently.

Apollo Client is newer than Relay. So it learns from a lot of the things that Relay did and, we like to think, improves on a lot of them, and currently is, as far as we can tell, the most popular choice for people who are using GraphQL with their React or Angular apps.

So that's been pretty interesting. It'll be interesting to see in 2017 what happens in the GraphQL client ecosystem, as well. Basically, when GraphQL first came out, Relay was the client that Facebook shipped with it to start with. And a lot of the talks introduced them at the same time. But as we're moving into GraphQL becoming more of a standard with a lot more people using it, there are now a lot more options for all different parts of the stack.

Brian: I think it's important, too, that, I mean, you guys are really pushing the space here. Not only do you integrate with React, which helps integrate with other front end libraries, that, like Vue.js, you mentioned. I know I just saw yesterday another guy had put out his own version of the Ember Apollo library, or the client, rather, which is super intriguing, because I like using Ember for quick and dirty, like, prototype apps that can be very CRUD-focused. I'd like to try that out eventually.

Sashko: I think one cool thing to mention is, one of the primary principles of Apollo, if you go to our website, is basically being compatible and integrated with stuff. So it's not just a few layers. It's also a variety of other technologies. Like, people have integrated it so it integrates deeply with Redux, first of all, and DevTools and stuff like that. People have used it with Maw-backs and CycleJS.

You can use it with various tools that make it work offline. You can use it with React Native. Basically, the idea is

If we find something that puts Apollo in conflict with a different adjacent tool you might be using, then we work hard to make it compatible with those things.

Because we don't think people should have to go create a totally new library just because there's something that's blocking them from using it with their other favorite tool.

Brian: Yeah. That's good to hear, too, because questions that come to me, because I've been using GraphQL for a couple months now, and that come up to me is, like, things like just normal things you'd normally do with Rest. Like off tokens and any sort of handling of data that goes between the API and a client. I guess at the heart of GraphQL, it doesn't take the place of your SAPI, but it enhances it, really, by adding that. So I know there's another thing called Apollo Server. How would that differ between the actual Client.

Jonas: Apollo Server is a server library that we wrote a while back. Basically when you do GraphQL, it's just a specification of a query language. So you need the Server part to basically fulfill those GraphQL queries, and you need the Client part, although the Client part is sort of more optional. You could also just send query strings. Now, Apollo Server was sort of something we started because we felt that it wasn't easy enough to write a GraphQL server.

So GraphQL queries are pretty easy to understand. It's just like this message, JSON-like string that you send. But writing a GraphQL server is a little bit trickier because you have to understand a bunch of new concepts, like resolve functions. So what we did with Apollo Server initially was that we took that schema language, which GraphQL defines as well, in the spec, and we took the schema language and we automatically translated that into a GraphGL schema, sort of into an executable schema, and added resolvers to that.

Then we started realizing that people actually wanted to have an all-in-one solution and not put all the pieces together. So that's kind of where Apollo Server came from. Now we've gotten it to work with Express, Koa, Hapi, and, I think, Connect. We're really looking towards the community for what to build in Apollo Server for what they need to make, kind of, writing GraphQL servers easier.

Brian: As far as Apollo, the team, how big is the team at the moment?

Sashko: I think to preface this question, before I even answer that, I think the most critical part of Apollo is that we're working with as many people in the community as we can. So, like, lots of critical features are built by people who don't work at a specific company, including, pretty much, all the UI integrations, like, 80% of Apollo Server, et cetera. Having said that, the core team is, I think, five people. That's five people working full time on various parts.

Brian: These are Apollo employees?

Sashko: Yeah, that's right.

Brian: Okay, cool. Then, you mentioned open source, was I was going to get at, too, as well, because that's why I asked about the team. All Apollo code is open source at the moment, is that correct?

Sashko: Yeah, there are kind of two parts to the story. One is, we think GraphQL is the right way for people to build apps. Right now, there are some compromises, but we hope in the future that there won't be, really, many compromises. It'll just be the most straightforward option, that you should always use GraphQL. And then the plan is to build as many open sources tools as we can, to enhance the experience, and then for the tools where they need to be production services that need to be operated, then we build those as production services that we can sell to people.

So, like I said before, Optics is the first of those, which is a service that you pay for that collects data from your server and then displays it to give you analytics and performance information. It wouldn't make any sense at all to build a GraphQL client and make it not open source. So that's what we're doing. And then for the things where people need stuff in production or, like, additional tools, then that's where we're going to make some money.

Brian: Cool. As you mentioned, Optics is the first attempt to monetize part of this effort and the moving into the GraphQL space, is that correct?

Sashko: Yeah, that's right. We figured that we should build a tool that is useful to pretty much anybody who's running a GraphQL server out there. So currently, it integrates with any JavaScript server or any Ruby server, and we're working on more integrations with the community. Basically, it's the only GraphQL-specific performance and, like, analytics tool out there. You turn it on and right away, you see stuff that is relevant to you as a GraphQL developer.

Brian: And then, Jonas, you mentioned that the Apollo integrates with things like Hapi and Koa. Those are all JavaScript frameworks, or server-side frameworks, sorry. Apollo Server connects to those things. But one thing that actually really impressed me was that the fact that the community of GraphQL extends outside of just JavaScript. So there's, like, Go clients, there's Ruby clients, there's any, most languages have support for GraphQL.

How about Apollo? Does Apollo also support other languages? If I have already built my GraphQL server, and my database that's actually connected to different language besides JavaScript, does Apollo connect at all to those?

Jonas: Oh yeah, totally. As Sashko mentioned before,

One of our main tenets of Apollo is that each part can be used individually and integrates with as many things as possible. So Apollo Client can be used with any server that's compatible with the GraphQL specs.

That includes, like, the Scala server, Go, it includes all the other servers, basically, that people have written that are compliant with the GraphQL spec.

And Apollo Server is actually just a server for JavaScript or type script, so if you want to run that on Node. And it can work with any GraphQL client, so it works with Relay just as well as it works with Apollo Client. The same is pretty much true of all our other open source libraries that we built around GraphQL. That's really one of the main things that we focus on that.

We don't want to build a stack where each part can only be used if you use most of the other parts of the stack. What we want to build is much more of a collection of individual libraries that can be combined with whatever else people wanted to use. Because we found that that's almost the best way to guarantee that the things that we build are useful to the greatest number of developers.

Brian: For Apollo, I know you guys been out for a bit, quite a few months, actually, or maybe even a year or so now, at the moment?

Sashko: Yeah, I think the first stuff we released was in March of 2016.

Brian: Okay. Are there any companies out there that are using Apollo as their choice for GraphQL integrations?

Sashko: Yeah, there's a fair number. Like I said before, if you look at something like NPM Downloads, it's the most widely used GraphQL technology client. In terms of people we've talked to who are using it in production, some examples that come to mind are Coursera, Credit Karma, we're talking to a few more. Thing is, I know who we've talked to, but I don't know which of them have okayed us to tell people that that's what they're using.

So we have a couple of examples of people who are really enthusiastic about supporting the open source, but mostly we're just focused on enabling those people. We haven't been as focused in collecting a bag on names, unfortunately. Something to look at.

Brian: I originally reached out to you guys right after the GraphQL summit. In between, I've actually, I was tinkering in GraphQL. Now I'm actually building projects in GraphQL, which is interesting. I've also stumbled acron LearnApollo.org. Is that you guys? I think I saw someone from Apollo's on there when I actually looked at the open source . Is that part of you guys, that put that together?

Sashko: LearnApollo is a website that was put together by Graphcool, who are a company that's making a Graphcool back end as a service. As you can imagine, for them it's really important for people who use their service that it's easy for them to learn the client part of that, as well. So we were really lucky to be able to work with them together and people in the Apollo community to create that website.

They have some great step-by-step tutorials on how to build an app. It was actually really fortunate for us that we're not the only ones producing Apollo learning materials now. There's a lot of people who are interested in doing that.

Brian: It probably helps that you guys have open source code. You've got all your stuff out there. Aside from the Apollo Optics, which you guys mentioned, like, if I wanted to see how Apollo works, I'm able to look at the code, I imagine?

Sashko: Yeah, that's right. I mean, that's the only way to get people to contribute to it. So, pretty important.

Brian: That's pretty awesome. And that's great. I actually did the React Native version and also the React version of LearnApollo. They have actually, somewhat what you said, Jonas, earlier, how you guys can connect to different front end tools, they've got all different types of Angular II.

Like, basically, there's different sections. Obviously, you guys know what it looks like. But for the listener,

There are different sections on LearnApollo where they have Angular II and Vue.js. You just build the same Pokemon Pokedex app, and you can just connect it with your Apollo Client, which is pretty awesome.

Sashko: Yeah, the one I'm really excited about, I don't know if this is, like, a spoiler alert. Well, it's not a spoiler to anybody who knows about Apollo, but we also have a Native Swift iOS client. That's something you can expect to show up on LearnApollo eventually, as well. If you're not interested in JavaScript at all, but you just want to build an iOS app with GraphQL, that'll be on there, too.

Brian: Yeah, that's huge, too, because I've got some iOS experience. I think my most useful tool was FireBase whenever I built a iOS app, because I did not want to have to deal with CoreData. CoreData is a bit of a learning curve when you approach, even Swift development. Swift, I think, is a breeze compared to Objective C. But CoreData, it's not as intuitive as far as managing your data. So I've always opted to do a back end into the service. So I think I might look into that.

I'm a big fan of Apollo, what I've seen so far. So I'm actually looking forward to using it for my side projects going forward. And hope that the listeners actually will do the same. Cool, is there anything you guys else wanted to mention, too, about Apollo? Maybe you guys are working on anything else?

Jonas: Maybe the only thing we didn't mention is that we're also working on an Android client. This is with a bunch of people from the industry. I think including some people who work at AirBnB. I don't know if it's officially for AirBnB, or if they're just working on that. Yeah, so that's also going to come out at some point in the near future.

Brian: There was one thing, actually, in addition to that that we didn't mention, which was server-side rendering.

Sashko: Oh yeah, that's true. Basically on the topic of working with things that people want to work with, one of the things that we focused on was making server-side rendering basically trivial. So, often when you're trying to do server-side rendering with React, you have to do something like move all of your data load into the router, or like manually write code that listens for promises or something of that nature.

So we took a different approach, I guess better would be a good word for it, where you can usually just take the app you wrote to run the client, and it will server-side render itself correctly on the server, because the Apollo server-side rendering tools will crawl your component tree for you, collect the data, wait for it to be fetched, and then render that stuff, and, like, properly in-line it into the HTML and rehydrate on the client, all that.

So all you have to do is basically go to the docs and copy and paste some code, and you'll have a completely server-side rendered app in no time.

Brian: Cool. How do I enable it? Sorry, is that a separate plugin that I have to ask for, to get that to work?

Sashko: It's part of the React Apollo integration. You know, it's something that's pretty hard to turn on by default, because server-side rendering is not as simple as it could be, I think, in React in general. But once you've set up your server-side rendering stuff that gets the URL and passes it maybe to React router or whatever, there's just, like, a simple code snip that you can put in there that just calls a function that, like, extracts the data from your UI tree and then passes that in.

So yeah, if you just go to the main React docs that we have, there's directions on how to get that done.

Brian: I'll have to check that out. Awesome. Well, with that being said, let's go ahead and move onto picks. Picks are basically anything that you're jamming on, hence the name JAM. So it can be something tech-related, but it also could be something entertainment-related, so music, food, maybe a restaurant you checked out in Taiwan that we want to hear about eventually?

But with that being said, I'll go first. I did have my first pick, which we did mention already, LearnApollo.org. I highly recommend anybody who's interested in checking out more about Apollo, it's a good intro, just to getting your feet wet. If you're familiar with JavaScript or some of those tools, you can just build an app, connect Apollo and kind of get your, actually, get a pretty good idea of what it's going to do for you, which is pretty awesome.

I have a lot of experience with using GraphQL directly, without using a client, mainly because I just kinda, I was just more interested in GraphQL at the time. But having a client definitely helps handling stuff like, mutations in GraphQL and stuff like that. It's a breeze, and it's almost trivial when you use Apollo with it. So check that out. I have another pick, too, which is, it's an entertainment-related pick, which is a Netflix original series called Travelers.

I just randomly found in on Friday night, and basically finished it last night. It's like a whole 12-episode first season. I won't give away the plot, because if I even talk about it, I'll just give it away too quickly for anybody. But I highly recommend checking it out. It's a good, good binge watch for the weekend. So check out Travelers on Netflix, original series. Do you want to go next, Sashko?

Sashko: Sure, yeah. I think my pick is a little bit more stale now after the Golden Globes or whatever. But I just, everyone who hasn't seen La La Land yet, if you don't think you're going to like it, I didn't think I was going to like it. But now it's basically my favorite movie of last year. I could not recommend it more strongly. There's probably something involved there, which is that I grew up in L.A..

So that might be a good temper to that. But honestly, it's like a totally awesome movie. I thought it was going to be some kind of, like, romantic comedy thing that I don't always like. But it was definitely above and beyond what I expected.

Brian: Is it better than Sing, because that was pretty good.

Sashko: I haven't seen Sing yet.

Brian: I saw Sing last weekend. I'm just going to add that as my pick, another pick, as well. But yeah, kid's movie, Dreamworks, lots of music. It's not actually a musical. It just has music in it. But it was actually better than I thought it looked. I took my three-year-old to it. That was my excuse, but I actually enjoyed it a lot more than I thought I would have.Jonas, you have any picks you want to share?

Jonas: Yeah, I've been in Taiwan for the last month. I've been here trying to learn Chinese. So most of the things, or pretty much everything I did was just using, speaking Chinese. Both of my picks are something to do with Taiwan. The first one is a really good green tea place that I found here. It's like this Japanese Matcha place where they don't just have tea, but they also have a whole variety of desserts that all have Matcha in them.

Brian: Sorry, what's a Matcha?

Jonas: Matcha is just this Japanese kind of green tea that they usually make with this, like, powder. The most common way you see it is that they have this cup of green tea and then they use a whisk to kind of whip it up, and then it has a little bit of froth on the top and stuff. I didn't know they made desserts with that, as well. But those are really delicious. So if you're even in Taipei and you're feeling like having some green tea and green tea desserts, check out the place.

My second pick is a Taiwanese movie. It's already quite old, but it's called Hear Speak. It's a movie about a deaf and mute girl, and her story of how she met the guy and fell in love with him, or how the guy met her and fell in love with him. I'm not very good at explaining this. But it's a movie that I enjoyed watching. It was especially good because my Chinese wasn't that good yet when I arrived, so it was kind of good to watch a movie that didn't have too much speaking in it.

Brian: I have to ask, you knew Chinese before you went to Taiwan?

Jonas: I did, yeah.

Brian: Okay, so in one month, like, on a scale of one to 10, how well has your Chinese improved?

Jonas: How much? I would say, as always, at the beginning, it improved much more than it did towards the end. I don't know, I'd say six or seven. But yeah, it's kind of, you know, you go into a new environment, you lean a bunch of new words, and then, once you know those, you kind of have to push yourself to learn more.

Coming to Taiwan was sort of part of pushing myself. But then, once I was here, after two or three weeks, it kind of levels off and you kind of have to push yourself even harder or put yourself in a new environment where you learn new vocabulary.

Brian: Cool. I was going to say, if you responded in Chinese to my answer, then I would have said it was a 10. But I'm glad you're honest.

Jonas: I don't know how many of your listeners are fluent in Mandarin.

Brian: Oh, you'd be surprised. We actually had a Japanese guest on one of our latest podcasts that haven't come out yet. But we do spread the world, as far as I've seen on Twitter. So if you're on Twitter and you're in Taiwan or Taipei or even in China or somewhere in East Asia, definitely hit us up and let us know where you're from, # JAMstackRadio, that'd be awesome.

With that being said, I just want to thank you, Jonas, and also Sashko for coming on and talking about Apollo. I do highly recommend listeners check it out. You're interested in getting into GraphQL, it's a great, not only entry level, but also even advanced level, to get your GraphQL, like, actual production-ready GraphQL apps working, and working with . So check it out. We didn't mention Apollo has a website, check it out?

Sashko: Yes, so if you go to ApolloData.com, that's our homepage and that has links to both the commercial stuff and the open source stuff. We now highly encourage people to contribute on GitHub. It's always, I think, frightening to contribute to open source projects. But that's one of the things that we're the most invested in, is helping people do that. While I have the microphone here, I obligatory have to mention that we are hiring.

So if you're interested in working on GraphQL stuff full time, either open source or commercial tools or dive-opps type stuff, we're always looking for people who are passionate about that field. So, I think you'd have a great time if you joined our company.

Brian: Awesome, and you guys are remote force, too, as well, too.

Sashko: That's right, yeah. We have our main office in San Francisco, and a lot of remote opportunities, as well.

Brian: Awesome, well, thanks again. And guys, keep spreading the jam.