The Changelog: Software Development, Open Source - Why is GraphQL so cool? (Interview)

Episode Date: June 30, 2017

Johannes Schickling (Founder of Graphcool) joined the show to talk about GraphQL — an application layer query language from Facebook. We talked about what it is, where it makes sense to use it, its role in serverless architectures, getting docs for free via Schemas and Types, and the community that's rallying around this new way to think about APIs.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Linode, our cloud server of choice. Everything we do here at Changelog is hosted on Linode servers. Pick a plan, pick a distro, and pick a location. And in seconds, deploy your virtual server.

Jewel-worthy hardware, SSD cloud storage, 40 gigabit network, Intel E5 processors, simple, easy control panel, nine data centers, three regions, anywhere in the world they've got you covered. Head to leno.com slash changelog and get $20 in hosting credit. From Changelog Media, you're listening to The Changelog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, Editor-in-Chief of Changelog. On this episode, we talked with Johanna Schickling about GraphQL, an application-led query language from Facebook.

We talked about what it is, where it makes sense to use it, its role in serverless architectures, getting docs for free via schemas and types, and the community that's rallying around this new way to think about APIs. All right, we're back talking about something very cool, Jared. Something that we have not quite talked about on the show. Although when we talked to the people from Facebook, we kind of coordinated this call, but it's been like forever and we're not even talking to them.

Yeah, it's been a couple of years since Facebook announced GraphQL back in 2014, I believe, in fact. Nope, September 2015. If I just would have looked at the notes, I would have got that the first time. But since then, people have gotten quite excited about it. And we are joined today by a fellow who is so excited about it, he even has a company, GraphCool. Great name, by the way, Johannes. All about GraphQL and serverless and providing really hosting and options for people who are using

this technology. So first of all, Johannes, thanks so much for joining us. Yeah, thanks for having me. So everybody's getting excited about GraphQL. Seems like for different reasons. Others are still skeptically standing on the sidelines. But you, as we just said, are kind of all in on it. So first of all, tell the audience what GraphQL is in your words,

and then tell us why you're so excited. Sure. So GraphQL, in abstract words, is a query language for your API. What that really means is if you're a front-end developer, you're probably used to using RESTful APIs, which is kind of like the best practice of the last 10 years. And you can kind of think about GraphQL

as a better replacement for that in most cases. So as you're querying a REST API, you're usually getting back JSON of a certain shape. And you can think about GraphQL as basically you're sending a query to the server with just the shape of the JSON, but without the values. So kind of like a JSON blob, just the keys without the values, and the server fills in the values for you. And if you take this concept, you can directly tell the server

the shape of the data you're expecting, and you can do queries to get data, and you ask for what you want, and you get predictable results. And you can even traverse your entire data of your backend in a certain way, and you get a lot of flexibility

you wouldn't be able to get with a common REST API. So that is maybe a quick way to describe GraphQL from a front-end perspective. So the big wins are reduced number of calls to the API because you don't have to make subsequent requests for related objects or records, as well as the flexibility to grab exactly what you need and nothing more.

So reduced payload size. Exactly. Flexibility. And so therefore, speed, right? Exactly. So these two problems you called out are actually called data overfetching. So imagine you're starting out building an app

and you have a REST API for that and the iOS app has quite a lot of different requirements and you keep adding stuff to this endpoint. You also start building an Android app which doesn't have all of these data requirements and it anyway gets all of the data constantly over the wire and fetches maybe 60%, 70% more data than it actually needs. So the other idea is to keep the REST endpoints really slim.

And so let's say you build like an Instagram and you have your feed with all of the images, but for every image you also want to get the author object, like the person. And let's say you want to do that for 100 images. What you would end up doing is sending 101 requests, one for the list of images and 100 for each person. And this is like the classical N plus one query problem. And both of these problems are solved with GraphQL.

So going to the n plus one query problem with REST interfaces, with the JSON API spec and stuff like this, there are solutions for this, such as sideloading associated records without having to create multiple queries. So I think that isn't that sufficient for many people? Yes, but GraphQL gives you a lot of nice other things on top. And it does that by, at the same time, being really, really simple. So the way GraphQL actually works is that GraphQL gives you a type system as your discoverable endpoint. So for JSON API, you would still have all of these endpoints. With GraphQL on the other side,

