Special Guest: Sean Grove.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project or I just got off a call with a client or something like that, a lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little. Or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so I was looking around to try and find something that would work out for me and I found these Factor meals. Now Factor is great because A, they're healthy. They actually had a keto line that I could get for my stuff and that made a major difference for me because all I had to do was pick it up, put it in the microwave for a couple of minutes and it was done. They're fresh and never frozen. They do send it to you in a cold pack. It's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And, uh, you know, you can get lunch, you can get dinner. Uh, they have options that are high calorie, low calorie, um, protein plus meals with 30 grams or more of protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet. You know, obviously if I'm eating keto, I don't do all of that stuff. They have smoothies, they have shakes, they have juices. Anyway, they've got all kinds of stuff and it is all healthy and like I said, it's never frozen. So anyway, I ate them, I loved them, tasted great. And like I said, you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals. Head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project, or I just got off a call with a client or something like that. A lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little, or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so, um, I was looking around to try and find something that would work out for me and I found these factor meals. Now factor is great because a, they're healthy. They actually had a keto, uh, line that I could get for my stuff. And that made a major difference for me because all I had to do is pick it up, put it in the microwave for a couple of minutes and it was done. Um, they're fresh and never frozen. They do send it to you in a cold pack, it's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And you can get lunch, you can get dinner. They have options that are high calorie, low calorie, protein plus meals with 30 grams or more protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet, you know obviously if I'm eating keto I don't do all of that stuff. They have smoothies, they have shakes, they have juices, anyway they've got all kinds of stuff and it is all healthy and like I said it's never frozen. So anyway I ate them, I loved them, tasted great and like I said you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals, head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

 

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from sunny, pleasant Grove. 

CHARLES MAX_WOOD: Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: AJ, what are you doing halfway to my house? 

AJ_O’NEAL: Uh, I that, well, that's, that's where my house is now. 

CHARLES MAX_WOOD: Oh, you moved. I moved. All right. I'm Charles Max Wood from devchat.tv and, uh, this week we have a special guest and that is Sean Grove. Sean, do you want to say hello? 

SEAN_GROVE: Hey, thank you for having me.

 

Wish you could speed up your release cadence and skip the rollbacks and hot fixes? What if you could move faster, limit the blast radius of unforeseen problems, and free up individual teams to deploy as fast as they can develop? Splits feature delivery platform gives you progressive delivery superpowers like the coupling deploy from release, gradual rollouts with automatic telemetry to detect issues before they show up in operations graphs, and the ability to prove whether your features are hitting the mark using real user data not the highest paid person's opinion. To learn more and sign up for a free trial, go to split.io. 

 

CHARLES MAX_WOOD: Yeah, do you wanna introduce yourself real quick since we haven't had you on the show before? 

SEAN_GROVE: Yeah, sure. So I work at a company called OneGraph, which is a GraphQL company. But before that, I ran engineering for a payments company. I used to work on the ClosureScript compiler. I worked, implemented the source map support. But these days I tend to work mostly in Reason and Rust and work on DevTooling a lot. 

AJ_O’NEAL: What about the RFID chip in your hand? I feel that's an important part of the introduction since you're the first cyborg we've had on the show. 

SEAN_GROVE: I see, yeah. I used to have a RFID chip that I put in my hand maybe about 12 years ago because I lost my keys in my car eight times and I realized at some point that it was just crazy of me to think that I was going to change. You know, like how many times did I have to do it again and again? So I decided if I wasn't gonna change, I had to change my environment. So I was taking a pro section course and I had a scalpel, so I was able to just cut myself open, pop it in my hand. So back up, I saw the door popper in my car and never forgot my keys again until the RFID chip died and stopped absorbing any power about four years later. 

CHARLES MAX_WOOD: Oh wow, that's hardcore. I don't know if I could ever cut myself open. 

SEAN_GROVE: I mean, it was very small. An RFID chip is about the size of a a thick grain of rice. It's not too bad. 

CHARLES MAX_WOOD: Right. I guess that's true. 

AJ_O’NEAL: That's, I don't cut myself large enough to like, I'll get a splinter out. I'm not going to put a grain of rice in. 

SEAN_GROVE: Well, I mean, if you, if you keep spending money on, uh, you know, tow trucks to come and unlock your car, what are you going to do? 

AJ_O’NEAL: I, I guess I'm going to cut my hand open and put rice in. 

SEAN_GROVE: You got to engineer a solution, right? So, or maybe over-engineer a solution. 

CHARLES MAX_WOOD: I love it. What's interesting to me though, is just at what point is that going to become normal? 

SEAN_GROVE: So, well I think that there are probably better ways of doing it now. Um, like using your phone, which would be a much better way of doing it. But you know, 12 years ago it wasn't, we didn't have, you know, NFC and whatnot in the phones. 

CHARLES MAX_WOOD: No, I guess what I'm saying though is that, you know, we have some kind of biometric where yeah, you walk up and you wave your hand to open the car door. You know, you're talking about doing it with a phone, but you, I mean, they're anyway, I could geek out about where, where this all could go. You could tell your Amazon Echo to unlock your car. I don't know. But yeah, so we're talking about GraphQL. And yeah, do you wanna just give kind of a high level overview? We've talked about GraphQL before, so I don't wanna spend too much time on what it is. I would like to talk a little bit more about the tooling and how you folks at OneGraph do things like the graphical explorer and things like that. 

SEAN_GROVE: Yeah, sure. So, yeah, GraphQL itself is a way of building APIs. And so it's, you know, normally thought of as kind of like a backend topic, but one of the strengths of GraphQL is you have like a limited ability to query for the data you want. And so what that means is a lot of the times with a REST API, for example, the backend developers have to very, very carefully think about all the use cases ahead of time. And if they didn't think about how you want to use an API, you know, the product or the UI you're trying to build then it can be really difficult to work with it. And so GraphQL gives the front-end developers much more flexibility and the data that they can pull out and how they can pull it out. But for me, the most important part of GraphQL is that by definition, every GraphQL server is introspectable, which means that a computer can ask a GraphQL server and say, hey, what data do you have available? What fields do you have? Give me their description, give me their types. And that means the kind of tooling you can build and the developer experience you can build for the front-end developers is just phenomenal. 

AJ_O’NEAL: So how is that different from Swagger? 

SEAN_GROVE: So it's really similar to Swagger in that it's Swagger is a computer-readable description for REST APIs. The difference with Swagger though is Swagger is, in our experience, is actually usually best effort. So people oftentimes don't write Swagger ahead of time. It's they write an API and then they go back and try to add Swagger and they almost certainly, um, diverge at some point. If a team is, uh, really, really disciplined, then they may, you know, stay in sync and that's great, but it's, it's my experience that most teams, you know, something happens, you have priorities and it's just like writing tests or something like that, you're sure you're going to come back and document it later. Uh, but it almost certainly falls by the wayside. Whereas with GraphQL, you cannot construct a GraphQL server without having that, like a superb level of introspectability. 

AJ_O’NEAL: So a lot of Swagger ends up being manual, although in theory it would be automatic. But GraphQL is required to be automatic. 

SEAN_GROVE: Exactly. And I think if you look at Swagger and OpenEPI, the tooling that's built on top of that is also really, really impressive. And so you can see that there is a big trade-off. It's just very difficult whenever you're trying to manage different priorities around shipping and products and whatnot to maintain a high enough fidelity of description for a rest API. 

CHARLES MAX_WOOD: So yeah, let's, I really want to dive a little bit more into kind of the tooling. So, uh, one of the tools that I'm fairly familiar with, at least on the backend is Hasura, um, disclaimer, they are a sponsor of the show, but yeah, it's, it seems like there's, there's tooling for the backend as far as here's a database or, you know, here are a set of rest services, you know, connected together and now, you know, now you have a graph a graph QL API. And then on the front end you've got different for lack of a better term explorers that allow people to, you know, jump in and kind of experiment with graph QL. So what's your experience with those? 

