Ep. #25, Adopting GraphQL with Graphcool

Brian Douglas: Welcome to another installment of JAMstack Radio. In the house I've got the co-founders of Graphcool. Johannes.

Johannes Schickling: Hey, I'm Johannes.

Brian: And then we have Soren too as well.

Soren Bramer Schmidt: Hey, I'm Soren, glad to be here.

Brian: Cool, and for the listeners, if you aren't caught up with all of our episodes, Johannes was actually on episode 13 not too long ago talking about Graphcool and how it got started.

But there's been a lot of changes in the last year. Almost a year since we talked last. So, what's new with Graphcool?

Johannes: Oh wow. That's quite a lot. I think the last time we spoke we were just launching or just launched, I think. And back then we really started out as a GraphQL backend service.

GraphQL was fairly new, we were spending most of our time explaining to people what GraphQL is. Now GraphQL has become really mainstream, both for people to introduce in their companies, but also to build new services around GraphQL.

So we had quite a lot of progression forward from GraphQL backend service, and now we are moving more into, we just open source basically Graphcool as a backend development framework. So there we've seen a lot of change over the last year.

Brian: You guys were pretty early on on the whole bandwagon of starting a company around the idea of GraphQL. I thought that was way interesting. So did you guys have any issues trying to keep up with the spec as it was evolving? I know we had subscriptions in the last year, and we might have live queries coming soon.

Johannes: Right, right. I think subscriptions were particularly interesting since it was always talked a lot about from talks and different people being excited about it. But the spec has always been rather lacking behind.

It was never like that the spec was moving so quickly that we couldn't keep up, but rather the other way around,

that the community is moving so quickly and the spec has problems to keep up to the demands of the community and what people are already adopting.

So, subscriptions, for example. We're working together with Apollo on different experiments on implementations of how that looks like, release a couple of implementations, and then together with Rob from Facebook we eventually landed on a good format that we eventually put into the official specification.

But currently, like you mentioned, live queries and a lot of other things, they're way more ideas that could potentially be put into the official GraphQL spec. Just for reference, just last Friday after the GraphQL Summit we all came together at Facebook, for the GraphQL working group, where we were speaking about all of these exciting new features. So that's super interesting.

Brian: Yeah, that's interesting that you brought that up, too. Because I was going to ask if there was some sort of committee, like TC39 to talk about GraphQL.

So you say it is a working group, is this something that's been a round for a while? Or did you guys just, everyone that was here of the GraphQL Summit, did you guys just happen say, "Hey, let's meet"?

Johannes: Right, this was the second time the GraphQL working group came up. At the GraphQL Europe conference earlier this year, we came all together and we were speaking about how can we make GraphQL more of an open standard? How can we have the community's say on where this is going? And how we can have something similar to TC39?

There the vague idea of a working group came up. And yeah, about two months ago we had our first meeting. There was a globally remote call with around 20 people, literally all around the world, where we had people from Atlassian joining from Australia, people from Apollo here, people from Facebook in Menlo Park, us joining in from Berlin, a couple of other people joining in from all over the world, where the agenda of all of this is in public.

So there is a GitHub repository on graphql/graphql-wg for our working group, and there you can always find the agenda, people can create a pull request on what they want to talk about. And so whoever feels compelled to add a certain item to talk about, or what they want to have as part of the spec, our handling live queries, co-generation, this meeting is a great format.

Brian: You mentioned GraphQL Europe too, that also happened since the last year. But we also came off GraphQL Summit, and also tying into your mention of the community growing, and making decisions. We've seen the community grow quite a bit, so what's your take on the growth of that community and also the adoption of GraphQL?

Johannes: Right.

Brian: You think it has some staying power at this point?

Johannes: Oh yeah. It was pretty clear for us already a year ago otherwise we wouldn't have bet so much on it, but we are rather surprised of how quickly also bigger companies are adopting GraphQL.

There are a ton of companies where we don't even know that they are already adopting GraphQL, then some point they pop and say "Hey, we've been doing this thing for the last two years."