you have this one endpoint where you can write your queries to, and you just have a really simple and concise syntax. So I think if you're already heavily invested into JSON API, then that's probably fine for most of your use cases. But GraphQL just has a way lower entry barrier and provides a lot of great tooling, which all revolves around this type system of the GraphQL language. And this allows for tools such as GraphQL or GraphQL Playground, which gives you, it's basically like a little IDE for writing GraphQL queries, which gives you auto-completion and

error detection if there's an error in your query. And all of this tooling just revolves around the simple standard of GraphQL. So we mentioned back that Facebook announced that they had actually been running GraphQL internally for a couple of years before creating the open source, or creating the specification, as well as open sourcing and reference implementation

in JavaScript. That was September 2015. About a year later, GitHub announced that they're switching to GraphQL for their public API, September 2016. I got a quick paragraph from the GitHub announcement on the GitHub engineering blog that I think will give a real example of what you're talking about, Johannes, with regards to the query problem, the too many API calls.

So they said that the REST API is responsible for over 60% of GitHub requests made to their database tier. This is partly because by its nature, hypermedia navigation requires a client to repeatedly communicate with a server so that it can get all the information it needs. Our responses were bloated

and filled with all sorts of star underscore URL hints in the JSON responses to help people continue to navigate through the API to get what they needed. Despite all the information we provided, we heard from integrators that our REST API also wasn't very flexible. It sometimes required two or three separate calls to assemble a complete view of a resource. It seemed like our responses simultaneously sent too much data

and didn't include data that consumers needed. Now earlier on I said if you can sideload relationships, you can get around some of the problems of the too many API calls but that requires you to have a very intimate understanding of the client that's accessing the API and when you're building a general purpose API for many different clients, like you said,

with regards to an Android client, iOS client, so on, you just don't have that level of flexibility. You have to be generic. And so in those cases, REST just wasn't a great fit. Anything to add there? Is that a decent real-world example of what you're talking about? Absolutely, absolutely.

And I'm not sure whether that was the statement from this Monday or from a year ago, but I think this Monday, actually, the GraphQL GitHub API was officially released, and it's no longer in alpha or developer access. Yeah, this post I'm reading here was last year. This was their announcement, and I think beta, that they were basically going to make this switch,

but they hadn't completed it yet. Right, yeah. So I've spoken to Brooks, who works at GitHub, and we actually had him over last weekend at GraphQL Europe, a conference we were hosting about GraphQL. And he was giving a talk about how GitHub was moving to GraphQL and gave a motivation around all of this. And it was really insightful and such a great fit for, like you said, it provides so much flexibility, this API. And I think it's a great introduction for people who want to dive a bit into GraphQL

and see why is this actually useful. And there they have a brilliant example. So with GraphQL, you have a schema that's exposed from the API side. Can you tell us about the schema and what it all includes? Right. So the schema, basically you have a server

that exposes the schema. So the schema therefore represents a type system. You have multiple ways to provide that. So usually you do that through a server. So the server, you could implement it on your own with multiple ways to build a GraphQL server in any language. You can use an Express app in Node. You can build it in Python. You can build it in Scala. There are also a couple of services out there which help you to set a GraphQL backend. And we are, for example, providing one

where the process around turning your GraphQL schema into an actual GraphQL API is literally you're specifying your GraphQL schema in something that's called the GraphQL SCL, the schema definition language. So if you're heading over to GraphQL.org, you actually see in the header where it says, describe your data, you're seeing a very concise syntax of a part of your schema.

So you basically, if you're familiar with typed languages like Swift or TypeScript or something like that, and you're writing out your type definitions, that's basically what you can do for GraphQL as well. And these type definitions are the foundation for your GraphQL schema. What's really cool about that is because you're defining the schema with the type definitions and everything that's supported. You get basically free and up-to-date docs all the time, right? Because that's basically what you're writing. Exactly.

And there is so much great tooling around that. And the type definition is really the foundation for that. So that's probably one of the biggest aha moments for people getting into GraphQL is trying out this GraphQL Playground or this GraphQL Graphical Editor where you see all of this auto-completion and you can toggle automatic documentation for your API

and you don't need to maintain a Swagger documentation, all of that. So that's really like a completely new level of what you would get out of Swagger, for example. What are the drawbacks? Because right now it sounds like unicorns and rainbows all over the place. There has to be. With all technologies, there are trade-offs.

What are some of the drawbacks? I mean, this is a fairly big unicorn. So I've actually, I think I can list the drawbacks. Like I don't even need one hand for that. So there are a couple of weird cases, but these are really exotic and don't really occur in the real world. So the biggest pushback we got from people is when they say, Hey,