SEAN_GROVE: Yeah, I think one of the original kind of killer experiences for GraphQL is what's called the Graphical Explorer. Uh, it's a nice, nice little pun. And the idea is that it's, it's an open-source tool that you can point at any GraphQL server and you'll get nice, auto-complete. It's a little playground where you can explore an API, build up GraphQL queries, uh, play them, run them, test them out and get some data back quickly. Uh, as well as search through the documentation. I, it was compelling because. You could point it at any GraphQL server, including your own and gets this experience. It was, it meant that there was now open-source shared tooling that you didn't have to build on your own. Um, and I think since it's come out, uh, it, it languished a little bit, uh, you know, as I think the rest of the GraphQL ecosystem got built out from about a year and a half ago or so it's, it's really started to accelerate and we're seeing a lot of changes and a lot of additions to it that I think are really impressive.

CHARLES MAX_WOOD: Nice, so what exactly does it do? I mean, I've used it, and it's a handy tool for exploring what's going on. And you can also get some of the type definitions. Is that the way you think about it in GraphQL? 

SEAN_GROVE: Yeah, so you can imagine, for example, that it starts with this blank canvas. You have two panes. One is you're building up your GraphQL query, and you hit play, and then the other pane, you're gonna see the results for it, which is just some JSON response from the GraphQL API. And in the blank panel, whenever you hit control space, it'll auto complete and say, here are all the fields available. So for example, you might see a users field. And so it'll all expand users. And as you select that and you descend into users, you hit control space again, it says, here are all the fields available for users. So first name, last name, email, and so on. And so it's this really nice way of just kind of auto-completing and building up GraphQL queries that you can then copy and paste into your React code or your view code or wherever you're using GraphQL. And that same experience actually has been replicated now inside of VS code. So now like directly inside of VS code, whenever you're writing your GraphQL queries for your React application or whatever, you'll get this nice auto-complete query for your users and get the exact fields that you want out of them. And you can do this in a way. Uh, you can, it's, it's a kind of magical and bizarre experience because you're auto-completing inside of your editor, a remote API, right? So imagine, you know, every time you've ever done some integration with some third party API and you've gone and you've read their documentation and you've looked up the endpoints and you figured out what the fields are going to be and how to call it, all of that goes away because you can just write it directly inside of VS code and get that nice auto-complete. 

DAN_SHAPPIR: Uh, this is Dan. I'm really happy that I managed to join after having some unexpected connection problems at home. So hi, Sean. So basically I'm kind of stoked that we are extolling the virtues of typing and type safety and whatnot in a JavaScript podcast. 

SEAN_GROVE: Yeah, it's usually not my leading pitch for JavaScript people is the type system. Yeah. Yeah, but I do think that because of the introspectable nature where, you know, you get that nice auto-complete and everything, but you can go even further. And so we built a little extension for the original graphical tool that we're talking about where it gives you almost a file system view where you can literally just, uh, if you know, you click through, you see all the fields that are available. And if you click on it, it expands and you can select the sub-fields and they'll expand and so on and so forth. And the reason we did this is, you know, GraphQL is, is still pretty young. And so, you know, we're at a company called OneGraph and people who sign up for OneGraph typically aren't excited about GraphQL, they're just wanting to get their data out of Salesforce or QuickBooks or wherever. And so a lot of the people actually think that GraphQL is our own proprietary language, so there's a lot of customer education involved and what we wanted to do was find a way to make it so that. When someone is first using GraphQL that they're as productive as possible. And one of the challenges with dev tooling and any sort of like, you know, if it's a functional programming or GraphQL or whatever it might be is almost by definition, as soon as you understand the technology, you are incapable of explaining it to someone who doesn't understand, right? You're so stoked on it, but you can't really explain it. And so people were really happy with graphical, with those two panes that I talked about, where you build up your query manually and you see the results. But for a new user, an empty canvas is incredibly intimidating, right? Like GraphQL has its own syntax. It's different from, it looks like halfway JSON. It's not too bad to learn, but it's still a big step function, from knowing nothing to knowing how to input syntactically correct GraphQL queries. But with this GraphQL Explorer approach where you can just kind of click your way through and see the GraphQL query building up, it meant people could express the data that they actually wanted and get the results out very quickly without being forced to sit down and learn and deal with a blank canvas. 

DAN_SHAPPIR: But does it still mean that at the end of the day when I'm embedding a GraphQL query inside of my code, I'm essentially just embedding a big string that maybe a tool generated for me, but from the perspective of the language that I'm currently using is just this big string? 

SEAN_GROVE: Yes and no. So depending on how you use it, so just like the raw level, say for example, you're calling a GraphQL API from the browser and you're just using fetch. In that case, you can just embed the GraphQL query as a string that you're going to send to the server. But most people will actually use it with, for example, the GQL template string. And what this does is actually gives the pre-processor the ability to analyze that string and for example, do generate type definitions or that kind of thing. You do still end up with a, you know, a blob of a string inside of your component. Uh, but the tooling is able to extract structural information from that and then help you along the way and to make sure, for example, that whenever you're consuming the results of that query inside of your UI component that you know that, for example, field might be nullable, right? A user might not have an email. And so it'll ask you to actually, you know, do a, to double check and make sure that you're not using it in a way that's going to cause any sort of runtime exceptions. 

DAN_SHAPPIR: So, so are we talking about just the dev tooling or like a deeper integration? Like, I don't know, like JSX or something like that. 

SEAN_GROVE: Yeah, it's just a, like inside of a VS code, if you're using, for example, Apollo or really actually any GraphQL client at this point. Just by putting inside of GQL, what it will do is actually parse the GraphQL query at build time or inside of dev time, and then generate all of the structure that you need. You can do a lot more like that, other than that. So for example, in our case, inside of GraphQL, so not only can you introspect a GraphQL server, but introspection is so deep inside of the GraphQL community and its culture. You can also easily introspect GraphQL queries themselves. So what we do is we have like a little demo that I like to do where we just go through and we use that Explorer and we explore the Spotify API and we build up a couple of queries to get data out, to search them for a couple of songs. And we use some mutations, which are, you know, write functions or effects to build those Spotify player with pause and resume and next, and then we analyze that. And we can actually generate an entire react application with all of those individual components. We also, I mean, my, for me, my favorite is actually generating a bash script because I can't write bash, but I love being able to explore any of these APIs, analyze them, and then generate a bash script that I can use to control Spotify or, you know, to, um, you know, get my tweets or read RSS or whatever it might be. Uh, so you can, you can also introspect the types and the GraphQL operations at dev time as well. 

AJ_O’NEAL: So are you saying that Spotify has a GraphQL API or that you are exposing one through one graph? 

SEAN_GROVE: We expose one through one graph. But the same principle will work for any GraphQL API. So for example, tomorrow GitHub could add both the Explorer and the code generator to their graphical instance. And they wouldn't have to invest any additional effort, and all of their users would benefit from it. That's what I really like about the nature of GraphQL, is it means that there's a shared set of tooling that kind of helps every developer, like the experience is much, much better. Rather than right now, you know, if you think about the companies that are well known for good APIs, you can kind of name them on one hand, because most companies don't have a ton of efforts or a ton of resources to invest in a really good API experience. 

AJ_O’NEAL: So, okay name them on one hand? 

SEAN_GROVE: So I think Stripe is the one that comes to mind. They are really excellent on several different levels. I actually think Spotify also has a very good API, GitHub, before the GraphQL also had a really great, a really well-documented REST API, and they still went over to GraphQL for one of the reasons we've been talking about. I can name a lot that don't have a great API as well. 

AJ_O’NEAL: But I'm going to throw a mail gun out there. I, you actually, two that are on my list of what I think of great APIs, mail gun and strap come to mind every time. 

SEAN_GROVE: Yeah. I think no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no

 