So, IBM is, for example, one of these companies where we were super excited that they are using it internally. And the community is really fostering, so we have meet-ups all around the world, like in Sydney, in Asia. A lot of them in Europe, in Paris, London, Berlin, Barcelona, also a lot of them here, in New York.

Brian: Yeah, San Francisco is one block away.

Johannes: Yeah, exactly. The community is just exploding there. Our Slack community is actually now one of the biggest melting pots of GraphQL.

Brian: Yeah, I think I saw it was 20, over 2,500 just in general?

Johannes: We have almost 6,000 now.

Brian: Okay, well maybe I was looking up the wrong one. The wrong channel.

Johannes: Yeah.

Brian: Yeah, that's a lot.

Johannes: That's the biggest GraphQL community so far.

It's just amazing how people can help each other to get GraphQL adopted. There are so many different patterns now emerging of how people use GraphQL.

I think an interesting pattern is to distinguish GraphQL as a gateway technology and GraphQL Native as a way to build new GraphQL applications. And yes, it's just amazing to see so many applications.

Brian: Speaking of it as applications, I'm not sure if you can speak on this. What are the technical challenges for adopting GraphQL in a company? Because I know everybody's got REST APIs, and I assume you guys are using it internally. Do you guys use GraphQL internally for your staff?

Johannes: Of course.

Brian: Okay, yeah.

Soren: Most of our internal tooling is built on Graphcool with GraphQL.

Brian: Okay.

Johannes: Yeah.

Soren: So it's kind of two ways you go into GraphQL as company. Either you have existing infrastructure, you have existing rest IPI, and what you want to do is have a GraphQL proxy in front of that, have a coherent API. That's kind of your entry point, is your GraphQL.

The other issue is you want to build new features, you want new products, you just start from the bottom up with GraphQL. That's kind of what we call GraphQL Native development.

Brian: Okay, yeah. I just saw a blog post you guys had put out. Actually, I just read it on the way, on the train, the third time, because I thought it was so great. Talking about the two implementations that you're talking about, like the entry point where, my talk at GraphQL Summit was all about wrappers and using GraphQL wrappers.

I started the Native side first, of just trying to get on to our API, like, attached at the hip. But I found having the GraphQL gateway as you would put it, being so much more approachable, but also a better selling point to get introductory GraphQL into a product, or encoding Netlify as where my main focus was.

Johannes: We actually wrote it three times...

Brian: Oh, yeah?

Johannes: So, glad we had these situations on both sides.

Brian: Yeah? So now large companies are attaching themselves. Is there any pain points that people are seeing going GraphQL first, or GraphQL Nnative?

Soren: When you do build out a GraphQL API, then you need to start to think about, how do I query my data? How do I expose my data in a way that is fast and flexible? This is where you need to start to thinking about the data, the pattern and efficient query and how does that fit into my existing databases.

Do I need to start actually scaling this out in a way that I didn't have to think about before? Those are kind of the technical challenges companies have to face.

Brian: I missed a lot of talks at GraphQL Summit. I was very focused on my talk the first day, and then the second day I ended up sneaking away to actually a recording for JAMstack Radio.

So I missed a lot of talks at GraphQL Summit, but I'm not sure if it got brought up, the idea of performance. I know Apollo's engine, it's now going to have way more features. But performance in GraphQL, is that something that's a big focus point on GraphQL as of the short term?

Soren: Do you mean on GraphQL or Graphcool?

Brian: Just Graphcool, GraphQL. Actually do you guys have a solution for something similar, like being able to see a performance, to see if your queries are bad?

Johannes: I think this is where you have to clear, this is why it's so important for us, that people understand the distinction between GraphQL as a gateway, and GraphQL native to build new applications.

We are all the way on the GraphQL Native, and we run, make it really simply for people to build new scalable production-ready GraphQL backends. That they also can then compose together in an API gateway layer with existing legacy infrastructure. I think, in this API gateway, this becomes a really crowded area.

We've learned about tons of companies who are building what APG was now for GraphQL. And this is where, also, Apollo was in use product tries to solve a couple of problems with error handling or caching, and I feel like this part of this API gateway, this will be a really tough domain to be in since it's both from the business point of view, attacked from open source.