my API is really, really simple. So it's just an endpoint that exposes maybe two fields. And I'm always expecting the same thing from this API. And it's not really complex. And this is where we hear people saying it might be overkill to use GraphQL. And in these cases, if they already have their REST API, that's probably fine. But as soon as your application really starts to grow

and you have multiple from a REST world resources, this becomes more complicated. GraphQL is really, it has almost zero overhead for you to implement on the backend side. And there aren't really any obvious downsides. I mean, of course, you have to, like, it's usually when you want to start something from scratch, you're usually going with what you already know.

And GraphQL is not yet as well established as the REST standard, for example. But I think it's literally just a matter of time until people realize it's actually simpler to build GraphQL APIs compared to REST APIs and definitely maintaining them and so on. I can speak a little bit to the learning curve because as we were telling Johannes before the call,

neither Adam nor I have used GraphQL in any sort of significant way. But I did go through learngraphql.com, which we'll link up in the show notes, which is a very nice tutorial. And probably 30, 45 minutes with that and I already felt like, okay, I get it. I'm good here. I could probably take this this and run with it and I wasn't trying to achieve anything real so that's the real test but at least the concepts and the formatting if you're used to JSON and

JavaScript and you know things like that it is pretty easy to conceptually wrap around your head from the client side yeah and that's the beauty of GraphQL it's so simple to understand it fairly quickly wrap around your head from the client side. Yeah, and that's the beauty of GraphQL. It's so simple to understand it fairly quickly. But at the same time,

like now that we've been using GraphQL for more than two years, there are constantly new points where we have like brilliant aha moments where the simplicity of GraphQL enables completely new concepts. So it's really well thought out and was very much worth it to stay internally at Facebook for five years

until it's really evolved to what it is today. And really the simplicity is what makes it so easy to understand. And it's so well designed and enables so many different scenarios. One drawback that I've heard, and I can't validate this, so I'm going to ask it to you,

is that because every API call is a unique snowflake, that it's darn near impossible to have an efficient caching strategy on the server side. Is that something that you've run into or is that a non-issue? That's a very good point.

So GraphQL is definitely a new paradigm how you expose the API. And I mean, that's the entire idea of REST APIs that you have like on a resource level that you can do HTTP caching and so on. So that is, you cannot directly transfer that concept to GraphQL, so you need new ways to cache. And I agree that is not as well understood

as REST APIs, for example, currently are. But this allows for new kind of concepts so you can cache more on a data graph level. So there's just a lot more still to be explored. And that's definitely one of the parts of how you build GraphQL servers, where there's a lot of movement currently. I mean, it's not directly something that is just not possible. It's just something where you have to wrap your mind around.

It's different. where you have to wrap your mind around. It's different. I would think with less queries, less activity to the server, you might actually be able to save and maybe caching is less required because your server is actually getting pinged a lot less. Exactly. Basically, how you assemble

the response of a GraphQL query is entirely up to you, and you can cache it in whatever way you want. So usually the GraphQL queries you're getting are fairly similar. So you can do quite a lot of efficient caching. And if your data structure and if the nature of your data allows for it, then you can even cache the normal HTTP requests which are coming in. So that's maybe also worth mentioning that GraphQL is from the standard on its own

independent from the transport protocol being used. So most commonly it is used via an HTTP transport, but for example there are also now newly the GraphQL subscriptions, which are usually used via a WebSocket connection, but we are aware of people who use GraphQL with binary transports and using a UDP stream, for example. So you can, whatever transport protocol you're using, you can also do a lot of clever

tricks there. Yeah, that's definitely worth mentioning that where that sits in the networking stack is at the application layer. So thinking about it in terms of REST, you know, REST semantics use HTTP, even verbs, right? Get, post, put, or patch, if you will, and delete. When you're using GraphQL with an HTTP underneath it, are you just using gets, getting post? How does it actually, does it matter

how you communicate at that layer? So it's mostly up to you, but there is a definite best practice, and that is usually that you send everything via post request. And in this post request, you're usually sending a JSON-encoded payload, and this JSON-encoded payload at minimum has a field called query, where you're literally sending your GraphQL query. Additionally, there's also the concept of variables,

where you can parameterize your query with variables you can pass over. And yeah, that's basically what you're sending over, and you just get JSON back. So that is kind of like the best practice being used in 99% of cases. Coming up after the break, we're going to talk about mutating data, how you go about changing data with GraphQL mutations, authentication and permissions,