AJ_O’NEAL: different tabs you can click on for what language you want. And then it shows you an example that you can literally copy and paste. And the case of Stripe, if I'm not mistaken, you log in, you can view the documentation anonymously, but if you log in, it uses your dev key. And all of the examples is that is Stripe, the one that does that. I can't remember for certain. 

SEAN_GROVE: Yeah, they do. 

AJ_O’NEAL: Yeah. And I thought that was just that's it's next level and it shouldn't be.

SEAN_GROVE: Yeah, exactly. And that's exactly how I feel. Um, cause you know, I want that, but I don't necessarily want to spend all my time implementing that. So it'd be great if we could just, you know, uh, share the effort across the community. 

AJ_O’NEAL: So speaking, if I'm okay to take us, uh, back to the GraphQL, but in a different direction, um, one of the biggest criticisms of GraphQL is the story around authentication and authorization. So what. Do you have any, what do you do other than throw your hands up and pull your hair out? 

SEAN_GROVE: Yeah, so for me, it's great for public APIs, you know, in terms of all that, the explorability you're talking about. But as soon 

AJ_O’NEAL: as the API requires a log in, it's constrained, like admins get different sets of data or edge points than users, you know. Sorry, go on. 

SEAN_GROVE: No, no, I think it's a really good point. So one thing that I like about GraphQL is there is an easy way to get kind of a human-readable description of a GraphQL API. So it's called the Schema Definition Language. And so it just says something like, hey, there's an object called a user and it has these fields that are of these types. It's a string and a non-nullable int or UID, that kind of thing. But the other cool thing is, inside of this Schema Definition Language, you can also add what are called directives. It just a little like little tags of metadata. It just looks, you know, a little ad symbol. And what I really like about this is you can, for example, build a simple authentication or authorization mechanism where you say this object, this user object turns out you can only get to it if you are at authenticated and then you can also do things like authorization, right? Authentication is actually the easier of the two authentication is just who are you authorization is a like significantly more challenging problem because it's figuring out what are you allowed to do. And that often depends on lots of different data. And 

AJ_O’NEAL: I would refine that one little bit to say, authentication is, are you who you say you are? Doesn't necessarily define who you are, just that you are who you say you are, which is kind of weird, but authorization, because once you are a person. Like I can say that I am John, and if I can prove that I'm John with, even if it's a pseudo-identity, if I can somehow verifiably prove that I am, that I call myself John, and that when I call myself John, John is who I am, that is, that is, that allows you to attach an identifier. But the authorization being, how do you then give a privilege to say, this person that calls themselves John, the himself John is allowed to be an administrator or such. 

SEAN_GROVE: Yeah, so what I like about the GraphQL schema definition language, you can build tooling that says, let me see all the data I have in my API, and let me look at the user object and say, of these fields here, which of them, maybe there's a account balance field. And I'm gonna tag that with an at, requires authentication of quote unquote admin or finance or something like that. And being able to tag it with, you know, either the roles or authentication, um, means that you can easily summarize the rules for your API separate from the actual implementation. So that's on the server side. 

AJ_O’NEAL: Uh, is that newer? Cause I don't, I don't think I'd heard about that before. 

SEAN_GROVE: So the technique itself is relatively new, but the, so there isn't a standard implementation. I mean, Apollo has theirs and we have ours. Um, But the idea is relatively new. So the directives themselves have been there for a while though. It's also how you would, for example, deprecate a field is you just add an ads deprecated for this field and it will still be available for everyone, but it will no longer show up in any of the tooling that we've talked about and, you know, that kind of thing. So being able to quickly add metadata, uh, means that authentication authorization can be handled in a really powerful way. So that's on the backend. Now on the front end, what you can do. Uh, and what we do, so, you know, one graph is a, is a GraphQL endpoint through which you can get data from Salesforce and Spotify and Stripe and NPM and GitHub and all these, these different, um, uh, public APIs, but that means that we have to implement, you know, authentication and we have to understand OAuth permissions for all of them. And, uh, as a developer, like you really should be implementing progressive authorization where if, for example, you're building a Gmail application, you shouldn't ask for both the ability to read my email and also send email until I actually try to send an email. But this is so painful to do as a developer, right? Because I have to kind of carry this knowledge around with me and think, all right, have I asked you for this permission? The thing that I'm about to do, what are the permissions that it requires? Have I asked you for them beforehand? Are they still valid, et cetera, et cetera? 

AJ_O’NEAL: Well, a lot of times the way that's done is you just try to send the email, and if it comes back with the authorization error, then you present the dialogue that time and you can kind of skip all of the state holding because the moment you try to do it, you know whether it works or doesn't. 

SEAN_GROVE: Exactly, and that's actually what we're starting to see inside of the GraphQL world where there's becoming more and more normalization around both authentication and authorization. So the idea is, rather than asking the user upfront for, hey, you've just logged into my application, I need these 20 permissions to everything. What you do is you just program as though you have access to everything. And on the GraphQL server side, what you do is you just annotate, using that same mechanism, what are the permissions required to view any of these fields? And now you normalize that error, right? Cause GraphQL will give you partial success. So you can run anything and it'll give you back a list of data that came back and a list of errors. And so you just look through the errors and you say, were there anywhere the auth was missing or it was insufficient? If so, what's the service and what's the permission? And now I'm going to ask the user with one function that just checks the results of every response and says, Hey user, that thing you just did. It turns out we need permission to send, you know, emails on Gmail. Uh, do you want to grant that to me right now? So now as a programmer, you don't have to think about what permissions you have. Like you said, you just program as though you have access to everything. So now on the server side, you've kind of gone through and you've annotated everything and you don't have to think about implementing it on the client side as a developer, you no longer have to think about, you know, what permissions have I asked for and am I implementing this correctly? And also as a user, most importantly, you get this really nice experience where every time the application asks for increased permissions, it's always contextually relevant. It always tells you, like you always understand why it's doing this. 

DAN_SHAPPIR: And this is a service that you as OneGraph provide, correct? 

SEAN_GROVE: It's yes, it's a service that we provide, but the pattern itself works for any GraphQL

AJ_O’NEAL: Well, it works for any server period. 

SEAN_GROVE: Yeah. 

AJ_O’NEAL: So one of the things that, that this is part of my beef with GraphQL is people start talking about things and it goes from the, the practical to the magical pretty quickly, like you just described something that I don't know of any GraphQL server that actually implements any of that as a out of the box type of thing, like that's all custom logic. So Yeah, you declare the type annotations in the schema file, which I did not know about that. And that's cool. And that gives the downstream, something that feels cute and pretty and easy to use. But upstream on the back end, you still have to do 100% of the work to make that happen. And I mean, it contradict me if I'm mistaken and you've got some toolkit that makes that easy and simple, but as far as I'm aware, it's still the same you do it all yourself as it is with REST or with, you know, soap or whatever. 

SEAN_GROVE: Yes and no, I think it's a little bit more nuanced. I mean, it's a fair point that, you know, it goes, it can go to magical and fantasy land pretty quickly. But I think because of the, well, let me back up and say that GraphQL in many cases, I think will take more effort to build than an equivalent REST API. Because it does say, hey, what, ahead of time, you have to tell it, what are all the fields that are available? What are the types? Give me some documentation on that kind of thing. But because you can do this, you can easily describe the permissions for each of these fields as well. And now what you can do is just as middleware, you know, it's kind of orthogonal. So whenever you're actually implementing the resolver for that field, you don't have to care about what the permissions are, right? You're just getting the data and saying, if the user has permission to see this, um, then I'm fine to run. And if they don't, it won't have gotten to me anyway. And the way the open source package that we have that for Apollo server, for example, it's literally, I think, three or four lines where you just, you require it. There's a context function that says, whenever a request comes in, look at the bearer token, extract, you know, it's signed in a couple of different, it's a JWP or a job, and extract the information that's going to contain, you know, the user ID and the roles and now automatically, orthogonally implement all of the permissions. And that's again, it's-

