Sessions is temporarily moving to YouTube, check out all our new videos here.

GraphQL and ApolloData

Gerwin Brunner speaking at viennaJS in May, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Find out what GraphQL and ApolloData are, plus play around with GraphiQL, and have an in-depth code view with a sample app.


- Hey, everybody. - Kind of still awake or somewhere in between. Let's do some kind of starting exercise. First of all, who has heard of GraphQL already? Put up your hands. Who has a clue what GraphQL is? Lift their hands up. Who has a clue what GraphQL is? Okay, who has worked with GraphQL already? Okay, so you're in the right spot. That's nice. Okay, what are we going to cover tonight? Yeah, what is GraphQL and ApolloData? Then, we play around with something called GraphiQL. Very clever joke with the name here. I will give you a sample application walkthrough where, very basic thing, to give you a kind of little bit more in-depth code view on what GraphQL really means. So, what is GraphQL? There is a pretty interesting explanation. It's a query language but for the application layer. Sounds cool, sounds fancy. And there's another one. It's a syntax that describes how to ask for data. Also very fancy. Does anybody have a clue what this means? When I saw that at first, I was like, "Hm, sounds cool, but I have no clue "how it's done." So, that's how GraphQL looks like. That's a query, and that's the response. Awesome, and it's JSON. Yoohoo! So what else is GraphQL? It's like, you have a query then you have something mystical which in this case is the logo from ApolloData, and then you have models and connectors and backhands, and you can do crazy shit with this thing. How does it look like with GraphiQL? So, imagine you've got a server providing data for you. And, I'm getting rid of this here, so this server has a graphical interface. It does not have to but in this case it has, so if you ever have had the pleasure to play around with Postgres, you probably... Or MySQL, you have seen this PHP application thingies. MyPHP, uh MyPHP app, no, MyPH... MySQL PHP thingy, where it just throws something in. This is kind of similar. So, it's on the server that provides our data model, our API basically. So, what you can do here-- Oh, it's fancy! It has code-completion in the browser. Um, so, okay! I want to write a query! I give it a name, "myQuery," and then I open the brackets, and it does suggest me something. I can fetch the user and the state. Let's go for the state. Oh, and there is a prettify me. That's really helpful. And if we run that, nothing happens, which is super uncool. Okay, let's copy this query and try to reload the server and then we figure out something died. Really, I did kill the server, because you have to start a server. Makes sense. And we try again as soon as it stops, so in the meantime, this is the Meteor Apollo sample project, which is a really simple quick start application thing, and it just wires everything up for you. So if we do a reload, here we go. That's nice, so yoohoo. We got some kind of state here, and as you see here in the background, the server does automatically change the state, so, every eight seconds, I get a new value. Okay, so we saw the code-completion thing here before, so let's add something. Oh, a user. And if I just run the query, this thing does auto-completion, because user is an object in itself. It's not a property like the state we had here. So it fills out automatically the properties you defined. In this case, random string and ID, and on the right side you see it's returning the stuff. And is there something else? Oh yeah, there's emails, and it's again, an array in this case as we can see here and we get the currently locked in user back. So, fancy right? Makes things really easy. So, but, do we already know what GraphQL really is? What is it? One endpoint to access all your data, so all Lord of the Rings fans can freak out already. There's the one ring, so we all know this scenario. You have rest. You have clients, and it starts really cool with nice APIs, but after a while, it gets really crazy, like, really crazy. And with GraphQL, it's the one endpoint that rules them all, so you just have one instance and you just query them. Sounds cool, right? Another cool thing about GraphQL is you only retrieve the data in an API call that you really need. So, in rest, you get like everything that is on the resource or you go a little bit off standard and do something like parameters in the query where you restrict the stuff, but in the end, you just get what somebody's designed you to get. With GraphQL, as you already saw in the GraphiQL example before, you can say, "Oh I'm just interested "in like the state and the user "and I don't care for the emails, "so I'll leave them out." So you only retrieve the data that you really need. So, there is no need anymore to tailor endpoints for your views. So, it's not anymore like, you have a generic consumer, you have a mobile application, you have a web application, and you run like 15 different APIs that provide like, yeah, your basic shopping cart or whatever. And like in the fancy web view, you also add like the customer information already in this one query, but on the mobile device you don't do that because you don't display it really there. So you quickly end up with different APIs or hacks on making this one API you have more smart. With GraphQL, you just create the query you need, and that's it. And you just retrieve the data you need. So, and then, the biggest plus I think, my personal favourite is no more freakin' versioning of APIs. So, has anybody had to deal with versioning rest APIs? Did you like it? So, yeah, I guess not, because it really gets messy really quickly. I did mention it before, GraphQL, for those who don't know, is basically thrown out into the wild by Facebook, so the specification is made by Facebook, and they came up with that, because they really early on figured out, "Hm, crap, we're having like a tonne "of different clients and a tonne "of different versions "and we iterate really quickly "and we need to solve this problem." And that's what GraphQL does. And so, there are still very early implementations of clients for Facebook on their GraphQL API that still work that are like five years old, so that's really impressive there. So no versioning. You just have one generic schema, and I mean, you can do like, phasing out stuff. You can mark objects as obsolete, but you don't have to really roll out a new version which is a pretty common pattern with REST, where you have like the version within the URL to mark the... - [Student] Which means that I cannot change my data by schema? - You can. I mean, uh, if you change it so hard that you basically go from, oh, this is a blogging software to now we do management of Texas. - [Students] Let's take a very simple case. I had the idea I could make a social media website and I thought, "Oh, every user will have "one email address." I made a string field email and then I figure out, "oh, people have multiple emails "and so when I have a one to n relationship." - Yep, so what you would do in this-- - [Student] So, I would have to, in my business logic, have kind of some mapping that every time someone changes the new email array, the one email is changed and it was database - Okay, schema doesn't mean database schema. It's totally decoupled. It's just a schema for your API or for your data, whatever, wherever you put it in your stack. And you don't even have to have one data source. As in the picture before, there are like... Let's just jump back here. You can have like any kind of backend tied in your schema. It doesn't matter. You can have like five different databases. - [Student] It'll help with write some kind of transformation rule to still provide the whole fields. - You have connectors and resolvers that figure out what part of your schema is resolved how and where it's derived from and so on. So, how you would do this one to... So going from one to n problem is basically... in the database, you have to figure it out somehow. So probably instead of having email and then the probably after the email, you'd change to emails, and then keep the email field with an index, an index that's pointing to the array or something like that and then you just change the logic in the resolvers to facilitate that. But in the schema, you would still provide like the original email address that gives you one email address, the one that you selected there, and like the array for the new clients in an ordered list. Does it answer the question? Okay. So, no versioning. That's cool, and only one endpoint. If I didn't emphasise it enough, and for those who are not yet asleep, this is the same point than the first one, so only one endpoint is required for all your data needs. Okay, let's take a look at a real world application. So, boilerplate application which and I don't explain it here. There is a login that's handled by Meteor. Fancy pantsy around in the bag, so we don't care for that. We just assume we have a connected user, and then there's an interesting thing here. Now, I logged out, and if I run this query that we just retrieved before. Again, I do not get any information except the state, because the state is public but the user is based on the current session. So that's dropped out, and if I log back in, when I remember which user, yep. If I log back in, I get the information. Again, of the logged in user. So, how is the magic basically happening? So, in... and this can be done in any note server. There are different implementations. I think the most mature right now are in the JavaScript universe. One is ApolloData. The other one is Relay from Facebook itself. But there are already coming up implementations in various different programming languages and clients are there like for every platform you can imagine. I don't know how good they are, so you have to look into how good they already are. If you want to use it in, I don't know, whatever language you prefer, Urlang, I have no clue, I haven't looked into that, but you could, and I guess there is one. So, you basically start up the server, and what you have here is you specify the interface where your single Apollo endpoint resides, and just throw it up, and then you have an Apollo application server running and waiting for your requests, which is crazy because I'm showing you the client right now. Forget whatever I told you. Here, that's how we create the server. Yeah, that looks more like it. So, what do we do? We have the schema that consists of a type definition resolvers and we throw this schema in and create Apollo server function which is provided by the Apollo framework. You throw it in, fire it up, you're good to go. So, the important part here which applied to any GraphQL server is, or servers are the schema and the resolvers, so let's dig into those. Schema, here we go. So, what is a schema? So, a schema is just the definition, and there are four main parts, five main parts, depends on what you're looking at. We looked into queries, so you define a query, and the query returns a user and a state. Oh, we saw that before in the GraphiQL example, and we see the definition of the user is not a object user, and this is a string which is a predefined thingy. So that's exactly what we see here. If you run it, you get here. You get a string, and for the user, you get like an object. And so, if we walk down, the user is defined down here. It consists of email, random, blah blah blah. That's a regular schema. You're probably familiar with that, and then you wire this up where you say the schema itself consists of query, mutation, subscription, and yeah, that's kind of it. That's the part for creating the schema and doing the query. The other part is if the server receives a query, what does he do with it? And that's where the resolvers come in and do their magic. So, if we, for example, take a look at like the simplest possible query we can imagine in this scenario, it's a query that just queries the state. So, what does it do? Here we got a resolver that listens for a query, and we have a state function, and the state function in this case does nothing else than just returning the state of R, which is just a plain variable in this file that's changed by an interval every three seconds. Yay. So, a little bit more complex is the user thing that we had here, which is derived by a context. This is magic from Meteor where it just sneaks in the Meteor user and returns it as the object with the random string, ID, and emails and stuff, so okay, that makes hopefully a little bit of sense. So there are the two parts. The one where you define the schema and that's what you can query from a client and there is the autopod in the server that needs to basically execute the schema and figure out, oh, that guy asked for state, user, random string and ID, how can I figure it out, and what it does is basically walk down the list and sees, oh query, and he asks for user, so call this function and do this stuff there, and he asks for state. So call this function and do this stuff. And you can basically go crazy behind the scenes here. You can do anything. You can, as mentioned, call a database, I don't know, query a sensor, whatever you can imagine, you can do here. Or whatever you are capable of doing with JavaScript code, you can do here or know code in the sense. Okay, so querying is fancy, but what if I want to change something? "changeSomething." So for changing stuff, we need mutations. So, here we go. Oops. Where have I... So, let's take this one. So, this is a mutation where you basically say, "Oh, the client wants to update something on the server side." So, I just run this, and then I rerun the query and see, test was the thing I sent in as a new state and it updates the state, so hooray, that worked, and the worker here updated after three seconds. So, that's the really really really simple and rough overview. Okay, so... - [Student] Excuse me. - [Gerwin] Yeah. - [Student] To insert new elements, it's also with a mutation? - [Gerwin] Yeah. - [Student] Okay. - [Gerwin] You use mutations for that, and that's basically the only way how you can do anything from the client. You go from mutations, queries, and what I didn't show here is like subscriptions. A subscription is basically published subscribe, so you can get real-life Feedwire, WebSockets for example, to have instant updates whenever something is changed on one end, in one client, and you want to update automatically all clients, you would use subscription and not Polymer, something like that. Okay, conclusion. Is it perfect? Um. At least not yet, but we're like 80%, 90% there, so my personal... Okay, so second question, should you look into it? Absolutely, it's the future of Meteor, and it's going to be the future in terms of enterprises, so I've been in, yeah, quite a few large organisations doing like innovation projects and like, a lot of them struggled with exactly those problems, like a year, two years, three years ago, and I think the technology or the idea behind GraphQL is really awesome, and could solve a lot of those issues. So, I recommend everybody to look into that because that's going to be the password pretty soon in all enterprise world. So, can I use it in my enterprise? Yes! And yes and yes! And the cool thing is the transition is super easy, so you can throw in, especially Apollo, really in any project you have right now, build a small-- I mean, get basically the foot in the door. Already use the advantages without having to revamp the whole thing. You just can start with small pieces and continually iterate and get more stuff onto those queries, and it really will pay off very nicely soon, and very soon, so it's super easy to get started. The only thing you have to have is like one server that is basically the API server, and then just hook up the clients and you can use like both, or any way you already use for the application, and then also have this GraphQL endpoint where you start to build some queries and stuff upon it based on the useKit, so there is absolutely no excuse to use it in any project or any project you are right now working on. So, Meteor stuff. Apollo stuff. Links. Awesome. Thank you.