and the role of GraphQL and how it's aiming to be your favorite serverless GraphQL backend. Stick around. This episode is brought to you by Hired. Hired matches outstanding people with the world's most innovative companies. At Hired, your dream job is waiting to apply to you instead of endlessly applying to companies hoping for the best hired puts you in control of when and how you connect with interesting opportunities the best

part is hired is completely free to you it won't cost you anything. In fact, they pay you to get hired. Head to hire.com slash changelog. Don't Google it. This URL is the only way to double the hiring bonus to $600. Once again, go to hire.com slash changelog and back to the show. Johannes, we talked about fetching data, the advantages there, the simplicity. We haven't talked about mutating data. So why don't you give us the quick rundown and we'll go from there. Exactly.

So yeah, these are basically the two big concepts of GraphQL. One is querying data, what we talked about in the first section. So the other big part is how you actually write data, how you update data. And that's called GraphQL mutations. So that's from a REST perspective, that's kind of the equivalent of put, post, delete, patch. And yeah, these sort of verbs. So the idea of a GraphQL mutation is basically a GraphQL schema exposes mutations. You can kind of think about them as remote function calls.

So they expect some arguments. So for example, if you're building this Instagram app and we want to create a new image, we would need to provide like a description for the image and maybe the image URL. So, and all of these arguments are typed. So you need to provide them and you can also, for every mutation, it also exposes a view into your graph. So you can, while running the mutation, you can also already query back data. So for example, as you're creating this new image, you might want to get its ID back and some other information.

So a mutation is really a mutation plus a query. And yeah, this is basically the concept of a mutation. It's as simple as queries are, and this is how you can implement any sort of writing operations. So whatever mutates your backend, you would do through a mutation. And once again, because it's part of that schema, it's all explorable, it's all documented, it's all very clear. Exactly, yeah.

What about if you want to mutate a host of things all at once? It's basically up to you how you design your mutations. So whatever fits your use case, you can design mutations that do that. So for example, if you have a more complicated piece of business logic in your backend, so for example, if you're building a webshop and you have a checkout process,

that usually does more than just one thing. So you would create a mutation that does exactly that and your implementation would take care of all of the implementation steps. So it would maybe create an auto object, it would maybe transform a list of items into a representation that fits your webshop, like other items and so on. So it could basically do whatever you want

your imitation to do, and you expose it in a very minimal way to the front end. So what about permissions and authorizations and stuff? If you're having this kind of an ad hoc, put your query together API, but you want to provide different access for different clients, is that something that's built into GraphQL or is that something you'd have to go out on your own and figure out how to get that done? Right. Really good question.

So I think we should talk about both things. The first is authentication. And going back to your last question, neither of these concepts are directly built into GraphQL, but it's so flexible that you can basically use

whatever concept you want to use, you can use with GraphQL. So every authentication mechanism you would have for your REST API, you can use with GraphQL. So every authentication mechanism you would have for your REST API, you can more or less directly translate to your GraphQL API. So best practice for authentication in GraphQL APIs is that you have some sort of mutation that authenticates you

as anonymous user as a authenticated user. So maybe you're sending back some kind of session token and the session token you might send back for every subsequent request through an authorization header. So this is a really simple way to implement authentication for GraphQL APIs, but you can also use HTTP basic auth or however you want to go about that. So that's completely up to you.

And authorization is basically the same story. It's up to the backend how you would implement that. But additionally to rest api where you would usually just do authorization based on a on a resource and endpoint level uh with graph kl you can go a step further and you can um do field-based authorization rules so um for example if you want to query a user, maybe you're allowed to see the user's name, but not the email address and certainly not the hash password. So, and there you can basically, on a field level, implement authorization rules, what you can see and what you cannot see. And yeah, so this is usually where it gets, as for every backend, it really gets fairly tricky how you implement permission rules. And this is something where we at GraphQL, we're pretty excited about the way we found to expose a level of abstraction for authorization rules with our permission system. So this is one of the voids where GraphQL or similar services are, you're

offering some solutions to these things, which it's, you know, there's six dozen ways to skin the cat, right? Because like you said, it's not in the specification. So it's up to the individual API or the individual implementation to figure out how to do it. And so you guys are providing some of that stuff out of the box for GraphQL users. Is that right? Exactly. And that's actually one of the biggest steps how we see ourselves as a next step

in the evolution of backend services. So if you think about Parse or Firebase, you have these concepts of ACL and roles so that you can say, like like this user has the admin role and therefore this user is allowed to do X. But in most real world applications, that's way too minimal and that doesn't allow you to implement your real application.