AJ_O’NEAL: And so you said that you store the roles in the token. 

SEAN_GROVE: Yeah. 

AJ_O’NEAL: So the token, which this is, this is, yeah. So you are expecting what the token you receive to tell you what the permissions are rather than the backends. You're making the backend more storage-based and putting a role-based permission rather than a, I forget that I guess the term that would be synonymous that's not the exact term I'm looking for would be row level permission. Like it role versus row. Like you might have a coarse grade role of that, not fine grade control. 

SEAN_GROVE: Well, I think yes and no. So for example, with Hasura, Hasura does a really excellent implementation of row level security effectively. So you know, Hasura is this really amazing bit of technology open source Firebase, where you just put it. 

AJ_O’NEAL: Let me clarify real quick for the listeners, row level versus course versus find. Course role-based is like, I have access to the admin panel. I can do anything an admin can do. Row level or fine grain security would be like, these are my pictures that I uploaded as an individual that I have access to because they're my pictures or that I have access to because as a one-off, someone shared with me.

SEAN_GROVE: So that's cool. 

DAN_SHAPPIR: I actually wanted to add, by the way, I don't know if it was mentioned before that we actually had a JavaScript Java episode about us. So right. It was episode four or one. We'll probably put the link in the show notes. 

Hey folks, this is Charles Maxwood and I just launched my book, the Max coders guide to finding your dream developer job it's up on Amazon. We self published it. I would love your support. If you want to go check it out, you can find it there. The max coders guide to finding your dream developer job. Have a good one, Max out. 

 

SEAN_GROVE: Yeah, so it's an amazing bit of technology that has that row-level security where you can say, I have a list of movies and a user can only access the movies if their user ID is the same as the owner ID on the movies table. And it works in the same way as for example, the metadata annotation at the end of the day. So the token has a set of things like the current user ID,Um, and you can set the rules that will, um, look inside of the token and can run some kind of relatively simple logic on them. So the idea of being like, if the, uh, user points are greater than 42, then they can do this kind of thing. Um, and all that information does have to be stored inside of the token, but. In return for putting that in the token, that means as a developer, you can describe your permission sets declaratively, and then whenever you're implementing it, you don't have to worry about, you know, going through and you can do one thing at a time. You can implement a resolver and then separately you can think about, um, the permissions and the authentication story in and of itself. 

AJ_O’NEAL: So if I wanted to get, um, it sounds like there's almost two endpoints that you'd have for this one endpoint would be all data and another endpoint would be all permissions. So if I said, I want to get access to this photo, I would, would I then exchange a token at a permission endpoint to get a permission token and then go hit the data endpoint or how would I get a token that lets the thing know this particular photo was shared with me or something like that? 

SEAN_GROVE: Yeah, sure. So I think typically that happens in kind of the login process, right? So I come to your application and I log in and during that login process, you look at my cookie and my username or whatever you pull that out of the database. And you construct a token that is going to contain, for example, my user ID or maybe my team ID and the roles I have. And then it's going to be a, you know, signed in a way that, so you're going to hand it to me and say, Hey, store this. And whenever you hit my GraphQL endpoints, use this token. Uh, and that token will be signed in a way that if I try to edit it in any way, or someone else tries to edit it, then it will be invalid. And so whenever that token comes in, first, you're going to, you know, verify the signature and make sure that it hasn't been tampered with. But from then on, you know that the data that's in there was put in there by you. And so you know that it has a user ID, it has the team ID and it has the roles. And now inside of your middleware that's handling the auth, what you're doing is saying, all right, the user has asked for this field. What was the, the authorizations permission required for it? And if it says, well, the shared with, so this photo table, for example, has a join table with a, you know, shared with users and you have to have a entry in that shared with users where the photo ID and the user ID from your token are the same. And so like you can describe that all in the metadata. And now you implemented once inside of the middleware and then you just build your API. So there are kind of three separate systems. Now, one is you're just thinking about what's in the token and how do I construct a token? The second is how does the general declarative auth system work, and then the third is how do I actually get my data? And each of these is now handled separately and can be reused with different tooling, or across different tooling, for example. 

DAN_SHAPPIR: After going down this security rabbit hole so deep, can I ask you another question about a different topic? 

SEAN_GROVE: Sure. 

DAN_SHAPPIR: So one of the key things about one graph, as I understand it, is, I think you also said it explicitly, is that you take information from a lot of services and kind of join them together so that I can correlate between data coming from different sources, correct? So you know, we've been talking about the type system and how key it is to actually understanding what the data is and managing the data and manipulating the data. So my question then is, how do you ensure that the type system across all these services is consistent. That user entity, for example, in one system has essentially the same field as, let's say, a user entity in a different system. 

SEAN_GROVE: Yeah, so we don't do this in one graph, and that's because I used to do integrations a lot in a previous life. And at the payments company, we had to do over 100 different integrations and maintain them. And at one point we tried to do a unified data model across all these systems. And it caused a, you know, a lot of problems. Effectively, what you're running into is the least common denominator problem where, uh, every API gets dumbed down to just whatever they all have, which is, you know, maybe, uh, a name and an email. And instead what we do is we try to make it so that it's so easy to access the data across them that unifying them is, uh, relatively easy. And that, but it gives you the escape patch of whenever you wants to actually join or whenever you want to, uh, unify them, you can easily do that. Uh, one of the things we have been thinking about, um, along these, these lines though, is GraphQL has a concept of unions and of interfaces and interfaces is really interesting here because you could imagine allowing a user to, uh, create, you know, a, an intermediate API on top of your GraphQL API. And I'm getting hand wavy here. We haven't implemented this. This is just an idea that I've been thinking about, but what it would be is you would say, all right, I'm going to, you know, say some visual editor, maybe I'm going to create a new, uh, user object. And this is Sean's user. And it is an interface that has an email, a first name, a last name, uh, as required fields, anyone who implements this interface has to implement those. And so now I can go and say, oh, well, a Stripe user when converted into a Sean user, you know, map the first name into here and email to here. And same thing with Salesforce and same things with QuickBooks. But interfaces also allow you to say, you know, individual, um, GraphQL object types that implemented can also implement their own, um, extended fields. And so in this case, you'd have those required fields, but maybe a Salesforce user would also have a, you know, an account ID. I'm gonna select Sean's user from wherever they come. I don't care about where they're coming from. And I wanna have the email and the first name. But if it is a Salesforce user, I also wanna have the account ID. And so that might be one way that you could start to allow users to unify a definition in a really, really quick way without running into the least common denominator problem. 

AJ_O’NEAL: That sounds like something that's worth exploring in more depth, perhaps in another episode. 

SEAN_GROVE: Yeah, I think it's definitely a big challenge. And it's maybe the holy grail of integration, right? Where what you're saying is, I have my data model, and it's kind of spread out across all these different services and data storage and databases and whatnot. And being able to think about the problem in terms of my domain, rather than the implementation of where the data actually lives, would be very powerful, it's just, it's, it's fraught with, you know, inherent trade-offs. 

AIMEE_KNIGHT: I have a question that seems somewhat related to this. It's probably backing up a little bit, but when you've seen people start to move over to GraphQL, like I know we've talked about this a ton in the past on the show, but I don't think we've really like dug super deep into how. And when I say how, I mean, I mean, there's like, you know, you could go route by route, but do you think that there's value in like just going route by route and doing like just gets? Is it better to like go route by route and do you know get post like go go all the way if if your you know route has a need for that? I don't know because I feel like I've seen people have pain points where you know in in like the migration path.

 