Most of these things are better solved by open-source technology, and also by just so many businesses trying to own that. At the same time, this is where you best address things like performance and caching.

Brian: I wanted to talk a little bit more about what you mentioned earlier. You guys now have a framework that you just opened sourced?

Johannes: Yeah.

Brian: Can you talk a little more about the decision behind that and how you guys first started as "Backend as a Service."

Johannes: Yes.

Brian: And that makes a lot of sense, but now you have a framework that's open-source. What was that decision?

Soren: Right, we started out early last year, early 2016, with this idea, Okay, let's have this ease of use what Firebase or Parse provided us and let's make that available based on a modern stack.

That works nicely with GraphQL, which is built for racked applications, and so on.

The idea was having a GraphQL backend service also play nicely with serverless functions, and so on. And this was mainly trying to solve the technical limitations of previous backend service. This is what we've been working on for the first year.

Where we've come already pretty far away, and got tons of adoption and a lot of people. A lot of companies using it in production.

We've constantly got one important bit of feedback, which is that people are afraid of vendor lock-in.

After what happened to Parse, that they got acquired and then eventually shut down, and that people are betting, typically their company, on some technology that they don't have any control over.

So people were asking us, "What happens to you guys if you shut down?" For us it was always clear. Okay, if we were to shut down, we would just open source everything, that people have this piece of mind. And then we kept thinking, what if we would just open source it right away? What downsides would we have?"

This, combined with another requirement that people want to, one, develop locally, and run Graphcool locally, and also deploy it on their own clouds, this ultimately let us to take this huge step forward.

Okay, Graphcool is now an open-source backend development framework that you can run locally, deploy in your own cloud, and you still have the ease of use that you had before with backend service, since we integrate nicely into a cloud deployment.

Brian: That's a pretty awesome and bold move too. Because I know when I,

my initial introduction to Graphcool was through the Pokedex.

Johannes: Oh, yeah.

Brian: All those applications. One thing that was really cool was that, not only was able to walk away through during that tutorial and have a Pokedex or GraphQL implementation React app, but also gave me examples of ideas of what I could do with Graphcool.

One thing that you would get if you could get all of your Pokemons in from a query, so that right off the bat I'm like, "Oh, okay, I can do queries. I can get all my data, or can just send an ID and get one ID back." So that's kind of how the basis of my GraphQL learning started.

Soren: This was through Learn Relay, right?

Brian: Yeah, Learn Relay.

Soren: Okay okay.

Brian: I was able to take those queries and then mimic that when I was actually doing my Netlify implementation. And then mirror queries that looked just like that.

But a lot of times, and I think there was another individual that I was learning GraphQL with at the same time, we thought to ourselves, "If we could just know what the Graphcool team did to make these queries, then we'd know exactly what the structure is."

Having a framework to look into, and also seeing, being able to look at the code, makes it a lot easier to really understand and be confident in the bet that you're making with GraphQL/Graphcool.

So going forward, I think it makes sense. I don't have to have the concern if I make the decision to start with Graphcool.

Johannes: Exactly. It's so important to have this peace of mind really to make a decision for what's part of your stack.

Brian: What I'm seeing in GraphQL,my experience was, I had to sell to the rest of the team. Because not everybody in the team is doing JavaScript development or React, or anything cutting edge.

We do have C++ development and we do have some gophers from the team as well who are just into doing Go code. But I had to sell the whole team, because we're a small team, on GraphQL as a technology that we should do in the future. I walk in there with this cool, hip React code and this cool tool called Graphcool, then I could see. And that's what I saw.

A lot of pushback and questions, and answers that, I'm not a CTO, I don't have all the answers for this. I don't have years upon years of experience, and I haven't seen the web develop from whatever came from Rest, to now have Rest and then now the evolution to making your Rest really wrap with GraphQL.

I'm excited to see what you guys are doing, and I know the open source repos. Do you want to talk about those a bit? Some of the projects I know, you guys have Chromeless.