So what we basically allow you to do is you can specify any kind of authorization rules based on the graph structure of your data. So in our Instagram example, imagine you have an author of a post of an image, and just this author is allowed to change the description or the image URL of this post. Or every person has a lot of followers and maybe this following needs to be accepted. And then just accepted followers are allowed to view images. And all of these permission rules are based on the information which is embedded in the graph structure of their data schema.

And we basically give people, give developers a way to implement these permission rules in the form of GraphQL queries, which represents permission rules by just specifying these conditions with the simplicity of GraphQL queries. So that sounds fairly abstract, and you would certainly need to see a few examples. But this is a really simple concept which allows you to specify any sort of permission rules. So you mentioned Firebase and Parse, and GraphQL is kind of a new spin on that same type of a service. And those are both services that got acquired and are in various states of distribution.

Parse, of course, famously shut down. It seemed like a very good job of going about the shutdown in terms of people having time and getting their data out and all that kind of thing. Firebase, I'm not sure of the status of Firebase. I think it still exists as is, right? It does exist, and it's actually Google is putting a lot of money into it. Okay, so getting better perhaps, but

Google could change their mind and shut Firebase off. So for those who are thinking, oh, GraphQL sounds cool, but what if it disappears tomorrow? That's always my concern. What do you say to that type of question? Right. So that's actually one of the most common questions we're getting from people evaluating our service, and it makes a lot of sense.

And I'd ask the same question if I would see a service like that. So I think one thing that Parse has done particularly well is that everything went open source and you can now run your own Parse server. So people who were running on Parse before can still get somewhat the same level. But of course, that's not perfect. So what GraphQL really allows you to do, and not just GraphQL, but the entire concept of serverless,

is that the entire service we're building is based on open source technologies. So Firebase, Parse, all of these services were built on proprietary software. Whereas our service is just built on open source technology like a GraphQL API and we allow you to export we like not just for shutting down but like when you're signing up and you decide I don't want to use this anymore I want to build my own thing you can export the entire schema you can export all the data and you can roll it on your own. So this openness of these technologies allow you to migrate away. And this is really something really important for us. We don't want to promote the concept of window login.

We rather want to think about the concept of maximizing developer experience. So, I mean, it's a similar concept to what the guys at Expo are for example doing so they just make it really easy to to use these technologies with React Native and so on it's all open source you could build it on your own but with using something like that it just maximizes the what you can get out of it it gives you a better level of abstraction. And that is really what our mission is about. So you like how Parse went open source after acquisition.

Are you saying GraphQL would do the same thing if you guys found yourselves in a similar situation? Right. So I think it took Parse a bit to really get there. So it didn't, for example, it didn't open source most things on day one. So it was a lot of pushback, back and forth around which parts are being open sourced

until really most parts got open source. So that is one part of it. So we've taken the same concept and this is something what really resonates with people. So we have this policy, what we call the sunset policy, which basically says

whenever something would happen to our servers, everything would just be open source. People can host it on their own. I mean, everything internally is built on open technologies with Docker and so on. So people could host it on their own. I mean, everything internally is built on open technologies with Docker and so on. So people could host it on their own. And yeah,

needless to say, we're not planning to shut down anytime soon. And also, we said no to every acquisition offer we got so far. What parts of the service is proprietary? I mean, if you're built on only open source, there's got to be some sort of glue there, and that's the proprietary part that's not open source. Can you talk about that a bit?

Right. I mean, that directly translates to the value we are providing, and it's actually directly rooted in the cause of why we started to build GraphQL. So as you're building your own backends, especially REST backends, you find yourself a lot in the situation where you just basically you want your API and the API usually either gives you data out of a database or it receives data and stores it in the database in some way.

So you're just building this mapping between your API and the database. And this is where you put a lot of time in, it needs to evolve, it needs to, like, it's very error prone, it's not particularly exciting, but there are a lot of mistakes being made in this process. And this is something we wanted to just solve this problem. And GraphQL is the perfect foundation for that. So based on your GraphQL schema, you're specifying locally or on our platform with a GraphQL schema. We generate a GraphQL API for you with a managed database in the back. So where the proprietary part is, and proprietary, it's like there is nothing really secret about it.

It's just a lot of complexity we are abstracting away. And this is the mapping between the automatically generated GraphQL API and a scalable database. So maybe this will be more controversial and I don't understand your business nearly as well as you do, but why not just silence all questions and just go completely 100% open source, somewhere like Discourse,