SEAN_GROVE: Yeah, actually, this is one area I'm really excited about because we have a lot of internal tooling at one graph. You know, we have a lot of APIs that we've brought in and we need ways of doing a few things. One is quickly getting a definition of an API in terms of its implementation. The other is transforming that into a GraphQL API that's idiomatic and nice to use. Because if you just take your REST API and translate it over, it might not be that nice. Um, and then the, the third is actually knowing when an API has changed out from underneath us. And the interesting thing here is, and part of the, you know, to the earlier point about swagger and opening API is some of the partners who approached us because, you know, they want to have the, the GraphQL tooling that we offer for their users. They said, oh, we have open API specs or swagger specs. And we found that in most cases, they were actually, uh, not accurate enough to provide a stable GraphQL API. And so I think that the migration problem right now is pretty challenging. It requires a lot of effort. And for a lot of these companies, for a lot of these companies, it's actually like archeology. You go and look into their APIs because a lot of them are not as well documented as you might like. And so they have to go and figure out what are the routes that are available? What kind of data does it take? What kind of data does it return? Which of these fields are always going to be there? Which of them are knowledgeable? And so on and so forth. So one of the tools that we've been working on internally, and I'd like to open source at one point, is a nice little Rust network layer. And it can run either as an HTTP client or as like an Nginx module, or as a Kubernetes, like a sidecar kind of thing. 

AJ_O’NEAL: Rust, what's that? No. 

SEAN_GROVE: Rust is a nice type safe systems level language that has an amazing community and is, yeah. I will gush about Rust for a long time. I'm a big fan. But it's really good for people like me who are maybe not great at writing system stuff to actually write safe and efficient code. But what it does is it, it sits and set in the middle of the network and it analyzes HTTP requests and it keeps a little database about them. And it says, have I seen this host before? Have I seen this port? Have I seen this path? Have I seen this path with this verb? And it tracks novelty. And every time it sees a request coming in that it hasn't seen before, maybe there is a new variable included, that's a novel event. And it will look at both the input and the output. And it will look at the output and say, well, I've seen this endpoint before, but let me look at the output. And this output before always had a name field, and that name field was always a string. But now that name field is not here. And that means that that name field must be a nullable string. That key must be nullable. And any field, and you can do heuristics, right? Where you can look at any field that ends in ID. And what you do is you take that ID and you put it over this side. And any endpoint that returns an ID of that same value, it suggests that that previous field, for example, customer ID of, you know, 1 million, and then there's another endpoint that's hit and it returns an ID of 1 million it suggests that maybe that customer ID was actually pointing to this field. And in particular, if it's a valid UUID or a GUID, then it strongly suggests that that's a connection and you can actually probabilistically derive both the structure of an API. So what is input and output, but also the graph structure of an API. And you can also do this to detect, for example, authentication methods and whatnot. And then having recovered that. So basically it tracks the novelty until it hits zero. There's been nothing novel until, uh, you know, over the course of some amount of time and some amount of, um, requests. And it's almost like putting your API in the oven and then the light will ding and says, Hey, I now have a full accurate ground truth of what your API is and based off of this, I can actually generate about 80% of a GraphQL server. It'll be a GraphQL server that works really well, but now you have to make it idiomatic and that has actually been really valuable for us to figure out what's the, not what do you think your API does, but what does your API actually do? And then based off of this, it makes migration much, much faster, right? Because you can use that type definition to actually incrementally get over to GraphQL. 

DAN_SHAPPIR: So it seems, oh, sorry, Amy, but I just wanted to mention that it seems very reminiscent of some of the tooling that we heard in the show in the context of Swagger and the OpenAPI. You know, instead of generate, they generate the YAML file and it seems that in this case you generate the GraphQL definition. But otherwise it seems very similar. 

SEAN_GROVE: Yeah, except that we're doing it, do they also do it off of the network traffic? 

DAN_SHAPPIR: I think that such a tool was mentioned. Obviously the devil's in the details and I would probably need to go and listen to that show again. But as I recall, similar tools were mentioned. 

SEAN_GROVE: Yeah, and I think that the important there is just getting the ground truth of what an API is actually doing. And then, you know, a swagger open API definition or GraphQL or whatever it is just kind of falls out from that ground truth, right? 

AJ_O’NEAL: I feel like yes is the only acceptable answer. 

AIMEE_KNIGHT: So I still wanted to like dig deeper into my question because you know, say you don't have a tool like this, because I know you had said, you would like to open source this, but because I feel like from what I've heard and what I see at work, like some of the biggest gains you see in GraphQL is for get requests and then like a lot of the pain points are when you want to do mutations. So do you think there is any value if people are trying to, you know, do this in parallel with future work and migrate that way? Like in not going like full in CRUD and just focusing on get requests at first? 

SEAN_GROVE: Yeah, I definitely think so because, well, not only that, but one of the common patterns that we see is kind of you have teams who are building a product that don't necessarily control the API, right? The API on the back end is controlled by someone else. And so those teams oftentimes end up maps just the bits of the backend that they actually care about in a way that makes it really fast to build the UI. It's almost like building a custom product base or an intermediate API that's just for them. So it's like the backend for the frontend, I guess. And then for every bit that they actually bring in there, they get all that nice tooling that we're talking about. So explorability and code generation and that kind of thing. And they can incrementally migrate over. And I think, you know, GraphQL and React both came out of Facebook. And you can tell because they both have a strong emphasis on incremental adoption, where the, if you have to stop the world and rewrite everything, it's almost certainly going to be a failure, right? World, like whole rewrites almost never succeed. 

AIMEE_KNIGHT: Yeah. So I really like, not only like, can you like not advocate for the time to do it, but it's risky. 

SEAN_GROVE: Yeah, exactly. If you don't control the backend API and it keeps moving, then you have like two things that you're trying to keep up with a moving target while also trying to build a product that's really, really difficult. 

AIMEE_KNIGHT: Okay. I mean, I asked that question because like, I can see the value in that from a developer standpoint, like the migration path, but the OCD in me like fringes. When I think about having an API where you have all your CRUD actions and it's not, it's not using the same technology for all of them. Like the OCDME just is like, oh my God. 

SEAN_GROVE: Well, you can just think of it as another end point, right? You have like a bunch of little end points for your CRUD and you have one for the rest of it. 

AJ_O’NEAL: Wait, I'm confused. 

DAN_SHAPPIR: That's probably what it ends up being in any event. 

AIMEE_KNIGHT: It's true, but I don't want to add to the mess. 

CHARLES MAX_WOOD: Yeah, fair enough. 

AJ_O’NEAL: Like what? You've got your endpoints for your crud and then your endpoints for the rest of it. If you have your endpoints for the crud, don't you have the rest of it? 

SEAN_GROVE: Well, sorry for the though, you have all the existing, you know, rest stuff. And as you're incrementally migrating over, you can just think of the, the GraphQL endpoint is just one other graph, like one other endpoint. Oh, one other benefit that might be fun to talk about that we've been working on that I think will be good for the GraphQL community is Documentation. So one of the challenges, or I would say maybe negatives of the GraphQL culture is there's this idea that GraphQL is self-documenting because you can introspect a server and see all the fields that it has and you can get the documentation strings and whatnot. The idea is like, oh, well, the computer will do it for us, it's great. And so developers write less documentation than they really should. In particular examples. So my co-founder gave a great example of this. He was on the GraphQL team at Facebook and they had the like button. So whenever you click on the like button, it runs a mutation. And if you are a new hire at Facebook and you're trying to figure out, all right, well, how do I implement my own like mutation? And you search for like inside of the GraphQL schema at Facebook, you won't find one. The mutation is actually called UFI2 um, you know, reply or react feedback or something like that. And that's because, you know, Facebook has this, you know, beautiful, unified feedback interface or something like that. And so the, the model of what you're looking for isn't actually inside of the schema and that's where you really want to have human documentation that says, you know, if you are a user or if you're a developer and you're trying to add a like button, this is what you're going to have to do. And you give an example of a mutation. But the problem with docs is that there are lies, there are damn lies, and then there's API documentation. Documentation almost certainly, if it's written, it almost always falls out of date. It's a lot of work to keep documentation correct. And that's because documents are usually these blobs that are not computer introspectable. And so the suggestion we've been having is that inside of you know, your GitHub repository that defines your API, you can write, you know, examples and markdown anywhere. And what it'll do is it'll read all of the markdown files and extract any GraphQL code tag. And it will verify that the, every field selection and every argument inside of that example is actually valid against your current schema and it will fail the build, you know, every time you push, if you've removed or changed a field in a wasn't reflected in the documentation. So now the documentation will always be guaranteed to be a valid query. And then on top of that- 