Soren: Right, yeah.

Brian: And what else?

Soren: We've been working on a ton of different open-source projects, mostly related on GraphQL, some around serverless. You just mentioned Chromeless, actually has nothing to do with GraphQL, but still something we are pretty excited about, actually our fastest-growing open-source project.

I think maybe it was actually one of the fastest-growing open-source projects ever.

The day we launched it and we released it, I think in the first 24 hours it's got around 5,000 stars on GitHub. And we're all the way up on Hacker News, and trending on GitHub for a week or so. So what Chromeless is basically, it allows you to run a similar, like what Selenium tests were...

Brian: Well, they still are.

Johannes: Exactly, exactly. So, it's a solution for that. But running on headless Chrome, and we managed to actually make it work on AWS Lambda, so that he can, your integration tests are your bot scraping, or whatever you want to do in every browser, you can distribute and paralyze on a huge serverless cluster.

That allowed us to reduce our integration tests from 20 minutes to 20 seconds.

And yeah, we felt pretty excited about this technology, and we open sourced it. We were also working on, of course, the framework that's open source. But we have also, a couple of weeks ago, open source GraphQL Playground. So if yo haven't checked it out, I highly recommend it.

It's kind of like a GraphQL IDE. I think this is one of the typical aha moments for people who are just starting out with GraphQL, that they have this graphical editor.

Brian: Yeah.

Johannes: And I think this is a component of GraphQL Playground, but the GraphQL Playground is more meant as a daily tool for you to work with while you're developing your GraphQL API. So I think about it like Postman for your GraphQL API with a ton of features like subscriptions or history, or tabs, that you can share your Playgrounds, and so on.

It's a really tool meant for daily development with GraphQL. Besides that, we've done GraphQL requests, which is this smallest GraphQL client, both for frontend and backend. We've done GraphQL config, which is the foundation for a lot of GraphQL tooling, to the GraphQL CLI, which helps with common workflows. And most of them are just on our GitHub profile.

Brian: So the Playgrounds, can you create shareable links?

Johannes: Yes, yes exactly.

Brian: Okay, cool.

Johannes: You can basically have your entire development environment, where you say, "Okay this is my actual GraphQL endpoint I'm working with, and here I have different tabs so on the first tab I want to query this certain piece of information."

In the second tab you have a couple of mutations and you would just want to say, "Let's share this with my co-worker that he or she can help me debug this." So you can just share URL, open it in a browser, or open it in your local electron app, and that's a pretty essential part of the workflow.

Brian: Yeah, I need to check that out. The way I saw Playground was more of an enhancement to Graphcool. Graphcool is good out of the box, and it's great for giving the aha moment, because you just open up the Electron app and you show your co-worker or your boss or people in stage. But yeah, Playground looks a little nicer. So I'm actually happy.

Johannes: It's just like a bit of heavier expansion of that. And Graphcool, for example, doesn't support subscriptions or history and so on. So this is where GraphQL Playground is meant to come in.

Soren: The Playground is a plugin replacement.

If you're using the Graphcool right now, just switch it out to Playground. It's so much better.

Brian: Yeah, my experience from more the native side, building my own, has been through the GraphQL regen, and then a Graphcool has a Ruby gem that you just add to your project, because does the Playground also have a Ruby gem?

Johannes: Not yet, but it comes with middlewares for every node server, and we are just about to create for Scala and Java and Ruby, integrations for these, just takes a bit of time to build all of this.

Brian: Yeah.

Johannes: If you actually want to contribute one to Ruby, that would be fantastic.

Brian: Yeah, I need to finish my GraphQL setup, and then that will be my next thing.

Johannes: Awesome.

Brian: If no one beats me to it, everybody slow down development so I can open source cred. So you mentioned Scala as well, and a couple of the pushbacks that I had throughout the year of me personally, my GraphQL development.

And selling gophers that I work with, Go developers, was that GraphQL, it seemed like a node thing. Do you see a lot more adoption outside the JavaScript community now that we have a lot more larger companies using it? I know you guys use Scala as well, so how's that community?

