Ep. #13, Staying Cool With Graphcool

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line, we've got Eli Williamson. Eli?

Eli Williamson: Hey there, listeners.

Johannes Schickling: Hey, Eli. In the booth we've got Johannes.

Brian: Cool. We had you come in to talk a little bit about GraphQL and Graphcool, which is, I think, probably one of the coolest names for a project that I've come across as of late. But can you talk about who you are and how you got here? Maybe a little bit about Graphcool?

Johannes: Sure. I'm Johannes, and I'm one of the founders of Graphcool. I found myself in the situation about a year ago where I'd just sold the company I was previously working on. It was an Instagram for VR. We had just sold that and I had a huge bucket list of technologies I wanted to dive into.

Brian: What was the name of that company that you sold?

Johannes: Optonaut. So I had this huge bucket list of technologies and I didn't have the chance previously to check it out. On top of that list was GraphQL. So I just wanted to kind of dive into it and build something quickly with it. While thinking about it, the concept of backend service really appealed to me. I've used Parse before and I've used Firebase before. But some of the core problems for me was that it's too limited and not really flexible enough. And flexibility on the API level, that was really solved by GraphQL.

I challenged myself to build a first version of a GraphQL backend-as-a-service in a couple of days.

I've built that, and told my friends about it. Not sure whether they'll use it. One of the people I showed it to ended up being my co-founder. He just flew over to London and we iterated on the prototype. And he took it from there.

Eli: Cool, and now you have customers, it's a business and people are using it for their products?

Johannes: Yeah, exactly. We have 1,000s of customers. We are now a team of five people. We've raised a small investment round in December last year from people like the founder of Heroku and also diverse angels from Singapore and London.

Brian: Nice. You mentioned briefly about the limitations of Parse and Firebase. Can you go into more of, like, what's wrong with their implementation of backend as a service?

Johannes: I wouldn't say it's something wrong about the implementation. I think the fundamental difference they've taken and we choose to do is that we wanted to base it on open source technology. And these kind of open source technologies, namely GraphQL, unlock a huge potential of flexibility. For example, Parse gave you a couple of options how to use their service. The most popular one was an SEK you could build into your mobile apps. But it also provided a restful API.

You could do some of the things you can do with GraphQL, but not the whole spectrum. What GraphQL really allows you to do is, you get a super flexible API layer where you just specify, basically, what kind of data you want. You specify the structure of it, and you get back data exactly of that shape. So the flexibility of the API layer is a really huge deal. The other challenge we're trying to solve, and where we currently have probably the most sophisticated solution is our permission layer.

Most backend services don't give you the flexible tools to specify complex permission rules.

For example, you can always say something like, "user Bob has the role page admin, therefore, he's allowed to create posts and delete posts". But you cannot really specify something as complicated as building an Instagram and you say, "this person follows me and I need to activate his following, and then he can see my pictures or comment on these pictures". This is something where we are leveraging the structure of the data graph to let you specify permission rules.

Brian: Okay, and that's similar to a GitHub, where you can have someone in the organization that can have read access but not write access or vice versa?

Johannes: Yes, but you can specify way more flexible rules than that. There is basically no limitation on that. If you want to specify rules that are not really encapsulated in the draft data structure on its own, then you can always fall back to invoking Lambda functions. That's actually the second big part of our platform. One part of it is that it's based on GraphQL. But the real extensibility comes from Lambda functions so that at every given point of time, you can implement your business logic using Lambda functions or you can implement permission logic using Lambda functions. When I'm saying Lambda functions, I don't necessarily only mean AWS Lambda, but just the concept of serverless functions.

Brian: Yeah, functions as a service, kind of, yeah. We actually had an entire episode on functions as a service and use cases for that. So we covered, like chron jobs, form handling etc.

Eli: As a front end developer, I have very limited knowledge of the structure that typical databases use. I know that you mentioned earlier that yours is differentiated from some other folks in this space. Do you mind elaborating a little bit on the relational structure between models, nodes, schemas, et cetera, and then how yours differentiates from some of the other guys?

Johannes: Of course.

You basically define a type system. You wouldn't go ahead and say, "this is how I want to lay out my relational database" in a way that you specify a schema for normalized tables. But you rather specify a type for every kind of model you have in your data model.

Let's say we are building like a Twitter or an Instagram and we have this model called a post. So you would just create a couple of fields for this post. For example, a description, which is of type string, and so on. Then, if you want to also create a model called a comment, then you can just create a relation between these two models. We manage all of the relation handling on our side. That's just abstracted away. It could actually look like we're using a graph database, even though we're using a combination of relational databases in our background and some levels of caching based on Redis, for example.