AJ_O’NEAL: Well, if you have continuous integration. 

SEAN_GROVE: Oh yes, sorry. This is assuming that if you have some sort of build step and a nice continuous integration. 

DAN_SHAPPIR: Yeah, but it seems to me that the biggest challenge around documentation is that while the GraphQL reflection describes the syntax, the documentation is out there to describe the semantics, I guess. And, but the tests that you're describing are kind of still tests only of the syntax, not of the semantics. To actually test the semantics, I would actually need something like a test suite or something like that. 

SEAN_GROVE: Well, so the idea is kind of that you have, imagine that you're reading some markdown file that says how to create a new user, implement the signup mutation. And it says something like, you know, if you want to implement a signup mutation, you'll have to take care of these three things and et cetera, et cetera, et cetera. And here's an example of doing that. And developers, especially me, tend to gloss over all of the documentation. And I'll come back later if I need it, but I'll kind of copy and I jumped straight to the code, copy and paste it. And then I wonder why it didn't work because I didn't read any of the documentation. Um, and so I think just, you know, raising the bare minimum of saying, If you have some documentation that you've written, just making sure that all those examples will still function, and there won't be some error, like you've misspelled first, or you've misspelled some field name inside of the query, or you've changed the field, is still really, really valuable. And then on top of that, what you can do is actually bring that inside of, for example, a graphical. Going back to the original graphical that we're talking about, where one of the challenges is, you can search for a type. So for example, let's say, you know that there's a date of birth field somewhere in the API and you search and it says, here's a field, but you don't know necessarily how to traverse the graph and build up a graphical query that has that field, but if you've analyzed all of the examples inside of a repository, you know, all of the fields that are in there and all of the graphical types, so you can say, and here are all the examples that actually referenced this field and you click on any of them and it will automatically put it in. So it gives you a way of bringing those examples. So rather than existing inside of, for example, some documentation site, now they exist inside of graphical or even inside of VS code, right? Where I can actually get examples on how to use a field or I can search for us to create a user or like a post. And if someone has written that, it'll bring it in. And I know that that example is going to work. 

AJ_O’NEAL: So I I want to bring up another thing. I meant to say this earlier, so it's a little late, but another thing that's difficult about GraphQL when it comes to examples is, you know, when I, when I use a typical API, I can open up Chrome. I can open the dev tool. I can click on that tab and I see, you know, three or four requests. Every time I click on something, every time I perform an action, I see a URL. It's like slash users slash profile slash phone number say, or whatever, and I can click on it and I just see JSON, or maybe it's a post form field with a key value pair. But it's something very clear, very easy. GraphQL, you give that up. You get GraphiQL, and GraphiQL does that for you and makes that easy, but your Chrome developer tools become much more difficult to interpret because it's not JSON and it's not, and the URLs don't have any meaning slash graph QL. 

SEAN_GROVE: Yeah, it's a bit of a black hole, right? 

AJ_O’NEAL: I do know what's going on. Yeah. 

SEAN_GROVE: Along those lines, you're kind of talking about like sniffing an API, right? So you're not looking at the documentation, you're just using some web application and looking at the dev tools, yeah. So- 

AJ_O’NEAL: Yeah, which is like how I do it 90% of the time if it's available. Yeah, it's- Like I just click through and find out what I need to do just by clicking.

SEAN_GROVE: Yeah, I think it's not entirely unreasonable at all. Um, 

AJ_O’NEAL: actually, you as well. It's just not as easy to interpret it. Plus on GraphQL sites, normally there's like some, just by the nature of the site has nothing to do with graph, but usually the pinging once every second or you know, some sort of like web socket type thing going on. And so there's a million requests that have nothing to do with anything that's happening at all, like analytics. And I don't know, but it gets cloudy. 

SEAN_GROVE: Yeah, I think you might be talking about subscriptions, which are the kind of real-time feeds that come in over WebSockets. And yeah, that's definitely different. One thing we did, it felt a bit cheeky, so we haven't released it. So we built a graphical extension inside of the browser, and what it does is, it just monitors the web, it uses the Chrome web request API. And whenever it detects a GraphQL endpoints, like a request that's gone over, it just stores it. And then it just builds up a list of those inside of the little graphical, and it lights up. So you click the button and it says, here are all the graphical queries that were run. And you click on it and it gives you a graphical to explore it and to instruct the API. So it's kind of like, rather than graphical being the separate thing, it's like a graphical almost embedded inside of the application you're using. 

AJ_O’NEAL: But that's something that Angular's had and doesn't react to have one of those view has one of those. That sounds very reasonable. 

SEAN_GROVE: It is except that we often used it to discover, you know, which sites are using GraphQL that we didn't know that we're using GraphQL. Because one of the things we see is that, you know, GitHub, for example, has two GraphQL APIs. They have one internal and one public. And GitHub is amazing about, they're really good about how they implement their APIs. But a lot of sites don't do that, but they use GraphQL, but they still leave open the introspection query, even though they're not necessarily expecting you to use it. And that's, it's a little bit risky. So, I mean, for us it's interesting because, you know, we'll maybe poke around and see how they're, they design their scheme and whatnot. But yeah, we I feel always a little bit bad about doing that. 

DAN_SHAPPIR: The web was born to be view sourced. 

SEAN_GROVE: I suppose. Yeah. 

 

When I first started taking computer science classes in college, I thought programming was just a joke. In fact, I changed my major over to engineering and started doing computer engineering and chip design. Then I found Ruby and I fell in love. I love Ruby. It was my first real programming language where I dove deep and really learned how to make software that makes a difference for other people. Since then, and the way that we got started with devchat.tv, we started a show called Ruby Rogues. It's currently in the 400s of episodes. We've talked to hundreds of people in the Ruby community about the Ruby community, about the Ruby programming language, about Rails, and about what makes good programming. So if you're interested in Ruby Rogues, or you just want to hear a long series of experienced programmers talking about real problems, then go check out rubyrogues.com.

 

AJ_O’NEAL: It's undocumented APIs. It's not officially documented. So you're worried it might change or it might be. 

SEAN_GROVE: Yeah. For example, AMC theaters had a really, I think has a really extensive GraphQL API and you know, you can just open up graphical and connect to it and start, you know, you can purchase things and sign in and everything. You build your own app entirely off of that exposed API and there's no API documentation. There's no, they're not inviting you to use the API. Um, it's just, they, they left, you know, all the, um, the introspection, everything open, it's, it's probably fine. Uh, it just, it just feels, you know, a little bit, um, you know, they could get upset, I guess. 

AJ_O’NEAL: So do you, do you have like a custom version of graphical that you use? How, how do you do an authenticated request with graphical? Cause that's one of the things it's like, last I checked had been an open issue that was like open for as long as it's existed and the author is just like, man, whatever.

 

SEAN_GROVE: Yeah. So you think the, the challenge, it goes back to kind of your original question about, you know, authentication authorization is that, you know, right now it's still snowflake. Everyone does it differently. And, you know, 

AJ_O’NEAL: it's all through headers. Like everyone uses an HTTP header. There is no other way to do it. 

SEAN_GROVE: Yeah. 

AJ_O’NEAL: So it's not that different. Like maybe someone has JWT with different parameters than another person or someone uses an opaque token rather than JWT, but it's still you know, whether it's X authorization or API key or, you know, it's always a header, isn't it? 

SEAN_GROVE: Yeah. I mean, some people do it as a, as a query parameter or something like that, or, or, you know, they put it in the body as a variable. 