Soren: On the Scala side, GraphQL is certainly not just node, it's all the major languages. And especially Scala has probably the most sophisticated implementation, I would say it's even better than the node implementation. So on the server side, there's no issue whatsoever in using other languages.

Brian: But as far adoption of the community, as a community, the Scala community, are they embracing this GraphQL, what do you guys call it?

Soren: Sangria.

Brian: Sangria, that's what it's called.

Soren: Yeah, absolutely. Yeah, it's being used by a bunch of big companies.

Brian: Yeah, I think Twitter's a Scala shop, right?

Soren: Yes it is.

Johannes: Yeah, okay. I would actually go as far as saying that the bigger the company is, the more likely it is that the core GraphQL crossover is not implemented node.

But GitHub for example is one that's implemented using the Ruby implementation. Shopify is one, like Seren said, Twitter, Coursera is using Sangria. I think New York Times is also using Sangria.

Brian: I believe Twitch is using the GraphQL Go side of it. There's a lot of them on this side.

Johannes: Maybe that, I'm aware that a couple of companies also use Java heavily, some companies use Elixir heavily.

That's a fantastic thing about GraphQL, it works across any technology.

Soren: I think that's super important, actually, that GraphQL is this open standard that you talked earlier about the evolution and could we keep up with the standard. It's a really important point that it's a fairly conservative standard because there are so many players in GraphQL. So the committee is very deliberate about adding new features to the standard.

Brian: Yeah, that's awesome to hear, and I think it's giving a lot of the listeners reassurance to check this out. So, I guess now the question is, what's next with Graphcool? I know you guys are a growing company. How big is the company now?

Johannes: Right, so we're currently around 10 people.

Brian: Cool, 10 people. Mainly in Berlin?

Johannes: Yeah, so we're just about to open a small office here in the Bay Area around dev evangelism, helping companies to adopt GraphQL, small sales team here. And product-wise, it's really like the framework was the next big step after the backend service.

The next steps for us is making sure that the components that are part of the framework can be used standalone. There's a serverless function component. This is what you want to integrate more and more with other Functions as a Service providers, and for example, the serverless framework as well.

At the very core of what Graphcool is is what we call this GraphQL database. This is what we also want to make, standalone that people can use with their existing database. Have that really as an abstraction over your database that you can use GraphQL to define your data model, evolve your database layout this way. And also have a GraphQL API out of the box, over your database to just make it way quicker how you can implement a real production-ready GraphQL API.

So on a high level, it works like this that any GraphQL gateway, you would basically compose and define your GraphQL API by reusing the data capabilities of your GraphQL database. In the API gateway you would implement authentication, authorization and all of that. So this is where we really see Graphcool as a technology evolving.

Brian: I know you guys maintain the How To GraphQL. Or you guys Kickstartered that project.

Johannes: Yeah. You've mentioned Learn Relay, we've also a couple of months later done Learn Apollo, and we wouldn't have expected that the community would grow so much. But we've had all of these different ideas where people want to have also learning resources in a similar format so we didn't want to buy a ton of the mains and maintain all of these different resources.

We said, okay let's take our learning from Learn Apollo, Learn Relay, and create one resource out of that which helps people to get started with GraphQL with any frontend and any backend technology.

So they're like for Relay, for Apollo, for Amber, or Angular, for all of these different frontend technologies, but also for every backend stack like Java, Scala, Ruby, and just where we were working I think with more than 20 people out of the GraphQL community to keep these up to date. And it's really the go-to resource for new people to learn how to get started with GraphQL.

Brian: Awesome, I'm excited to continue to see this, well, see you guys grow, but also see the community grow. What anecdote that I got from the actual conference that I just thought of when you said Ember, is years ago I worked with a developer back in the Rails days, I did Ember for a little bit, he stayed in Ember. And he's actually the maintainer for the Ember GraphQL implementation.

Johannes: Okay.

Brian: And he was actually at the conference.

Johannes: Yeah, we've met him, that's amazing.