How that distinguish from other backend service at the moment is, for example, if you look at Firebase. They have just basically this enormous JSON blob you're kind of storing in your back end. You cannot really give it a structure out of the box. You also have the problem that you usually have to duplicate a lot of data. So you have just this one view on your data and then you have to duplicate it, the actually data nodes a lot. That's entirely not the case in our system. We want to really embrace the structure of your data in terms of a graph.

Brian: I guess to reiterate, I just thought of a project I literally just built with one of the bootcamps students I mentor. We built a chat app. In that chat app, we've got rooms. So you can go to different rooms to chat in, similar to, like Slack. Then inside those rooms, we have messages. But the problem with Firebase that we had, which I'm not sure, we didn't dig too much deeper into how to make the relation contain rooms and messages work. But we had to create basically a key of messages and then a key of rooms, and then inside of rooms, we had to recreate the same messages by pointing to the IDs of the keys. So that way, we can kind of cross-filter between the two.

Johannes: Exactly.

Brian: This was a beginner project, so we didn't want to get too deep into, like relations and really try to hack away at trying to make this work. But we just wanted just a quick prototype so that way, our UI worked. It was challenging to create that structure and I could see the way GraphQL set up that, not to be limited to needing to duplicate the data and having that relationship actually work realistically would have been nice.

Johannes: You would basically just create these single nodes representing a single room or a single message. Then you would basically connect these nodes with edges, if you imagine a data graph, and you don't need to duplicate the room.

Brian: Yeah, that's cool.

Eli: With that duplication, is there any duplication of queries? Does GraphQL handle it as a single query or multiple queries. I think Firebase does it that way.

Johannes: Right. We generate a schema out of the box which allows for basically all the use cases you might run into. For example, let's say you have, to pick up on the chat example. You might have a model called room and you might have the model called message. So you get two sorts of queries. One is all messages, where you literally get all messages and you can just filter them down so you just get the messages you are really interested in.

For example, to filter all messages by a certain author or all messages which got sent in the last hour or something like this. Or you could also get a particular message you are interested in and get it, for example, by its ID or by a certain author.

Eli: That sounds pretty handy. Are there any other tools? I know I was poking around a little bit earlier, and there's a few starter kits that are super easy to spin up. Speaking of the Instagram example that you mentioned earlier, I was able to spin that thing up in just a few minutes. I love those little out of the box kits, especially when you're starting to dabble around with some of this stuff.

Johannes: Right. I think your question was, are there other examples? We are actually at the moment working on a pretty big example. Hopefully by the moment this show airs, we'll have a complete intercom example. We want to do like a multi-episode tutorial series where people can build a fully-fledged intercom alternative. They would basically be walked through all the concepts of our platform. While doing so, they would build an intercom they could use in their own product.

Eli: That sounds awesome.

Brian: Yeah, I will definitely be going through that. I like your approach, too. I know you guys are partnered. You created the learnrelay.org, and then also learnapollo.org, as well. I like the approach of just walking someone through a very trivial app. The intercom example sounds a little less trivial, it sounds pretty realistic to use. But like Eli said, I also created that Instagram clone, as well. Just to get your feet wet and understand how much work Graphcool is going to do for you, it's super nice.

I think it's the same sort of feeling I got when I first started doing Firebase. Like, I built a lot of mobile apps and it was nice to not have to worry about using core data or really trying to invest into whatever my back end as a solution was.

I can just use something that already has a structure there. I can get my app up and running. My UI looks great. And if I want to, then at that point see if I want to commit to Graphcool, I can. But for front end UI developers, it takes out the need for the knowledge to also build your back end, when all you want to do is just make a beautiful app.

Johannes: Exactly, and at the same time, maintaining the flexibility that you can grow beyond a prototype on MVP.

Brian: Yeah. And then, I don't know if you picked up on this, Eli, too when you were researching, but

When you set up your queries, if you were to add a new table to your query, there's no updating you have to do other than adding a new item to your query in GraphQL.

Johannes: Exactly.

Brian: Your Instagram example, let's say now you want to add videos, you can just add another video table and it works.

Johannes: Exactly. If you would do a change that would kind of change the schema in a breaking way, we're going to warn you about it. And we're going to help you with running migrations so that you're always aware of the step you're going to perform and what kind of impacts that might have.

Brian: We talked before off air about Jamstack and how everything fits in the Jamstack and how we're trying to move people away from the term static and that more hyperdynamic. And now we're trying to push Jamstack because, like, you guys fit right there in the A of the API section of Jam.