AJ_O’NEAL: Those are people that want to act in, want their users information to be exposed publicly on the internet. 

SEAN_GROVE: Yes. Okay. Yeah. So if we assume that, you know, everyone is doing it in a relatively, um, responsible manner, then yes, it would just be through a header. So the post-graph file actually has a little extension for GraphQL that just you click on it and you can edit the headers there and put in your token. What we did is we integrated, you know, so one graph by virtue of having to implement with all of these different services, we had to implement the OAuth flow for all of them. And so we normalized, you know, going back to that example of normalizing authentication issues. So we normalize it and whenever someone tries to query anything, we know that, oh, you're about to make a query into Stripe, for example, to get a list of your customers. And you're not authenticated with Stripe, so we'll send back a normalized error and our graphical will actually pop up a button that says log in with Stripe and you click on it and we'll handle the whole flow. It's a really nice experience. The question is kind of how to generalize it so that it would work with anyone's, you know. There's, there's basically a spectrum, right? You can use the post-graph file style where it's, you know, you just click the edit HTTP headers and you can paste in your stuff if you're, you're hardcore and you know, the exact headers that you want to be sending versus this, which is like a much more UI driven thing where the UI actually responds to you not being authenticated with the service and prompts you to, to log in automatically. 

AJ_O’NEAL: That is your custom version. That is not an open source. That's not the open source version of graph a thing that you specifically built for your experience. 

SEAN_GROVE: Yeah, I think that's right. It's not a thing that could be, I mean, anyone's could do it. I mean, it's something like, I don't know, maybe 10, 15 lines of code. But yeah, if someone doesn't do authentication in the same way that we do it, then they would have to write their own. 

AJ_O’NEAL: Well, that, like, if you could just put up a blog post about how you did that, that would be amazing because when I looked into this, that was one of the first snags I hit was I was, you know, doing a business API. So it was non public and just trying to get that like happy doing the freaking graph QL to work was so hard. And I would love to see, you know, if you've got a, uh, here we cloned the main source, the official one, or we cloned the one from post graph or whatever. And, and just, here's, here's where we inserted the 15 lines. That would be so awesome. I would love to see that.

 

SEAN_GROVE: Yeah, we actually have a post that I could put on how to do it with Apollo server and graphical. That'd be a good idea. 

AJ_O’NEAL: Yeah, include that in the show notes if you can. 

SEAN_GROVE: All right. Well, I need to push it, but yes, I'll do that. 

CHARLES MAX_WOOD: All right. Well, we're kind of getting toward the end of our time. Anything else that we should make sure we cover before we go to picks?

DAN_SHAPPIR: I don't know if we have time for that, but so we mentioned one issue with GraphQL, which was the authentication. And we mentioned another one, which was, you know, the transition and so forth. Another issue I think has to do with the length or duration of the queries that you can ask what seems to be like a really simple query, but ends up causing a humongous amount of work on the server. And especially if you're integrating content coming in from various sources, like the way that you do, you know, one might respond really quickly. The other one might take a longer time. The third one might even time out. So, so it seems to me that that's always, that's kind of the inherent challenges, isn't it? 

SEAN_GROVE: Yeah. So it's, there's a spectrum there, right? Where if you design for a very specific use case, then you can make sure that the API will probably be fine and it won't be, it's unlikely. If you assume that you have good users, like well-intentioned users, then it'll probably be fine. But then you limit the flexibility, right? So if you're, if you want to have an open API in a way that people can build experiences that you didn't necessarily foresee, then it's harder to embed performance inside of that. And it gets even worse when you assume that you don't have well-intentioned users. You might have someone who's trying to, you know, dos you trying to take down your server with incredibly complex queries. One way that this is handled commonly is with depth analysis. So GitHub, for example, scores each field that you select with a cost. So, you know, maybe you're getting a user, that's a cost of one. And if you're getting the first name of the user. That's also a cost of one. But if you get a list of the user's repositories, if you join on that, that's a multiplier of 10. So now you're at a cost of 30. And so they just kind of like, they do that same metadata annotation we talked about with authorization where they just annotate the, you know, at cost is 10. And then they run a basically pre-flight whenever they parse your query, they say, all right, well, what's the cost of this thing? And if it's above a million or whatever, then you can't actually run it. And so that's how they do that fine tuning. Another really good way to do it is with persistent queries, where, you know, at dev time, so this is how Twitter and TweetDeck do it, they have a graphical query that anyone can explore and do whatever they want, but during dev time. And once it is going to production, they'll do that analysis of it and then bake that query into the server. And so now it's like a unique end points, almost like a serverless function that only runs that one query and that cost is associated with it. And now no one can go in and edit that and add more expensive fields. So that way they, they know at any given time, what is the estimated cost for their application. And they know that users can't tweak it. They don't want to have a, you know, it's Twitter. They don't want to have a public API for all their users to be able to explore and pull data out. So that's one way to also do it, is through a kind of a lockdown where it's free for your developers and they can explore and do whatever they want. And they'll always be aware of the cost and they can choose to do it however expensive they want. But whenever it goes to production, it's locked down in a secure way. 

DAN_SHAPPIR: Cool, thanks. 

AJ_O’NEAL: And I think we should just peek into the can of worms just to know that it's there. 

SEAN_GROVE: So this was my suggestion. It's another thing I like. So reason is a programming language for the front-ends. It's a bit like TypeScript, but with a very strong type system and a really strong emphasis on building React applications. And also it integrates beautifully with GraphQL. So I have this example where. You know, I paste in a GraphQL query and I'm building out my Reason React component, and it just does this nice autocomplete and it handles every case. So Reason has this idea of exhaustive pattern matching, where in Apollo, for example, you have, you make a GraphQL query. Your query can be in three states, right? It could still be loading. The data hasn't actually come in. It could be error, you know, maybe it didn't work or it might have some data. And in JavaScript, it's really easy to, um, forget to check one of the states, right? You just immediately go in and you pull out, uh, you say, if it's loading, rendering of the loading, uh, tag, and if it has data, then pull out the data and render it in some nice way. And you forgot to handle errors. And you know, that's just because you're, you're busy and humans have a hard time checking every edge case possible in their, in their minds and with something like reason, it'll say, hey, actually, there were these three cases. What about this one? Uh, how do you handle that? And it's, it's also, it can miles down to very readable, um, JavaScript. So similar to a TypeScript where just, you know, it's, it's JavaScript with types and it just removes them at runtime. It can miles down to very readable JavaScript. So if someone on your team is afraid of, of reason, or doesn't, you know, want to get into it, they don't, they don't have to, they can still read the JavaScript and understand what's going on. Uh, that's the short pitch for it, but I could go on for about a length. 

DAN_SHAPPIR: So just one quick question about it. I know that you never actually need to debug functional strongly typed languages, but suppose you actually do need to debug your functional strongly typed program that you wrote in that language. How do you go about it? How pleasant an experience is it? 

SEAN_GROVE: Well, I think on the front end, it's not too bad because... So Reason, so I used to work on the ClosureScript compiler and it's compiling a dynamic list into JavaScript. And we did not care about what the JavaScript looked like. No one's meant to read that, they're supposed to read the ClosureScript part. Reason ML has this really weird emphasis where they want the JavaScript that comes out of Reason to look like handwritten JavaScript. And so what that means is now if you're, You can go inside of the source code, inside of the Chrome DevTools, and set a break point, and step through everything, and see all the data as it's flowing through, and use all the tools that you're used to, and then figure out what the issue was. In particular, we find that Reason has a strong emphasis on integrating with the NPM ecosystem. So Reason also comes out of the Facebook world. So again, incremental adoption. That means you can't rewrite the entire world in reason. You have to use the JavaScript packages if you really want to be able to ship this thing quickly. But that also means that you need to write some bindings, you need to know the data, and that's easy to get wrong, especially whenever library authors haven't really documented how their API works very well. And so that's where you'll really wanna be able to use those Chrome dev tools is to make sure whenever some bad data has come in through one of these libraries, you can go in and actually see what did it look like? What was the type actually supposed to be? And then pour that over into your recent code. So yeah, it's not an unreasonable question. 