Brian: Yeah. it's over at Envy Labs, and yeah it was a small world. It's funny how GraphQL is now connecting people.

Johannes: Devan, right?

Brian: Yeah.

Johannes: Shout out to you.

Brian: Yeah, I definitely pick, check out the Ember Apollo, I think it's at Ember Apollo?

Johannes: Yes, Apollo.

Brian: Yeah, the Ember Apollo implementation.

Johannes: Relay hasn't fully lived up to its expectations yet that you can enable for also non-React for it. Theoretically you can, community just haven't come around to do that yet. Maybe there are some smaller projects, but hopefully that's also something that we see in the future.

Brian: Yeah, looking forward to it. I'm looking forward to, Relay Modern looked really interesting. But I was so invested in Apollo at the time it came out, so I never made the jump back to Relay for any projects. I think a lot of people where in the same sort of position but it'd be good to see another implementation with Relay going forward.

Johannes: I think both are fantastic clients.

Brian: Awesome. Well, with that I'm going to transition us to picks. So, JAM picks are things you're jamming on, things that are getting you going. This could be music you listen to while programming. Or things that you like to do when you're not programming. And Johannes, since you've been here before. I'll let you start with picks.

Johannes: All right, since you also mentioned music, I'm pretty much into drum and bass. And I've just found a new track by Keeno that's, I think, an artist from the UK. Just came ut with a new album and the particular track called "Cosmic Creeper." So that one is definitely a new all-time favorite for me.

In terms of more tech stuff, I want to give a shout-out to Manifold. They're creating an amazing platform around combining different dev tools. And what they want to do is, what they call the Steam for dev tools. This kind of a vague but provacotive, bold description.

I'm super excited what they are doing. Just allows you, one platform, to connect things like Netlify or Graphcool, and help you to maintain all of the services that you need to run apps.

Brian: Cool. Soren, do you have any picks for us?

Soren: I'm going to be a little bit old and boring, but I'm all into cloud infrastructure, service infrastructure as well. I love Jeff Barr's blog on new stuff on AWS, that's my thing.

Brian: Cool, and was this AWS re:Invent? Is that this week?

Soren: re:Invent is a month from now, roughly.

Brian: Oh, it's a month from now, okay. Cool, well I will definitely check out. I didn't even know his name until now, but I will definitely check out his blog, for sure.

My picks are actually, I want to pick Spotify playlists. Specifically, I've been getting back into '90s R&B, so I'm just reliving my childhood. Through Spotify. And yeah, recently I got into Aaliyah, which is someone I listened to when I was a kid but I never actually listened to it until I got, I'm listening to it now.

I'm like, wow, this is actually really good stuff. It's sad that she actually passed away. So I'm getting the '90s R&B, but from that playlist.

There's actually a YouTube video, it's a TED talk. This is transitioning to second pick, which is "Learn How to Do Anything in the First 20 Hours." And this guy taught him how to do ukulele.

He basically maps out a plan of how to learn a new skill. And he learns ukulele, and he found out that every pop song is basically a four chord progression. So it's the same chords no matter what key you're doing. And so he basically goes through playing all these pop songs with the same four chords.

So I took that same structure, and on the ukulele I play Montell Jordan's "This is How We Do It." And it works.

Soren: That's awesome.

Brian: You can take any '90s R&B song, and it works with those four chords. You just have to figure out which structure you're looking for. And what key you can actually sing in.

Johannes: How's your progress?

Brian: It's good. I actually watched his video years ago, so I learned ukulele after I watched that video. But I never actually took that to heart and actually played. But yeah, it's good. It's just my problem is, I always forget the words to songs.

I can hum it like no-one's business, but when it gets time to, "sha nah nah nah," I can do that really well. But I don't remember whatever the next words are. But I can play chords pretty good. So those are my picks, and this is JAMstack Radio. So guys, thanks again for coming in all the way from Germany, just to do this podcast.

Johannes: Definitely.

Brian: You guys had nothing else to do except this podcast.

Johannes: Yeah, that was totally the reason. Thanks for having us.

Brian: Awesome. And listeners, keep spreading the JAM.