where everything that they do, can do yourself but you know you can also use them as the host and they'll do all of the hard things for you is that a consideration or is that too scary or it's definitely a consideration and we're looking into ways how we we could go down a path like that so uh one one part of that is just that the system is far from trivial. So, I mean, we started out building the first few prototypes in Node and it just grew quite quickly and we knew we had to build it

in a way that is scalable, that will be maintainable going forward. So, for example, half of our test base was basically just something that could have been caught by a good type system. So really quickly, we decided to rebuild everything in Scala. And now it's this really huge code base with multiple microservices,

a lot of infrastructure involved. And that takes us quite a lot of time to ramp up new engineers to understand that internally. And open sourcing, all of that would just slow us down quite significantly since we would need to have documentation around that. And people would rather be concerned about, hey, how can I get this to run on my own? And it would just slow us down since every decision we would make internally, how we are changing infrastructure and so on, would suddenly be a breaking change. So we'd rather want to move really quickly on that internally because we are managing our internal breaking change

people will never know about. And once we have found a good way to orchestrate everything internally, we want to take one step at a time to open source version of that. Let's paint the timeline here. I mean, you as you mentioned in the

first part, Jared, GraphQL was announced July 2015. September. Well, I'm looking at September okay so I was looking at the GraphQL about page and kind of using their timeline oh I'm trying to paint back the picture of like GraphQL being announced it seems like their first prototype I'm assuming GraphQL's first prototype was in January 2016 and it seemed like you spent most of 2016 either creating and or getting the necessary investment to be able to make a company and so now you're at a point where you can actually launch

and be used and grow as a company and it seems like maybe you're in this stage of of like innovation and then once the dust so to speak settles then you can start to say well what can we extract from this to give back to the community? Is that a fair assumption of where you're at? To a certain extent. So it's quite remarkable what is actually needed

to just provide a baseline to people in terms of infrastructure that they can implement any kind of use case they want. So if you're basically giving them a new way to build backends, so we're not trying to be like a new Firebase replacement where we provide crash reports and all of that, but we rather want to provide people a new way to build backends

and a better abstraction for that. And there is just a lot of groundwork needed around authorization, around authentication systems, and also most importantly, around how people can implement their own business logic, how they can extend that, and so on. So we're working quite hard and it's just, it is a lot of work and I wouldn't say we're entirely there yet where we can say,

all right, all of that is perfect. Now let's see how we can open this up and make it available for everybody. Our goal at the moment is seeing what are the biggest problems

our customers are facing and how can we make it easier for them. And once we've reached that point, it's just like next logical step. Yeah, I just thinking about, you know, with GraphQL, the clients basically write their own queries and then with services like GraphQL and AWS Lambda serverless,

you don't have servers. You know, you don't have like, what's next, code lists? Like, I don't have any code anymore. Where's the, like, I'm thinking about this because you said business logic, and it's like, where the crap does my code go nowadays? It's like, I feel like I'm being marginalized as an application developer.

It keeps getting pitched to me as if I'm becoming Superman, but I feel like maybe my role's reduced. I wouldn't say so. For us, it again comes down to this concept of level of abstraction. So when you're building a backend, I think nobody really is obsessed with the part of how can I map the API perfectly to the database and how can I migrate my database in the best possible way.

That's the drudgery, right? That's the work. That's the labor. Exactly, exactly, exactly. And I mean, we are having compilers, we're having better programming languages, we're having frameworks that this manual and repetitive work

gets somewhat reduced to a minimum and that you can go to user experience. How can you make this a great product? How can you make processes great? How can you implement business logic? Like when somebody signs up, sending a sign-up email, sending push notifications, implementing authorization logic and all of that. So we just want to get people directly to that point where they can

implement business logic. And this is where serverless functions come in. So these are basically the small parts in the application where actually code is required. And I'm pretty sure that even there, the level of abstraction gets higher as well. So like 20 years ago, you wouldn't have a service like Mailgun or something like that to send an email. Now it's just a service you can use. So there's still a lot of hard problems that can be made easier with services. But how you tie all of that together, this is really when it comes to building an application. So as you're playing with Lego, you already have the Lego building blocks.

And that's the fun part of putting all of that together. But you don't need to manufacture the building blocks before. And going back to this analogy of Lego building blocks, the great idea of bringing GraphQL and serverless together is that Lego blocks snap together, and the snapping is done through a GraphQL type system. So the GraphQL type system, basically, for every moving part where you pass on data, the data is typed.