CHARLES MAX_WOOD: All right. Well, we're out of time, so I'm going to push this into PIX. Amy, do you want to start us off with picks? 

AIMEE_KNIGHT: Yeah, I'm going to go with, because it's been a really long time since I did any kind of fitness-related post. This is just something I saw because I never really thought that this would happen to me, but it definitely does happen. And that is just kind of like pains in my wrist and stuff like that if work gets pretty busy. So this is just an article about some exercises you can do for your wrist if you're experiencing any pain to kind of try to like prevent that going. And I guess I'll also just pick cats in the lap because it's cold here and he's keeping me warm. That'll be it for me. 

CHARLES MAX_WOOD: Nice.AJ, what are your picks? 

AJ_O’NEAL: Okay, so at some point, Chuck, we gotta talk about what happens, like the thing. And for those that are not familiar with what happened, it is a rabbit hole a mile wide that is filled with conspiracy theories that I wouldn't have thought that I would have bought into if someone had just told me about it. But the rabbit hole just goes deep and the more I learn about it, the deeper it goes. And a place to start learning about quote what happened and what it started from and what's going on in the world is there's a documentary called The Grievance Studies Affair. And it's just, I don't know how to describe it other than an amoebic cult that is on the rise in America and Europe. And they're not nice people, at least not in groups. So that documentary, the Agreements Studies Affair, and there's other ones maybe I'll link to in future weeks. As far as, let's see, other more positive things to pick. One, I'm gonna pick Go, because basically every problem that we talked about in this episode, Go solves all problems. It's just phenomenal. And well, that's actually coloring it to it. It's just incredibly pragmatic. It doesn't integrate very well with GraphQL though. I, the GraphQL libraries that I was forced to use with Go where it put a bad taste in my mouth for GraphQL. I, the story is much better in JavaScript, but post-graph file was not, not anything to do with Go, but I remember ended up using that for some stuff and that was pretty nice. And then I feel like I want to pick something else, probably some music, but I don't know what to pick off the top of my head. Music in general. Music's great. I'll pick music, the whole thing, all of it, except the bad stuff. 

CHARLES MAX_WOOD: All right. Dan, do you have some picks for us? 

DAN_SHAPPIR: Yeah. First one, just want to mention it was funny how AJ instantly jumped from social issues to go and mentioning how go solves everything kind of made it sound like go can solve social issues. 

AJ_O’NEAL: It can, it can. If people would just subscribe to it like a religion, it would be the most unreligion like religion on the planet. It'd be people being kind to each other, being not judgmental, offering helpful solutions, finding the pragmatic path to a problem. 

DAN_SHAPPIR: You're describing computers, not people. Anyway, so my own, I have two picks of my own. So I just came back with the reason that you might not have heard me on recent JS Jabber episode is that first I've been to the conference of Chrome Dev Summit, which was actually excellent. And afterwards, our family went on this really excellent vacation. And I want to so pick one of the countries that we were at, actually the one that we were mostly at, which is Guatemala and it's just an amazing place. The combination of nature and the history and the people is just incredible and I super highly recommend for anybody who can do it to just go visit there. For our American listeners, the people in the US, for example, it's actually pretty close. It's just four or five hours flight depending on where you are and it's just an amazing place and I just can't recommend it highly enough. It was one of our best vacations ever. So that's pick number one. And I would love to give tips to anybody who's interested in going there. I would love to give tips about where to go, places to visit, what to see, etc. My other pick, so I've been working through various fantasy books that have kind of fallen by the wayside, even though they're awesome and excellent. So this week I want to pick a book called Tegana. Unlike very popular fantasy literature these days, it's just the single book, not a whole series of books. But even though it's just the one book, it's a pretty thick book, it manages to do quite an amazing bit of world-building. So you really immerse yourself in this imaginary world. It was written by Guy Gravel Kay. I hope I'm saying his name correctly. He was actually the guy that helped Christopher Tolkien edit and write up the Silmarillion. And he's written a whole bunch of fantasy books on his own. And this of his books that I've read, this is my favorite one. It's kind of based on Renaissance Italy. And it's just an awesome book. So I highly recommend it and and I'll put a link to to the entry for it on Wikipedia and Those are my picks. 

CHARLES MAX_WOOD: All right Did we have everyone do picks? I have a Yeah, all right, go ahead Sean. 

SEAN_GROVE: Yeah, I was out at reactive conf and frog and UK Lee gave a really cool talk In party is called breaking out of the box. And the idea was she dislikes being defined as a front-end engineer because she started to limit herself to thinking, well, if I'm a front end engineer, I really only know React and whatnot and maybe the backend stuff is too difficult for me and whatnot. And so her reaction to that was to basically go crazy and she wrote a Game Boy emulator in Rust and then compiled it down to WebAssembly to run in the browser. And the talk was about building that out. But my favorite part was the beginning of it was actually a, she showed a Pokemon ROM running and it turns out that her presentation software was, uh, org mode, she wrote some Emacs list that extracted the, uh, presentation from org mode, created some Jason and then injected that into a hacked Pokemon ROM. So inside of Emacs, she defined Pokemon towns and encounters and shops and whatnot. And she made it so that the Pokemon ROM was actually her walking around inside of Prague, going to the conference and getting up on stage and then giving a talk about writing a Game Boy emulator in Rust. And it was running inside of her Game Boy emulator written in Rust in the browser. And it was this lovely recursive strange loop. And it just made me giggle in a way that I, you know, it sparked some joy in programming in me. 

AJ_O’NEAL: My heart is melting. I must see this. 

CHARLES MAX_WOOD: Nice. 

AJ_O’NEAL: I'm absolutely, that's what I'm doing today. 

CHARLES MAX_WOOD: All right, well, I think this is gonna be the last week that I'm picking Christmas movies, just because I think we'll run out of time. So I'm gonna throw out a whole bunch. Some of these are some of the ones that I just remember as a kid watching. Um, like Santa Claus is coming to town or Rudolph the red nosed reindeer. Uh, there's the little drummer boy. They're all kind of the clay animation, stop motion, video movies. Um, frosty, the snowman, which is the, um, cartoon from 1968. And then, um, I have two more and I said that I wasn't going to pick anything newer than 1984 but I have one that I wanna pick that's newer than that, that's somewhat newer. So I'm gonna pick this one and then I'm gonna pick my very, very favorite Christmas movie. The movie that I'm gonna pick that's newer, it's actually from 2006, it's The Ultimate Gift. I don't know if you've all seen it, but yeah, there's this grandson, his grandfather dies, and all the other family members get inheritance and he basically gets a letter and he has to go do certain things in order to get his inheritance. And so anyway, it's one of those feel good movies, but it is a terrific movie. I really love it. So I'm going to pick that. And then the last one I'm going to pick, this is my very favorite Christmas movie. I watch it a couple of times every year and that's A Christmas Story. It's just so many good one liners. It's classic. So I watch it every year. Love it. We usually watch it on Christmas Eve while Santa's putting out presents for the kiddos. So, yeah, so those are my picks. And yeah, that's pretty much all I've got there. Thanks for coming, Sean. 

SEAN_GROVE: Thank you for having me. This was a lot of fun. 

CHARLES MAX_WOOD: Yeah, it was fun. And I'm looking forward to it. I think we're talking to you tomorrow on React Roundup, so. 

SEAN_GROVE: Yep. So we'll make that happen. 

CHARLES MAX_WOOD: And then, yeah, we'll have to have you come back and talk to us about Reason ML.

SEAN_GROVE: Yeah, happy to. 

CHARLES MAX_WOOD: All right, folks. Well, I'm going to go ahead and wrap the show up. We'll have another one next week. And in the meantime, Max out. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y.com to learn more.