All you have to do is worry about your JavaScript, your markup, and Graphcool brings in the API for you. So your database is already set up for you. For the most part, you could add and remove stuff, as well. I do like your UI, as well. I found your UI was actually super easy to grasp, more than Firebase. I really miss the old Firebase before they were bought by Google.

I feel like their documentation was a little more verbose, that it had better examples. I think unfortunately, I hate to knock it because I'm a big fan of Firebase. I hate to knock Firebase now. But I feel like the documentation's been watered down even further to fit a more broader use case. But when you first open up Firebase, you get this empty object and that's about it. You're not sure what you're looking at, especially if you're coming new.

Like I said, I mentor a bootcamp student. We have all different levels of skills of people just learning how to code to start up with. There's no real hand holding there to actually understand, like, "Okay, this is, actually it's JSON. It's just a JavaScript object. Here, just go to this slash endpoint." But I like your UI where it just kind of hand holds you into asking your first query and your first object, the database.

Johannes: Quickly to pick up on the A of the Jamstack,

We do not just allow you to specify your database schema, but you can also integrate with all sort of services. For example, if you want to use Algolia and you want to use the real time search aspect of Algolia, you would just enable an integration.

So you would enter your Algolia credentials, you would create an index, and the index might be linked to a model. Let's say for all the messages of your chat app, you want to have them searchable through Algolia. So you would just, on our platform, create an index which says all the messages, or you can filter them, will automatically be synced up to Algolia and you can use that out of the box. So it makes all the other A's in the Jamstack even easier.

Brian: Nice. I saw that announcement about Algolia. Was it last week or the week before?

Johannes: Yeah, last week.

Brian: Very cool. That's a super awesome integration. You guys have any other integrations coming out?

Johannes: Yeah. We also integrate with o-zero Digits, we're working on numbers, other authentication integrations. We are also currently looking into a more sophisticated Stripe integration. But Stripe is a bit of a tricky one, since the last thing we would want is just to channel through all the Stripe API calls, since that would basically erase the security concepts of Stripe. Stripe has a lot of security certifications, and all of them will be invalidated if you would just proxy through the server side to API. So we have to be a bit smart about this.

Brian: Okay.

Eli: When Graphcool handles a lot of back end, how does that speed up your workflow? I'm sure it has some impact because you have this whole other component that you don't have to worry about. Does it speed it up immensely? Can you go a little bit more into detail about how it speeds it up?

Johannes: Definitely. Our core mission is basically maximizing this delta of developer experience. The service we are building, you could also build it yourself. But what you actually want to get to is,

When you build a back end, you're not necessarily interested in wiring up the data from your database that matches the schema you're exposing from GraphQL. But what you're interested in is that your back end actually exposes the schema you want it to, and also performs the business logic.

And we directly get you to this goal, that you can just focus on implementing the business logic and just focus on specifying the constraints around your dataset. This is basically how we save you a lot of time.

Eli: That's on the development side. It also speeds up things on the front end side, as well. Do you mind elaborating a bit on that?

Johannes: Definitely. This is how we can profit a lot from GraphQL itself. GraphQL has so many nice benefits in terms of what kind of opportunity it unlocks in terms of tooling. You get type safety for your queries, on the client side, you can save a lot of additional round trips. I could just elaborate on the upsides of GraphQL on its own. But what we are adding on top of this is, for example, that we are providing individual endpoints which match different technologies.

For example, we are providing a dedicated relay endpoint which should be used with Facebook's Relay framework, which kind of introduces a lot of additional fields around how this schema should be set up. So we provide that out of the box. But if you want to use Apollo, for example, you can use a way simpler schema. So we provide an additional endpoint which just exposes the bare necessities that you can use that when building applications with Apollo, which saves you a lot of leg work.

Brian: We actually had the Apollo guys on a couple episodes ago. They talked about more in detail, like, their use case and actually consuming GraphQL on the front end. Like, I guess if listeners didn't listen to that and also for the benefit of Eli who wasn't on that episode, Apollo and Relay basically consume your GraphQL endpoint and rather than deal with parsing JSON or whatever you get back from GraphQL, it actually parses it for you. Then you can talk to your Apollo client and then use that as your interaction for your data.

Johannes: Exactly.

Brian: Similar to Redux, the React Apollo client is a lot similar to the React Redux client. So you have that store that you can just access all your data from, which is super nice, it's nice to not have to, again, it feels like we're moving with React as if it was a library that rethought the way you built your UI. And then along came Flux and Redux that rethought the way you build your back end, or your back end for your front end. I think some of these tools make it a little easier to manage all that blob of data.

Johannes: Exactly. And they match really well together. A couple of other things we do, and what makes it even easier to build apps from the front end, is, we are trying to optimize for a couple of scenarios. Imagine you want to create a post, and for this post, you want to create a location at the same time. In a traditional REST world, for example, you might want to create a location.