So, for example, as data flows through your system and you want to hook in into a certain event and execute some code, in this case, it would be a function. The function would be, if you implement it in a typed language as well, such as TypeScript, for example, or JavaScript with Flow or Java. You have types as well, and you can map them one-to-one to each other. So the GraphQL type system of your application maps to your code, and you get something like global type safety. So that's one of the divisions for us, where we want to go to over the next years.

After the break, we talk about the difference between live queries and subscriptions. We dig deeper into this idea of a serverless GraphQL backend. We talk about where community is taking place, the future of GraphQL, and also where it's going. Stay tuned. This episode of The Change Log is brought to you by GoCD,

an open-source continuous delivery server from our friends at ThoughtWorks. GoCD lets you model complex workflows, promote trusted artifacts, see how your workflow really works, deploy any version anytime, run and rock your tests, compare builds, take advantage of plugins, and so much more. Head to gocd.org slash changelog to learn more and tell them we sent you. This episode of the changelog is brought to you by Microsoft and Azure Open Dev Conference. The event is over, but all the talks are streaming on demand right now. Head to azure.com slash open dev. This conference is focused on showcasing open source technologies in the cloud. Learn how you can build containerized microservices and improve your open source DevOps pipeline. Hear from community leaders like Gabe Monroy from Azure and Deus, Michelle Noraly from Kubernetes and Helm, and Scott Johnston from Docker.

Learn about app platforms, containers, DevOps, and more. All this is provided at no cost. Once again, head to azure.com slash OpenDev. And now back to the show. We've kind of come to a point where it's like, where is GraphQL going? How can you work with it? You know, what conferences are out there? Where's the community meeting?

What kind of resources are out there to get started? And you mentioned earlier in the show, GraphQL Europe. I think you even mentioned in the off-air, there's a podcast that you created. Where are things at for you? Right. So yeah, today is May 24th when we are recording this. And so last week, we actually had the first GraphQL conference in Europe called GraphQL Europe with the creators of GraphQL, like Lee Byron and Dan Schaefer.

We had folks over from Meteor and Apollo. We had people over from GitHub. And really the entire community from all over the world came together and met. And we had great talks about GraphQL. So that was a great place to talk about the future of GraphQL. Besides that, there is a newsletter about GraphQL called GraphQL Weekly. We also, like you mentioned, recently started together with Abhi.

We started out a new podcast called GraphQL Radio, which you can find on graphqlradio.com, where we also have all sorts of people from the GraphQL community talking about different projects. So for example, the last episode has been about Relay and Apollo, which are both GraphQL clients, and how that is kind of moving forward. And yeah, so there are quite a lot of emerging resources for and by the community. So I think GraphQL Weekly is probably a good place

to stay on top of that. You mentioned the conference. What would you say, in your opinion, was the future? Since you mentioned a lot of the future was talked about there. Give us some of the, if we didn't go, what would be the hit list of notes you took? Right, right, right. There are actually a lot of notes being published at the moment. So you don't just have to take my word for it.

But we actually also sat down with the creators of GraphQL and we are now also quite involved in talking about different features for the future of GraphQL and how that is shaping. So the great thing about GraphQL is really that it's an open standard. So it is an open specification. It has an RFC process. You can go to GitHub. You can propose a new RFC with a certain feature. You can hear other community members' ideas and thoughts about this.

And if you make a strong case, that might even be merged into the GraphQL standard. So recent developments, just last week as well, was a really eventful week for GraphQL developments just last week as well was really eventful week for GraphQL. Just last week, GraphQL subscriptions got officially merged into GraphQL. So GraphQL subscriptions, for those of you who don't know, is a way to establish a real-time connection to your GraphQL backend. So usually that's via WebSockets and you can subscribe to certain changes and the server will send you events. And the great thing about this

is you can utilize the same GraphQL query concept. So you can, for these events, you can even also traverse the graph and query for certain pieces of information you're interested in. So a common scenario might be if you want to build a chat application, you might want to listen for new messages being created.

And for every message, you're interested in the text of it and also in the name of the author or something like that. So GraphQL subscriptions got recently merged in. Then this concept of GraphQL SCL I've mentioned previously, that is not yet officially a part of the specification, but will be merged in fairly soon. And yeah, there are a lot of new other exciting features

which are coming up, and a lot of new other exciting features which are coming up and a lot of people talk about them. So for example, a concept called live queries, which is an alternative way to go about real-time queries in GraphQL. So yeah, there are a lot of, really a lot of exciting ideas around GraphQL. You said live queries or live?

Live. Okay. I thought I was like asking, you can ask questions about your life or something. Yeah, that's an interesting thing, though, to have. So is live queries and subscriptions the same thing? Really good question. So they are not, but they both can be used for similar ideas.

So Ravko, and the interesting part about that is that based on Facebook's experience building Facebook and all these real-time aspects of their system, of their platform, so like comments that you see them popping up or that you see like the like counts increasing and so on. So they've really learned a lot about how you build real-time applications at scale.

And these two concepts of GraphQL subscriptions and GraphQL live queries, they are kind of the result of hundreds of iterations. So GraphQL subscriptions, as I said, are based on events that a server sends. And GraphQL live queries are not fully specified yet. They're rather a broader idea where there are a couple of prototypes. So the idea is that you would basically send a normal GraphQL query,

which you would send once for a query query and you immediately get back the result for live queries you would send back you would also send um this this query and you get back a response but you keep open you keep an open connection and if some parts of the query change you get just like an incremental update for the things that have changed. So that is just like an alternative concept to implement real-time applications in GraphQL. Let's finish out on a conversation around what seems to be, to be honest,

the thing that really excites you which is the joining of GraphQL with serverless backend. And, oh, by the way, if you haven't heard it yet, we had a great conversation, didn't we, Adam, at OSCON with Pam Selle about the serverless revolution. So that one's either in your feed somewhere or soon will be. You can also just search changelog.com for serverless

if you want to listen to that. But you guys had this new architecture announcement on your blog introducing the serverless GraphQL backend architecture and it seems to be the result of some of your work of joining these two concepts and it seems to be

exactly what you're the most excited about is this thing. So tell us about this architecture concept and what you're trying to get from the community with regards to it. Right, right. So this architecture is basically, like I said, merging these two new paradigms,

how you build APIs based on GraphQL and also what serverless infrastructure just enables developers to build applications in a lot less friction, like reduces a lot of friction and removes the requirements of hosting your own servers and so on. And bringing these two concepts together, we've proposed a new architecture idea where the GraphQL backend would basically be automatically

generated based on your GraphQL schema. Besides the service we've built, there's also a lot of work in the community, how you can, well, not fully generate a production-ready GraphQL API, but at least it already takes away a lot of the work for you. So you can do things like mocking based on your GraphQL schema or bootstraps a GraphQL server based on your schema. So that's really the first building block that you write out your GraphQL API based on a GraphQL SL. And you would get a production ready graphical API you can use. And the second part is you then just focus on implementing the business logic. And implementing the business logic as a scalable way is possible through the infrastructure provided by serverless

infrastructure. So like serverless functions or S3, these kind of services where you don't have to worry about how many servers do I need to spin up. Maybe just Google for serverless GraphQL backend architecture. And so that's a fairly new concept. And our idea is basically our platform, GraphQL,

provides a developer platform for building these backends, but we also very much believe that this will be a concept how other people build their backends, even if they implement these core parts on their own. No need to Google it if you are listening. Any podcast client, just click to the show notes.

It will be in there. Or if you're on our website, well, you're just staring at the link right there. There you go. You got it right there. Even better. Awesome. Johannes, anything else you want to say before we close up?

Yeah, I basically just want to encourage everybody to just try out GraphQL on your own if you're a developer. See how easy it is to implement your own GraphQL backend. If you're a front-end developer using React, using Vue, using Angular, I highly encourage you to just try out GraphQL. A really easy way to try out GraphQL in your front-end app is using a framework like Apollo, which is a GraphQL client, or Relay, which is a GraphQL client. And yeah, there are two resources also created by us, which is called Learn Apollo and Learn Relay.

These are the easiest way to get started with them. So I suppose that's also in the show notes. Yes, for sure. Well, thanks, Johannes. It was awesome to have you on the show. Thanks for coming on. Definitely. Thanks for having me. It was awesome to have you on the show. Thanks for coming on. Definitely. Thanks for having me. It was really great talking about GraphQL and Serverless.

All right. Thank you for tuning into The Change Log. And also thanks to our sponsors who make the show possible, Linode, Hired, GoCD, and Microsoft with their Azure Open Dev Conference. Also thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. We host everything we do on Linode servers.

Check them out, linode.com slash changelog. You can find more episodes like this at changelog.com or by subscribing wherever you get your podcasts. Thanks for listening.