The first thing is to kind of save the ID of this location and then create the post. What we allow you to do is use so-called nested mutation. You can create a post and a sub-object of the post you want to create is the location itself. So you can create not just one node at a time, but a whole sub-graph of nodes you want to create. Another nice example of how we are solving complexity and giving front end developers the upsides of it, is, for example, our filter syntax.

You don't need to implement crazy filter algorithms on the back end to give you a lot of flexibility in the front end. We are solving that for you. You can filter the data exactly how you want it and how you need it, and the client, and based on a GraphQL type system.

For example, you want to get all messages from Brian. So you just say, "Give me all messages where the author, the name matches Brian". Basically you have a full-blown Boolean algebra to express what kind of rules you want to convey in this, and therefore you have a really powerful way to filter and search data.

Brian: Very cool. I don't know if this is a underhand pitch of a question. But what's your outlook on GraphQL as a whole for 2017? I guess speaking to the skeptic who says "I already use REST APIs. This already works for me. Why would I want to use GraphQL?"

Johannes: Right.

We've looked into GraphQL a lot over the last year, as you might imagine. We haven't found a single use case where you might want to pick REST over GraphQL.

You see it with companies like GitHub settling on GraphQL and a lot of other companies are now officially using GraphQL. What particularly excites me is that GraphQL is maturing a lot. So GraphQL has now this official RFC process.

We actually have quite a couple of features we'd love to see in GraphQL. And the best way for us to contribute is to open the RFC, discuss it with the community, and see how that evolves. There are also really exciting features coming up, for example, GraphQL subscriptions. Over the next couple of months, we will really see a lot more movement around the real time aspect of GraphQL.

Lee Byron last year kind of mentioned a lot of neat features of GraphQL, for example live queries or the patch syntax. So there are just like a lot of idea floating around which are not yet landed in GraphQL. Hopefully we'll see a lot of these in 2017.

Brian: Yeah, and I think it helps, too, because we didn't mention it while recording. Lee Byron is actually an advisor of yours, for Graphcool?

Johannes: We are very fortunate to work with him and kind of bounce a couple of ideas with him. For example, the filter syntax we've released, we got some great advice from him. Also our permission system. We're pretty happy about the feedback we got from him. So he said that, to some extent, we've reimplemented the way Facebook works with that. So yeah, that's pretty cool.

Brian: I guess I should preface, Lee Byron's the creator of GraphQL.

Johannes: One of the creators, of the three, I think.

Brian: He's the most outspoken, I guess. He seems to be the one that leads the conversation at conferences.Which is a nice person to have. I think you're actually, out of only 14, 15 episodes of this podcast, you're our third GraphQL episode, mainly because it's something I'm super interested in, and hopefully that gets us closer to Lee Byron to coming on.

Johannes: I might be happy to make a connection there.

Brian: Yeah, cool, I would love to have him on. I think that kind of wraps up most of our questions on Graphcool and GraphQL. I think we'll leave it at that. I think it's a really good introduction. As I mentioned, you guys have really good tutorials out there to learn Apollo, learn Relay. Just the Graphcool docs are growing, as well. So the Graphcool docs, the GraphQL docs are also growing. Hopefully I'm enunciating GraphQL and Graphcool clearly. People will kind of get that. But if you're not, just Google both of them.

Johannes: Well, that might be intended to some degree, too.

Brian: I guess I'm trying to wrap this up. But where did the actual name come from? Did you guys, did you have to shop a bunch of names?

Johannes: I just checked whether .cool is a thing, and then it was, and that was settled, then, for me.

Brian: Wow, that's easy. Wow, it's like picking a band name. Sometimes it takes forever and sometimes it's super easy. Awesome, cool. I'm going to segue right into Picks. We do JamPicks, which is basically anything you're jamming on, stuff that gets you going, music, TV, food. Have you been to San Francisco before?

Johannes: Just once before.

Brian: Okay, cool. If you have any San Francisco picks that you want to check out, or maybe I can throw a San Francisco pick in there for you. Actually, I will give one. With that being said, I'll go first. Since I'm the host, I'll go first and give you guys an option to parlay to the other person. But my picks, one is actually going to be a TV show I just binge watched in two days. It's a short season. It's called "Humans", it's an AMC show that I've never heard of. I have Amazon Prime. I don't know if you guys have it over in the UK?

Johannes: Yeah.

Brian: They have the shipping, two day shipping, but they also have the video service, which not a lot of people use. So I forget that I have it, because I use the shipping so much. But I was just looking for something to watch, found this show called Humans, which turned out it's a AMC show that I'd never heard of, watched the eight episodes. And basically four episodes a night. So I've gone through the entire first season. I think the second season just started, like, this week.

It's actually really good. If you're a fan of Westworld, it's in that vein. Not to give away too much, but it's also in the vein of Battlestar Galactica, et cetera. It's pretty cool. Just watch it if you're into those two other shows. My other pick would be, for a San Francisco pick, what I usually try to do, almost every couple of months, I try to go to Marin, up to the Marin headlands.

You basically, it's north of here, you go over the Golden Gate Bridge, and it's got really awesome hiking trails. You can also see the bridge. When it's foggy, it's pretty awesome because it's really cold. It's even colder than San Francisco normally up in Marin when there's fog. So I highly recommend checking that out. Land's End is another, very similar, it's just on the San Francisco side. I prefer Marin because it's less tourists over on that side. But Land's End is another one. If you're into hiking, definitely check that out if you're in the city.

I also want to pick Oakland. A lot of people come to San Francisco, they go to the Bay Area and then to South Bay, down to Silicon Valley. But Oakland seems to be neglected. I live there, and my neighborhood's actually, it got put on the list of the best neighborhoods to look for in 2017, which is scary and a good thing at the same time. Because I pay cheap rent. But it's not going to be the case if I ever move. But Oakland's a pretty awesome neighborhood, and I highly recommend checking it out. That's it for me on Picks. Eli, did you have any picks you wanted to share? Things you're jamming on?

Eli: Absolutely. I'll start with the silver screen. Me and my wife, we just checked out "Passengers" the other day. I know it's a little late. It debuted a while ago. But I was truly amazed by the cinematic beauty in that movie. It's not just kind of 3D eye candy, but rather a truly intense and creative plot that keeps you on the edge of your seat. We truly enjoyed it. It's kind of a longer movie, but we didn't mind it.

It felt like it flew by because it was so intriguing and engaging. The other pick I have is in the music realm. At the time of recording this, Valentine's Day was yesterday. Of course, you kind of break out the lover's playlists and all that good stuff. But one of the songs that kind of caught my ear again was "The Generationals", called "When They Fight, They Fight". It's just a beautiful melody that always lifts spirits, despite its content being a bit confrontational at times. But it's a great mix and I definitely recommend checking it out.

Brian: Very cool. And Johannes.

Johannes: Sweet. I was kind of expecting more technical picks. So that's what I've been brainstorming about. I've been recently checking out a technology similar to serverless, but on another dimension, called Standard Lib. That's actually a really cool technology. It's really a function as a service so you can compose Lambda functions. They give you like an NPM, but for your functions. That kind of level of abstraction really makes a lot of sense for us, and we want to also integrate it into Graphcool.

Brian: Be able to share functions, like that NPM side?

Johannes: Yeah, exactly. You kind of have a marketplace for your functions. That really strikes the right level of abstraction for me. Another tool we've built on our own which I'd love to share, we haven't really spoken about it before, it's called Prep, which is all about server-side rendering. But it's not really server-side rendering, but rather build time pre-rendering.

I think the whole server-side rendering, especially around Jamstack and so on, is still fairly unexplored. Of course, you can kind of proxy your entire static site, but that also defies a lot of the nice benefits of it. So the tool we've built, it's basically using Electron. It locally holds the static build folder of your single page application.

It opens that up in Electron or in a headless way and just waits until the website is loaded, and then just takes the generated HTML and writes it back into a new index HTML and you can iterate over your routes, you can even get dynamic routes, and therefore for static marketing pages, you can pre-render at build time your entire React app of U apps.

Brian: Wow, that sounds pretty awesome. Yeah, I think the idea of how to approach server-side rendering, I think the term server-side rendering is all wrong. I think the approach is wrong, too. At Netlify when we do prerendering, we use pre-render iO under the hood. But this sounds actually super intriguing. I think I might have to check it out. I think you put a link in the show notes, too, as well.

Johannes: Yeah, exactly.

Brian: Very cool. Well, Johannes, thanks for coming into the studio here.

Johannes: Thanks for having me.

Brian: All the way from the UK, is that where?

Johannes: This is where we started out. At the moment, we are based in Berlin. But we are also looking to move to the Bay Area here in a couple of months.

Brian: Okay, cool. Awesome. I will have to show you all the good eats the next time you're out here.

Johannes: Yes, seeing Oakland, I guess.

Brian: Yeah, Oakland, it's the place to be. Uber's going to Oakland. So it's going to blow up. Johannes, thanks for coming on. Eli, thanks for coming on to sit in second chair, as well.