Coding Blocks - 3factor app – Realtime GraphQL

Episode Date: September 17, 2019

We begin to twitch as we review the first factor of Hasura's 3factor app, Realtime GraphQL, while Allen gets distrac ... SQUIRREL!, Michael might own some bell bottoms, and Joe is stuck with cobalt.

You're listening to Coding Blocks, episode 115. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And we've got a website up at codingblocks.net where you can find show notes, examples, discussion, and a lot more. Send your feedback, questions, and rants to comments at codingblocks.net. Follow us on Twitter at Coding Blocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood.

I'm Joe Zak. And I'm Michael Outlaw. This episode is sponsored by Datadog, the monitoring platform for cloud-scale infrastructure and applications, applications and the O'Reilly software architecture conference. The only conference that focuses exclusively on software architecture and the evolution of being a software architect and educative.io level up your coding skills quickly and efficiently, whether you're just starting preparing for an interview or just looking to grow your skillset. All right. preparing for an interview, or just looking to grow your skill set.

All right. And in this episode, we're going to be talking about factor number one in depth of the three factor app. So before we do that, as we always do, let's go ahead and get into some podcast news. Yeah. And first up, big thank you to the iTunes reviews. We got ZJ, who farted, not me,

Marcus Johansson, this just 10, a 50 cat and runs with scissors. So thank you very much. We really appreciate those. I'm pretty sure that's supposed to be pronounced this just 10. That's it. Yeah.

Like Justin. Justin. Yeah. Yeah. Runs with scissors is amazing. That, that might be my favorite so far. Oh, really? That was the one that got you a laugh?

Yeah, yeah. I'm partial to ZJ. I mean, the Who Farted Not Me was good too, but Runs with Scissors, that's just amazing. I have the visual. All right. And from Stitcher, we have Whatta Did and Uncle Scooter. Both good also. Yes. uncle scooter. Both good. Also.

Yes. Squirrel. There might be a bit of that tonight. So, uh, also, um, I think we mentioned this last time, but,

we've got, uh, the video confirmed now for sure up on YouTube that, uh, Zach did for us, uh, walking us through, uh,

Vim. So, uh, thank you very much, Zach Overflow. I just noticed you're a YouTuber. It's good. I'm subscribing to that channel. It's great. So just a heads up, this might be changing. If this particular video isn't there, whenever you listen to this, we'll probably have an updated URL in the future. Because I think Zach said that he might also go in and edit to clean it up. But I mean, I've already listened to at least 10 minutes of it and I thought it was excellent. Like the flow of it was awesome. Got a history. I'll probably just leave this one in there. If he gives us a, an updated one, I'll add that in a future one. But I mean, we'll just leave this one.

Totally good though. I mean, I hated it that I had to stop at 10 minutes, but, um, excellent. You guys attended it live, right? Yeah. Yeah. We were both there live and it was really good stuff. So definitely if you want to pick up some VI or VIM knowledge, definitely worth your time to give that a view. All right. And with that, I guess let's go ahead and jump into the topic. And we're going to talk about the three-factor app. So we've done the 12-factor app. Yeah, I was going to say, does this remind you of like a scene out of something about Mary? You know, like, why have the 12-factor app when you can have the three-factor?

No. Right? What's he saying? I don't remember, man. And that's definitely like what makes me think of it, though. It's like, yeah, we can one-up the 12-factor. So the next one will be the two-factor app. That'll be coming after this series.

Or it's just the one-factor. I just wanted to kind of recap. We talked about the 12-factor in depth over a couple episodes. But basically, kind of the gist of that was uh it's kind of a devops perspective of like infrastructure so we talked about like declarative formats for setup augmentation augmentation automation that was good yeah how you could figure applications what to do with logs um portability deployments things like that um different so uh scaling i very much saw that as being like very DevOps oriented. And so when I thought three-factor app,

I thought it was going to be kind of evolution of that, but it was actually kind of went in a different direction. Yeah, this one's going to be fun. I think everybody listening, hopefully you'll get something good out of this. So I think what we should first do is kind of call out who this is done by. So when we first, the website obviously will be one of the links that we have here.

But it's all, it's a very small website and it's written by the people who own has surah.io. So it's interesting. It's their take on the three factor app. So this is very much a sort of like a specific set of criteria to do this. So the first thing let's do, they're talking about modern architecture. And these three factors are, it needs to be able to do high feature velocity, meaning being able to add features quickly, right?

And it should be scalable from the very get-go. And to do this, what they're basically saying the pieces are is you need real-time GraphQL, reliable eventing, and async serverless functions, basically. So those are the three factors. In this episode, we're only going to be talking about the very first one, which is GraphQL, because it's big enough on its own. Yeah, and so I guess we're going to dive in.

I'm so tempted to jump ahead on this one. I'm going to try and stick to the notes here. But what I kind of got to take away, so I mentioned TotalFactors is kind of about DevOps and kind of moving towards microservices and like a cloudy world. And this one, I kind of thought, boiled down to basically having an API gateway,

in this case GraphQL, storing your state in something like a distributed store. So, you know, we'll talk about that too. And having services that interact with that state via an event system. And you notice that the direction I went there was API state and then services, which is a kind of an inversion of how I normally used to think about kind of web applications, which is basically like a website would talk over REST to an API, which would then interact in a database. So you notice in this case, I kind of had that data layer second. So API gateway, database, and then services. And that's a that's an interesting twist there that we're going to dive into and be talking about a lot.

But I think it's really interesting. It's got some really interesting use cases that we found on the website. Yeah, so like one of the ones they called out was Uber for Access order track. It's highly asynchronous. So like when you do an order, I don't have it in front of me right now, but, you know, it's got to be verified. The payment has to be processed. You know, you have to actually set up the order. You have to track it. Like there's all these pieces that need to happen. Like they even seem like seeing the cars around you as they're driving around. And then the order goes into the people, the people, someone has to kind of pick up that order and say, I'll take it.

It has to confirm. You can watch that car come and pick you up on the map. Like there's just a lot of events moving around. And this application setup is specifically good for that sort of thing. Yep. The next one was personalized recommendations. Yep. And again, they kind of mentioned the asynchronous operations and near real-time results because apparently I've never built anything like this, but a big part of kind of personalized recommendations as you're like shopping along is that you want to take in a person's behavior and what they're looking at in order to show them better ads essentially, try to guide them to the things they're looking for now

and not just based on their past history. So some of those operations are kind of slow. So if you've got a big system that takes a couple seconds and you want to kind of show this stuff, you want to pop it into the search results or you want to kind of suggest it as they're going along, then the subscription type services and some of those asynchronous calls that this architecture makes easy is a really good setup for that. Yep.

Next one up we have were chatbots. And again, it's those async events. That's kind of a big recurring theme here. That ties into microservices. And they mentioned some other things, just some nice features around like WebSockets and whatnot that kind of tie in nicely with this architecture.

And then the last one we got here is real-time analytics. Yeah, and that's Alan's favorite topic. So we're definitely going to be using a couple of examples around that. But it all boils down to the same kind of thing. We've got asynchronous events, we've got subscriptions, we've got data that needs to be updating on the screen as we're browsing.

So there's definitely certain types of apps there that are reflected. They all have got real-time stuff going on. They've all got kind of these multifaceted kind of moving pieces all going on. And they kind of don't fit into that traditional submit the form, wait for the response kind of use cases that a lot of apps are still built around. I got a list of related technologies here. So these are things that I kind of associate with these ideas typically. And these are things that we'll see either echoes of in this architecture or just flat out included in. So WebSockets mentioned a few times there.

It's a nice way of kind of streaming data back and forth. It's really efficient. Lambda, Kappa, and streaming architectures. That's something we should talk about on a future show. Those are kind of heavyweight, like big kind of enterprise-y architectural patterns for doing certain types of like real-time streaming applications that are kind of associated with things like Uber very often, real-time analytics. So I think those are all really exciting.

Well, it's more about how you could scale it, right? Like some of those features that you're talking about there. And when you say Lambda, I'm assuming you're talking about like AWS Lambda, right? That's what I assumed. No. Okay, you're not. you're talking about the lambda architecture yeah so actually i should add another note here because that is also those like kind of serverless functions are also a technology that's closely associated with this uh so let me add this in here to notes but uh when i talk about lambda architectures um they're i think they're not as popular maybe as they used to be.

But it's kind of like if you're familiar with Apache Spark where you've got streaming data that needs to be fast in real time. But you've also got like these bounded data jobs, things that need to happen kind of in batch. And so Lambda was like this pattern for basically processing fast analytics and slow analytics kind of at the same time and then bringing that together. But that's kind of fallen out of favor a little bit in favor of something like a kappa architecture, which is, I don't know, is that like a Greek letter? Is that the next letter to the alphabet or something? Probably. I couldn't tell you exactly.

I sound like a moron right now. I don't know my Greek alphabet. Or what, Latin? I don't know. I don't even know what language this is. But the idea is that Kappa is a bit of an evolution that drops those batch jobs and says, why don't you just make your streaming architecture better

and faster, and then you can handle both situations with one architecture rather than kind of duplicating logic against these two types of jobs. But either way, like, Lambda and Kappa are closely associated with, like, streaming architecture, so things like Flink or Spark or Kafka is really the main one that I'm familiar with. All right.

I'm glad I asked that then because I assumed you were talking about Lambda. Yeah, the way it was written out there, I thought that it was like three of these. So Lambda and Kappa are the two types of streaming architectures that we're we're talking about here so lambda also applied to batch there from what i'm seeing yes lamb is but like what he said so lambda is batch oriented kappa is more like kafka streams um that kind of thing where like every time data comes in it automatically responds and does something with it yeah land does that too but it's it's kind of both it's kind of it seems strange to me i've never worked with the lambda architecture and there's like lambda, but it's kind of both. It seems strange to me. I've never worked with the Lambda architecture. There's LambdaConf, and there's a couple things that are kind of built around it.

But yeah, it's got those bounded jobs where the batch things, where you've got a set of data that needs to process, and you've got it working in connection with streaming. And what people are saying as tools kind of evolved and things like Kafka started to kind of eat in the world, said, why don't we just stream everything and then throw the batch stuff in there too?

Like why not just treat it like streaming data, even if it's bounded, we'll just kill the topic afterwards. Yeah. I mean, according like just basing this off of what little I've seen so far of it from the Wikipedia. Right.

So like, you know, a whole bunch of knowledge over here, but yeah, I mean, they're saying that like it, they're taking the Lambda takes the advantage of both batch and stream processing methods right and kappa simplified that by only focusing on the streaming is the difference between the two okay cool and nowadays actually um so you started

seeing stuff about landos and i started people saying like now we're done with landa kappa's the way and now i feel like I've seen more people in YouTube videos and, like, talks from conferences talking about just streaming architecture. So it seems like they're kind of getting away from whatever language that is. I know some people are screaming at their phones right now. I'm sorry. I don't know. Is that French?

I don't know. All right. So then you also have event-based architectures in here. Yeah, and so I can't really think of any event-based, like examples other than the ones I just kind of talked about right there. But, you know, I kind of associate it with like service buses and stuff, but you don't really hear too much about that. I think that's kind of gone the way of the dodo a little bit

in favor of things like that Lambda Kappa streaming. And I also got microservices here, which is kind of, you know, hot topic. Sort of. That's also an interesting thing because when you start talking about streaming, and, you know, I don't even know if all our audience knows even what we're talking about when we say streaming and all that kind of stuff, right? So maybe we define that a little bit is, you know, in the old days, if you imagine that you have a database and you need to get analytics

or run reports for, for your sales people, right? A lot of times what they do is they run that at night in a batch process, right? And then that way the next morning when their sales folks got in, they could look and see, Hey,

what customers do I need to go talk to? Right? Like that kind of thing. Yeah. And it's really interesting. Um, so like, you know,

we, we talked about that kind of like old school, submit the form, update the database, come back like, uh, and you know typically or a couple years ago phone was talking about streaming they were talking about things like sensors like temperature sensors or like real-time data like people walk into the store and it sets off a message and the message gets processed but like as things have gone on more and more and like cloud uh architectures of have uh kind of gotten better and better people are treating more and more data as if it were streaming.

They're saying, you know what? We've gotten faster. We've gotten better. We trust our cues. We trust our data to come in and be in the right order. And we figured out how to deal with the situation when it's not or it's bad. Like, why don't we just treat more and more things like it's streaming and use these tools that we've been building up and maturing things like Kafka to do more stuff with that and just treat those old school things like

placing an order for an Uber, treat that as streaming data instead of an old transactional kind of acid type thing. And that's why we've seen like apps like Uber coming into popularity now and more and more people expecting those kind of experiences from the applications they deal with. Yeah. So like, I guess going back to that sales report, like when you start talking about streaming instead of, hey, your data will be ready tomorrow morning, the whole idea with streaming is as new data comes in for whatever customers that these salespeople might have, those reports are being updated real time, right? Because as soon as that data comes in, then it goes through whatever process is sitting there waiting for it and updating it one at a time, right?

Like as fast as it possibly can. And the reason why it's called streaming is you can scale this thing out, right? Like if your worker gets bogged down, start up another one, right? Now you got two of these things working on the same chunk of data coming in and i want to say like probably the one that the use case that almost every streaming thing touches on when you start looking at streaming is twitter right twitter has data coming in non-stop and they used to call it like the fire hose right like if you wanted to subscribe to the main twitter stream it was the fire, the thing is, could you batch process that stuff? It'd never get done, right?

So they actually needed to go to a method where it was like, hey, as data comes in, we need to do stuff with it right then. We can't wait. So that's the difference. When we're talking about streaming, it's handling data as soon as it gets in, creating any kind of aggregations or reports or anything. That should all happen near real time. Well, I mean, from what I learned, there was this really good talk called Real-Time Data with Kafka Streams.

You know, this guy, Alan, he gave this talk. Right. I don't know if you saw it at the Atlanta Code Camp. Hopefully. But I guess the old school way of that batch process that you're saying is you would run that select statement and you would just get back all the records that were there at that time. Right. Whereas in the streaming approach, you run your, quote, select statement, and it returns back the records that are available then, but it's still hanging, waiting for new records to come in. And as soon as those records do come in, then you get those as well. And it'll keep waiting for as long as you let it. It's like a live running query is kind of what is kind of what streaming is, right? Like

instead of, Hey, let me select what's in my table right now. That's, I know it's a fixed set of data instead of that. It's like your select statements just constantly running. Right. And every time something new comes in, it picks it up like, and it does whatever it needs to do with it. And, and honestly, it's really cool. Right.

It's very much like, it seems like it very much has its roots in cues, but with the added capabilities on top of it that you could like filter things and join things so it's like it's like it mixed the worlds of q of q's with sequel like you know capabilities that's the k sequel he's talking about specifically in terms of like kafka streams and and it does like it allows you to do some pretty complex things rather easily, which is super cool. So that's a fair point.

So maybe when we talk about streaming architectures, not all streaming architectures are going to necessarily have some kind of SQL-like capability. Right. It's definitely something cool to check out. Back in the day, I used to write a lot of sales reports where I would give them a little form, and they could set the date range and the types of products they were into. And they would hit enter, and they'd see a report that showed everything sold that month. And people would use the crap out of that stuff.

But now when you kind of think about how that pivots and how that is framed in the streaming world, you're thinking about dashboards that show like real time data. And so now if there is a spike in sales for a certain item, the salespeople can see that immediately because the dashboard makes it very obvious that something odd is happening and they can go in and say, oh, crap, we missed the zero on this product or something, you know, isn't selling that they would expect to or if the number of orders drops, that's stuff that you can react to immediately now rather than running that sales report on monday this is just all evidence that our society has become like just too impatient we can't we can't wait for tomorrow that dashboard widget needs to like update right now it is crazy but when you think about it like another example use case of this is like um something with with self driving cars and that kind of stuff now right like that data is coming in and it's having to constantly readjust to it.

Right. And I'm, you know, there's machine learning algorithms and stuff that are running on it, models and all that. And I'm sure that's all getting fed up to servers too, to where it's like, Hey, what was the right thing? What was the wrong thing? Whatever. So like as more data needs to be more real time because we're relying on our technology more like this stuff is getting more and more important so um so here's where it gets to on on the main page on the three factor app page they actually started off with the old school i'll call it food ordering application

and what's funny is their old school one was rather new school. So I needed to back it up and make up the real old, old school. So, so the old school food ordering application, typically like if you've worked in databases, like Joe, you said a minute ago, right? Like you usually think of a database and API and a front end, right? Like, so in that world, your application makes a call to an API, right? Maybe it's REST. Maybe it's just web service method type based type stuff, whatever. Then that API makes calls to mangled spaghetti code that exists that will then place the order. It will confirm the payment and it will set up delivery. That's all going to happen somewhere in that application, right?

And then the API is going to call the database to save the state of that stuff. And then after all that's done, then it's going to return back to the user and say, hey, I'm done, and give it some information, right? So that, to me, is what probably a lot of people are familiar with. Yeah, that's normal to me. You know, I got kind of curious because um you you were talking about like all the data that was flowing in everything and i was like oh you know we've talked about these kind of stats before in the past where it was like you know how many youtube videos per minute or whatever but you know those kind of numbers are always like interesting to me and so it's kind of like

uh you know because of how much data is being generated, you could like imagine like, oh, well, this is why the evolution of streaming architectures had to happen. Right. And so I found this interesting article. I'll share a link to, but I just, some of the highlights in here was just that, you know, going back just five years ago. And then this article was updated as of June of this year. Right. So as of five years ago, there were 2.4 billion internet users. That number as of June had risen to 4.4 billion, right?

So an 83% increase in the number of internet users on there. So you can see like, you know, going back to your Twitter example of like just how much stuff is happening, you know, as a result. So check this out. Seeing as how you did that, I wanted to look up how many tweets are there per second.

Okay, I've got the per minute number, but okay. They said roughly 6,000 per second. All right. In a day, that equates to, let me count the number of commas here. One, two. That is 518,400,000 tweets a day. That is a lot of tweeting. You know, I've watched a YouTube video specifically about Twitter's architecture. First of all, it's amazing that that video exists and there's multiple of them. But they actually have a couple different use cases that are really interesting.

Like one is like the Taylor Swift has 30 million followers or probably like 30 billion followers. Like that's an entirely different use case from the average, which is someone who just mainly reads and probably doesn't have a lot of followers and probably doesn't tweet that often. And so if you've got a thousand followers and you tweet, that's not such a hard engineering problem. You can solve it one way. If you've got 30 million, then you kind of need to solve it a whole other way. So they've got kind of this two-split brain kind of thing going on where if it's one situation, they go this way. If it's another, they go another. It's all really interesting.

I learned the term fan out, which I'm dying to use in a conversation. I guess I just missed my opportunity. Dang it. I mean, yeah, we've gone over these kind of numbers before. It was like the number of Facebook posts shared each minute has increased 22% since 2013, right? There are 510,000 comments posted every minute on Facebook. Golly. 293,000 statuses are updated and 136,000 photos are uploaded.

That is melting the polar ice caps. That is, that's why. Yeah, because we got to cool those data centers. That's right. Taylor Swift has 84.6 million and one. Why don't we have that? Followed. I don't get it. Hey, maybe if we sing more. Oh, you know, it's funny.

If you follow, you can see who else in your friends list that you're following follows them. You're already following them. Paul, I'm calling you out. Go chair Paul. Wait, what? I see you. Go chair Paul. That's awesome. But truly, I do love Taylor Swift, though.

Hey, so one thing that came up before the show that I think we need to address here, and it's not probably the elephant in the room, but rest, right? We throw that term around, and I think it's worth somewhat defining it, right? Just so that people have an idea of what REST even means. It's that thing that you do instead of sleep. Golly. Right? If only. You just get some REST, but you got to move on.

So usually, and I'm not going to give any kind of definition off the web. Like this is just from years of maybe doing it wrong. If you want. Yeah, you totally can. Um, but like rest is typically like web requests or HTTP requests using verbs. Right. So you're going to have gets updates, puts,

deletes, et cetera. And typically you're supposed to adhere to those things. Pretty hardcore. Right. So like, let's say some pretty strict rules too. Right.

Right. So if you have something like a person in point that needs to be, that needs to have things, if you want to get people, then you're going to make a get request to my API slash people or person, right? And you might pass in some parameters in the URL string. If you want to update a person, then it's typically going to be something like my API slash person slash the ID. And then you're going to have post params that went with it. Right. And and put versus update or no way put and post are two different things.

Like I think put is a create post is an update delete. Again, it's going to be like slash person slash ID. And that's going to be deleting a very specific person. Like there are all these very hard rules that are around it, but it's so it's easy for people to reason about what's going on. Now there's some reasons why people don't choose to use that. And it's because some things are a pain in the butt, right? Like if you need to, if you need to get back a set of people and you have a complex search type thing, it usually doesn't play well with the REST world, right? Like maybe you need to post some data. Well, technically you're not supposed to do that, right?

Yeah, posting stuff when you want to get data is like the number one violation of REST. That and not returning URIs to like other resources of your REST API. No one ever does that. Right. And I totally forgot about that when you're actually supposed to return the URI so that you can go get other information to do things like whether you want to update or delete what it's just, there's a ton of rules around it. Right. And I never realized that it actually stood for something. I don't remember what it stands for. Representational State Transfer? Wow.

Pulled that one out. Did he get it? Not bad for me looking up like an hour ago. All right. Very nice. Yeah, I don't know that I ever thought about it, but yeah. Yeah, I'm so used to don't know that I ever thought about it, but yeah. Yeah. I'm so used to just associating with, with web services that whenever I read about graphical,

not being a rest service, I'm like, wait, what do you mean? It's not like, how are they doing it? Of course that's rest, but it's just cause it's become a synonym to any sort of HTTP request.

And that's not actually the case. Like rest has a very specific definition that everyone ignores. Right. And, and there's another one that a lot of people that I don't think is as popular, but is probably more powerful is I think it's called OData. And it's just gnarly. Like if you look at it, it's extremely, extremely powerful in what you can do, but it is incredibly hard to read and understand, but you can basically do anything you want to do with it, right? Like it's like web API requests on steroids, right?

Like they've thought about almost every feature, but it is also ugly and sort of a pain to work with. Didn't – like REST was the answer to SOAP though. I mean talk about Marley, right? Like SOAP was way worse. SOAP was so dirty. But you could generate your client for it. See what you did there? Yeah.

But it solved a lot of the same problems. Like, the URIs were supposed to help with discovery, which is kind of what SOAP did with, like, WSDLs and stuff. And so there was good things about it. And REST is still, like, it just kind of took over the world. Like, people don't even think about web services versus REST anymore. You just kind of think of, like, I ask for data, you know, via a URL and I get some data back. Yep. Now, one thing I want to call out before we wrap up on this rest thing here is, again, it's usually per entity, right? So you're going to have an API endpoint for,

let's just take our thing that we always do with like orders, right? You're going to have a customer endpoint. You're going to have an order endpoint. You're going to have an order endpoint. You're going to have a payment endpoint, right? There's going to be endpoints for each one of these things. So think about it. If you're writing a C sharp app, then you're going to have, you know, three C sharp files for your controllers for each one of those. Or if it's a node app or whatever, you kind of get the point, right?

Like you're setting up a separate endpoint for each one of these things. So you might have like, you know, a slash API slash customer slash some ID number. Yes. And then that, you know, and if you were to use the get verb for that, then you would retrieve back a customer at that ID. If you were to use a delete verb for that then you would why would you allow them to delete a customer i don't know but maybe you did it was a logical delete it didn't actually yeah truly well i think about like if you want to pull up like an order page you buy something from a from an e-commerce site and you pull up the order you click on the order id on the their admin page under your account and then it goes out and it does a rest

request and says get me that order for order one two four seven that order has a customer id you say go get me that customer for one two three that's how we get the names we say hello you know joe here's your order then we say okay now we've got your list of products let's go out and get information on each of those products and so that if you're doing things strict and like the strict REST, like whatever, HATIOS, like format, like that's a lot of web service calls that you're making from either your service on your API layer or you're doing

it from the front end, which is kind of crazy when you think about how much work goes into essentially getting one thing. And so people usually, I don't want to say usually, but a lot of people end up building these purpose-built endpoints called like get order details where you pass in the order ID and it just returns all that stuff. It'll do a SQL query or whatever. It'll take care of whatever details to get that thing in one chunk for you.

Hey, so let's walk through that example because you said a whole bunch of them. Let's just talk about it, right? You're on the customer page. It's going to make a web request to get customer information. Then there was an order that was supposed to be there. It's going to make a web request, a REST request to go get customer information. Then there was an order that was, that was supposed to be, there's going to make a web request, a rest request to go get that order. Then it's probably going to make a rest request to get the order details. So the line items, and then it's probably going to make another rest request to go get the actual details about those order line items,

right? Like what was the product? What was the description? So you've got up to four separate requests that are happening there. If you were to just follow the true rest format, but then what Joe was saying is typically what people do is they're like, man, we don't want that, right? Like we just want to be able to make one call. And so now you've got some, some custom thing that you've written out there. That's get customer order details, right? And it's going to return you back everything. But here's the things to keep in mind with all that's in a generous version too that right you could have you could have you could definitely envision a world where for uh privacy and security related concerns for example uh the the shipping address and the

customer's address and the customer's name, those could all be separate calls. And, you know, in order to see that it all goes together so that, you know, someone who works in the shipping department can't immediately see that like, you know, oh, this person bought flowers for that person and they shouldn't have. Right. So that kind of information might be not obscure isn't the word I'm looking for. It's broken up. It's basically separated. Separated. Right. Yeah. word I'm looking for. It's broken up. It's basically separated, separated. Right. But so

here's the other important takeaway from this is typically in your rest API endpoints is if you have a person endpoint or a customer endpoint, when you call that and you say, give me the customer information for customer one, you're going to get back this blob of data for customer one, right? Like you're going to get their customer name, their address, whatever else comes on, right? Same thing with the orders. You're going to get a set of fields, whether you need them or not. Right. You're going to get those back, right?

And when you create that custom endpoint, get customer order details, you're also getting back everything you need there. Now, what happens when Joe needed customer order details? Now I need a customer order details, but I need a little bit of extra information, right? What typically happens is they're either going to go create another end point method. That's basically going to be a copy and paste of the other one, plus some additional stuff, or they're just going to modify his intact that stuff stuff on there so now one of the two of us is getting more than what we need right so that's kind of the the typical world that most people live in and we're painting this picture we have two very similar end points to maintain yes which means that if you ever change one you likely have to change the other one maybe

maybe that's the thing you don't know is. Is it accidental duplication? Right, right. So, so we're painting this whole picture because it's going to lay out the awesomeness that we're going to describe here in just a little bit. So, so we went through, we talked about the database one and how that typically works. Now they went with the more generous old school food ordering.

We've gone through the very old school. Now we're into the old school. So it's not even old school, right? Like the other one we said is actually what happens most of the time. So then there's this more optimistic version of what happens in this food ordering application. That's the application makes a call to an API. The API makes a call to the database. And it's also making an API call to the payment microservice, the order microservice, and the delivery microservice. All kind of at the same time. I mean, if you've got microservices, come on, man.

If you're calling your microservices old school. Right, that's what I'm saying. You don't live around here, I'll tell you that much. That's not optimistic. But, I mean, we've talked about microservices in the past. And the thing is, they require a lot of prethought, right? Like how do you make these things either stateless or work to where they don't require each other to function, right? So that's why we say this is – it happens, right?

Like this isn't something that's made up, but it's definitely probably not the norm as they sort of called it out on the page. All right. So now we get into their version of how this would work. And it's a little bit longer. So I'm hoping that this will paint the picture. So the three factor app food ordering application, the application calls a real time GraphQL API. The application calls a real-time GraphQL API. The application gets instant feedback. So as soon as you posted something to it, you're going to get a response back. The application then subscribes to a GraphQL API endpoint for feedback when the state store operation is complete, right? So picture you placed an order. As soon as you hit that submit button, you're going to get some feedback saying, hey, we've submitted your order, right? Now you're going to subscribe to a GraphQL

API endpoint. That's basically going to keep waiting for this thing to come back and say, Hey, the order has processed life is good. And as soon as that happens, it's going to come back to your API or to your, to your UI. Now behind the scenes, what's going to happen is GraphQL is going to call the state store. That's a database. It could be a distributed thing. It could be Mongo. It could be Postgres. It could be whatever, right? So it's going to call your state store. The state store is going to store something. It's going to start emitting events. These events then get handled by these serverless functions, right? So if you're thinking AWS, it could be an AWS Lambda. It could be an Azure function. It thinking AWS, it could be an AWS Lambda,

it could be an Azure function, it could be an OpenFast, right? It could be any number of things, but more or less what's happening is it goes out and calls something, that stuff is going to do some work, and then it's going to write back to the state store, right? Once that state store gets its notification, it's going to notify GraphQL that graph QL that you subscribe to from the UI for the real time updates is then going to send that notice back to UI. And you're going to get this message that says, Hey, order number one,

two, three has been placed and you didn't have to do any polling or anything for it. Right. It all just kind of happens. So I don't know. Did that paint the picture? All right.

You ever order a pizza from Domino's and it sings to you? No. Well, not sings to me, but I've definitely seen where their UI, you can watch it where they'll say, hey, we're putting it in the oven now. And you can see the little progress bar will move and they'll be like,

okay, we've just pulled it out of the oven. We've put it in a box. It's in the car. It's being driven. You can of the oven we put it in a box it's in the car it's being driven like you know you can see like the various states as it's going through that's cool oh man outlaw this this should be my tip but i'm gonna give you this one for free okay it was pizza hut pizza hut you can choose how they'll like tell you about your notifications and they have an 80s like hair metal motif oh gosh so it'll sing to you when it changes state so it'll be like your order is in the oven it's it's pretty awesome i want to go order a pizza now just so i can see it yeah i

can't eat it though i guess i could like scrape all the meat and cheese off of the bread no that's the best part you can feed it to the rest of us man that's fine yeah well i don't who needs those carbs man not me yeah that's the same kind of thing can feed it to the rest of us, man. That's fine. Who needs those carbs, man? Not me. Yeah, that's the same kind of thing where like the UI is basically subscribe to event and we've got something like a web socket or it'll fall back to, you know, whatever older technologies, long polling or whatever. And whenever that the state gets updated and matches message gets sent, your UI reflects that change and you don't have to be doing any sort of crazy antics on the UI. That stuff is kind of built into GraphQL's capabilities. And so not only are you able to easily interact with and fetch data, we're going to get into details here,

but you can fetch data with GraphQL and place your order view in GraphQL, but you can also subscribe to these events. So when that state changes, you can react to that in the UI. And the UI isn't sitting there hung waiting. You can still click around. You can add additional items. You can do, you know, play Tetris or whatever, whatever you want to do. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications.

Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. Head to www.datadog.com slash codingblocks to see how Datadog can provide real-time visibility into your application. Again, that's www.datadog.com slash codingblocks to sign up today. All right.

So we talked about all the stuff that exists in the today world. And if you haven't gone into the GraphQL world and all that, this factor one of this three-factor app, now it's time to talk about the why. Well, it's also the yesterday world. The yesterday world, yes, the yesterday and today world. Because I don't know that a ton of people, I mean, there's plenty of people that have gotten behind GraphQL, but there's probably way more people that just keep working their job in the same old stuff that they've always done, right? Yeah, I was going to question, like, graph QL has been out for a minute though.

Right. It has. It has. And it's gained a lot of functionality even since the last time I looked at it, like even things like pagination and whatnot, like they figured out some things there that are kind of nice. So,

um, but let's jump into it here. So, so again, factor number one for this real time graph GraphQL three-factor app is use real-time GraphQL as that data API layer. And so they said it must be low latency. And to them, that means less than 100 milliseconds in a response, right? So fast.

They said that's ideal. Worst case, it should be less than one second. And they have a link that I thought was pretty cool to a Stack Overflow thing to where they talk about where people start losing focus and interest and all that kind of stuff. Right. Like this is stuff that kind of Google has talked about over years and whatnot. But it was pretty good. And the next thing they say is it must support subscriptions. Now, this is something I didn't know about GraphQL. And I feel like either it was new or I just never got far enough into it. But GraphQL actually has subscriptions, which is really cool. And basically what that means is it allows the application to consume information from GraphQL API in real time.

You see, this is the part that keeps throwing me is like they're talking about real-time GraphQL. And I'm like, okay, is this quote real-time GraphQL? Is that new? Or is that just me? Because like every GraphQL conversation I've ever had or heard, because I've been to several talks on the subject, maybe I just missed something. But I never heard reference to that before. I hadn't either. I think what they're referring to is, I mean, behind the scenes, more than likely, it's probably using something like WebSockets, like what Joe mentioned earlier.

But it's just the ability to subscribe to something and say, hey, as soon as you have the data ready, give it to me, right? Like, don't make me go poll every 15 seconds to find out if something's ready. Tell me when it's ready. So I think that's what they're referring to here. And it might be something they've just dubbed for this three-factor app. I just looked it up in the spec because I missed the same thing too. Like every presentation I've ever seen on GraphQL kind of emphasized basically the web service-y type aspects.

Like they didn't even talk so much about updates. I didn't even know you could make updates. I was so used to just getting data. Google and I found it as part of the original spec. It looks like that part of the spec is still in flux a little bit. They're still kind of ironing some things out. It's noted as a draft here.

But it's really cool. They got a lot of information up here in GitHub. Man, I want to spend some more time with GraphQL. I promise you, every time I revisit this topic, I'm reminded how awesome it is. So let's go ahead and press on here. So some comparisons to a typical backend API call, right? So a traditional uses REST calls. We already went over that pretty in depth as to what that means, right?

Like a separate endpoint for everything. And they always come back with the same data. The factor one uses GraphQL API. So instead of a REST endpoint, GraphQL. So now I haven't dug into the implementation details, but I'm pretty sure the GraphQL API just does post requests to one endpoint, and then you get your data back from it. So they don't care about REST, right?

They just care about you submitting what you want and then getting what you want back. Yeah, which sounds like a web service to me. So that's why we spent some time up front there to talk about what REST really means. When people say GraphQL isn't REST, they're specifically talking about those kind of rules that a lot of people ignore anyway. Right. Just because when you said factor one,

we're talking about factor one of the three factor app. Like it might be more clear if we just said like the free, the three factor app uses GraphQL. Okay. Yeah. Fair enough. Okay. So the next one up is in the traditional sense,

you may require multiple calls to retrieve all the data. We talked about that. You get the customer, the order, the order details, et cetera, right? Or write a custom one-off method that will give you back everything you need. Hey, in the three-factor app approach, when you use GraphQL, you tell it the data you want. You tell it exactly what you want, and that's exactly what you get back. Right. So none of these make four or five calls. It's one call and you give it the shape of what you want and then it gives it back.

I mean, for those who've never seen any GraphQL conversations or presentations before, like imagine it is like the client is getting to describe the query that it wants ran. So instead of the backend server is going to execute some SQL query, for example, and you're going to get whatever it returns. Instead, you're able to shape that request from the client side and only get back the things that you asked for. And when he says shape, he truly means it. Like the reason it's called GraphQL is because you're building a data graph. So your request might be like customer, bracket, order, bracket, order details. And your data that comes back will be customer with that information. And then there'll be a dot order with that information and then a dot order details,

right? Like it's going to be shaped exactly how you told it that you wanted it. So the next one that I thought was kind of interesting, and we've even talked about this in the past is probably even a tip of the week is in the traditional way of doing things with a rest endpoint or even, even just, you know, web service type endpoints, you'll use something like swagger or swashbuckle to generate your API documentation, which is really cool. But in the three factor app approach,

GraphQL actually generate all that documentation and that schema information for you. Yeah. And what's really nice is there's graphical tools that will do things like, you know, offer like strong typing typing and code completion, documentation built all right into the tool. And you can do stuff like that because it knows everything about all the inputs and all the outputs. Yep.

We should probably remove Swashbuckle from the note. Because it's.NET. Well, no, no, no. Because Swashbuckle does do the automation. So I don't want to confuse everything, right? Oh, okay. Swashbuckle does do the automation. So I don't want to confuse everything, right? Oh, okay. Swashbuckle automates Swagger for you. So it'll create documentation with like,

here's what this endpoint looks like. Here's what this endpoint takes in as parameters. And also, hey, here's a thing where you can test this and experiment with this API, right? It does that kind of stuff for you. So Swashbuckle will really kind of blur that line if you're not already familiar with it and graph QL. Okay.

So just talk about swagger is just a way of documenting your APIs, but it would be, you know, you, it'd be up to you to manually do that, implement that, implement swagger. That makes sense.

All right. And then in traditional for real-time type stuff, you'd have to set up your own WebSockets types. And that may not sound bad, but it could be a decent amount of work, right? If you're using.NET, you've got SignalR, which is a library that kind of does it all for you, which is nice. It's pretty amazing. But it's a decent amount of work.

In the three-factor app approach, if you use GraphQL, it supports it natively on the server side for you. So you don't really have to wire up anything special to make that happen. So, you know, again, just less work to do it. So the next part is the major benefits of GraphQL, right? So in this one, I absolutely agree with this one. It massively accelerates front-end development speed because developers can get the data they want without having to build additional APIs. So assuming you set up all the relationships in the schema on the server side, all front end dev has to do is issue the query they want to get the data, right? And if they realize that, oh man,

instead of just customer name, I also need the customer phone number on this page, they can issue that query. They don't have to go and develop another method on the backend or modify anything on the backend to make that happen. They just make that query in GraphQL. This is where some of it gets confusing, though, for me, as someone who does lack practical GraphQL experience. I guess that assumes, though, that you have something that's already set up to return that data somehow yes because this graph ql implementation is going to like sit on top of all those other calls yes so then you know it's kind of misleading to say oh well you decided you wanted middle name as part of the customer information that's returned so all you got to do is just tell it that that's the shape and you automatically get

it. Well, if there's already a call that supports that. So a lot of this is, it's not a, there's a call that supports it. No, actually. So that's, that's where things are a little bit different. So you set up a schema. So let's say that on, on your server side, you say that, let's just do person for ease, right? You have first name, middle name, last name, right? You define those three things on a person. What we're saying is,

assuming you have set up the schema and that stuff for GraphQL on the server side, if initially the front end person went and said, hey, I only need the first name on here, right? They make that query. It's all fine. Tomorrow, they need first and middle name. Assuming you have that set up on the server, nothing else has to change. The person on the front end side can just say, hey, give me the middle name also. Right. That's my point, though, is that you set that up on the server side. Yeah. So you already set up that mapping. Yes. So it had to exist. Yes. And that's where it almost feels a little bit like every every, you know, going to have to go modify that existing endpoint that was getting that person information back and say, hey, put middle name into the return set and make sure it's in the query.

So you're having to wire it all the way up, right? Like you're basically having to say, okay, now when I return that person, I need first name, middle name. You got to modify that, let's say, in our C sharp, right? And then that's going to get returned down to the client. Well, tomorrow, if they need last name also, guess what? You got to go modify that C sharp file again, modify that method and say, give me, give me first middle and last name. What we're saying that that is not misleading is assuming that you set up the schema on person to have first middle and last. If that, if that front end person requests his first name, cool. You don't have to do anything.

If they request middle name next, they don't have to do anything. Yeah, that part I get. Yeah. But yes, it does have to be set up. That's the key. Probably the one main takeaway that everybody needs to realize when you start talking about GraphQL is it almost means that you have to be mature enough in your product to have set up a relational data model that, that you can describe on the server side. Yeah. You have to. Okay. Right. Okay. So I'm glad you said this. You have to have already decided what it is that, what is the world of things that you might want period. Yes. And those things have to have already be established and already be mapped out on your server side. And on your client side then you can be you know free willy like whatever you want to pick right like you know uh and oh yeah i decided i need i need no name because

you've already you had previously already decided that that's a thing that should be you know something that could be returned totally But if you decide that you need something brand new and there doesn't already exist that return, that's my point where it's a little bit misleading because it's not like you just get to, on the client side, be like, oh yeah, and I also want your mother's maiden name. Right.

Like, no, no, no. You have to set up that mapping. Just like you would have had to do in the previous rest world or any other soap or wisdom or whatever. But what you get out of that, though, is very massively different. Let's say that age is the next thing that you need. So age didn't exist on the server side. So now you got to go plumb it in.

Guess what? Everybody now gets the benefit of that. Not just that one call. Yes. A fair point. Very, very fair point. Yeah, and we talked about code generation maybe an episode, two, three back. This is a great example where people have gone and built tools

that will take a database or a list of tables and will go through Introspect and generate that schema and make that available at the front end. Same thing for file systems. There's GraphQL providers for file systems that give you access to things like everything in certain directories and the modify times and create times. And what I was doing with findtech.events

was using GraphQL and it was going through Postgres and was doing basically just that. And so I could type any field that was in the database and it was all strongly typed and I got auto-completion too on the tool. So I couldn't query for a field that wasn't in my schema because it wasn't going to parse the query. It was going to say, I don't know about this field.

You're going to have to do something. You're going to have to go at it or you're going to have to regenerate your schema. And so the tooling around this stuff is really maturing right now and makes a lot of this stuff a lot easier. But that's because in your scenario though, you were literally exposing every column of every table, right?

You had some tool that was automatically doing that mapping for you. But in a real – well, I hate to call your app not a real-world application. Yeah, man. What the heck? Yeah. Well, this got awkward fast. You're fired.

Yeah, your toy app is fine, sir. No. In a traditional business application, there's going to be some fields that you're not going to want to return back. Like picture, okay, we were already talking about like e-commerce examples, even, well, that's always our go-to,

but even at the beginning, right? There's going to be like credentials like to log in that you're probably not going to want to return. Right. So you're not going to want to just go through and blindly map every column of every table. But I think it is worth mentioning, though, a lot of times and it doesn't have to be this way. So you can handcraft your own GraphQL schema to stitch together models and stuff on the server side. But a lot of times I would venture to say what people probably do is like if we're talking about a dot net world, you're probably going to take something like entity framework that does exactly what Joe said. It'll take a look at your database, find all the relationships, build your object relational model in C sharp.

And then it's so easy to overlay GraphQL on top of that because you've already got your model built out, right? Like I think there's even, I think there's even tools that will generate the schema to wrap the entity framework code that's been written. Okay. I feel like we got to take a moment though, to back up because now we're mixing the use of the word model. And before maybe I mistakenly took it to mean like a domain model no but now we're talking about a model as in like the schema yeah yeah like a table schema yes could be a quote model definitely was not talking about a domain model earlier it's it's definitely more of a relational model between objects see i was thinking of domain models

when we were talking about being mature enough to go ahead and map out everything, the world of everything that you want to have returned. I was thinking of domain models. They could be domain objects. See, that's the beauty of GraphQL is you can make it do whatever you want. You can make it look at whatever you want. It does not – it's kind of loosey-goosey in that nature. Like you can wrap

kind of anything. And we'll talk about some of that here in a little bit. But so I just wanted to point out like what Joe said, where he had it going to Postgres, like a lot of times you'll use tools to generate that stuff for you. Right? Yeah. I want to point out too, like whitelisting, blacklisting are definitely your friends. You don't necessarily want to expose everything. And I feel like whenever I talk to people about GraphQL, if they're a front-end dev, they're like, yeah, let's do it. This is awesome.

This is amazing. I don't have to bug you whenever I need something. Whenever I talk to a back-end developer, they're always like, whoa, whoa, whoa. What about security? What about, you know, you generate this thing. You can type 12 lines here and it's easy on the front end. Great, but you just executed nine queries in the back end

without even realizing the sort of load that you're under. And there's, you know, mitigations for stuff like that that you can see those things being queried you can log it you can take a look you can use purpose-built stuff you can kind of cheat the rules but also you know you'd like the entity framework is a great example where like with any framework you can kind of chain together these c shark calls with like where clauses and aggregates and group bys and it doesn't execute that query until it you basically need to you know render it you need to do like a to list or something and there are tools out there that are smarter about how they generate queries too so while if you generate graphql over a series of

rest endpoints that are strict it might end up executing nine calls and that would be terrible it may also depending on what tool you're using and how you put things together, be smart enough to put that query together in like abstract syntax tree and actually execute that in a more efficient manner. But it's still scary. And I think that people still kind of figure out exactly what the problems are and how to mitigate that stuff. And so it's something that, you know, like you shouldn't just go run out there and generate your whole database and expose it to your client. But it's something worth considering. Yeah, totally. And I mean, there's even solutions for that kind of stuff too, right? Like there's caching and all that. So yeah, the thing is, you know, as with anything, it's not like it's a silver bullet, right? Like there's going to be

some things that you have to take into consideration, especially if you have a massive amount of data, right? Like, you know, how does this stuff work? So, but REST API in front of your GraphQL API, which then operates on your other REST API. Which by the way, you can do, like you can totally do that, right? Like, so one of the things that I've got it further down, but I think it's worth mentioning is like, we've talked about the Star Wars API before, right?

The Swappy is what they call it. There's a GraphL implementation of that thing. That's, that's what it does. The schema, the graph QL schema is written and behind the scenes, it's calling rest endpoints and then stitches that data together and brings it back. Right? So it's not like it has to be a relational database. You could be calling rest endpoints. You could be calling a database. You could be calling all kinds of stuff. So, um, that's why I say it's like, it's, it's an open sort of standard that you can do what you want with. One of the other things that, so another major benefit is GraphQL APIs are strongly typed.

You know, it can require string and integer and enum, things like that, right? You can even specify objects that need to have a type. You don't need to maintain additional documentation tools, like we said, has real-time built-in natively, and prevents over-fetching. So this is what I was talking. I don't know how true this one is. It depends on what's underneath it. Right.

But at least to the client, like if you're only getting the person's first name and then all their order details, like you don't need to fetch select star from person table, which has, you know, 40 other fields that you're not even displaying. In this case, you tell GraphQL all it needs is the person's name and it's responsible for only getting that back. But like we talked about, depending on what calls are happening in those resolvers, you know, like maybe it is selecting star but only returning that to the front end. So maybe you're only really saving the bandwidth and the message size there and still doing all that work. Or if you've got a smarter GraphQL endpoint, then maybe it is doing something better with that data. Which could be – I mean you're almost like belittling that point though with the bandwidth. But I mean, if you're talking about like a mobile app, and it's like, take Uber, for example, and you're wanting to see the cars move around in real time, you know, that's a lot of communication back and forth. So you you want the payloads to be lightweight. That's a good point.

In that example. So, you know, the bandwidth between the server, your API server, and that database server, you know, might be a big fat pipe and it could handle it. It'd be fine if it's getting back a little bit more than what it needed. But that payload going back to the client might need to be really small. Yeah. And like what Joe was saying, I think just to drive it home here, it's up to the developer to handle how that works. Right. So when he said, you know, behind the scenes,

it might be doing a select star, but then what gets returned to the client is just first name and last name. If you're going to take in a GraphQL query and you see that, hey, they only asked for first name and last name, you could, as a developer, implement that to where you pass that along somehow to whatever is querying that data and say, hey, only get first name and last name. Don't get the rest of it. Right. But it could easily be doing a select store and then just filtering it down for it comes back down to the client.

I mean, you could very easily see that already happening, you know, be impossible in a world today without graph QO. Yeah, totally. You know, like if you have a home brew repository, you know, and you want to get some some model object back and it you know under the covers it's doing a select star but you really want like three fields out of it and you know so i i don't i don't know that i consider that necessarily like a a not a dig at graphql but you know like a problem like you know because the thing that they're talking, I think, when they talk about that prevents overfetching, is what's being returned back to the client, not necessarily what's staying on the server side.

What's happening behind the scenes, right? Right. This episode is sponsored by the O'Reilly Software Architecture Conference. The O'Reilly Software Architecture Conference is coming to Berlin November 4th through the 7th. The O'Reilly Software Architecture Conference is the only conference that focuses exclusively on software architecture and the evolution of that role. This conference is in the weeds with tech and covers complex topics from microservices and serverless to domain-driven design and application architecture. The Software Architecture Conference features different styles of learning from 50-minute sessions to two-day training courses. The Software Architecture Conference also focuses on soft skills. O'Reilly knows that architects are

having to communicate complex technical topics, and their merit compassionately to both upper management and technical teams. This conference is here to help you navigate different communication styles, like in their two-day training, the Architectural Elevator. O'Reilly knows how siloed software architecture can feel. The Software Architecture Conference offers countless networking opportunities so that you can meet people who are working on the same tech as you and can offer personal experience and learnings that you can apply to your own work. Many of the attendees are either aspiring software architects or doing the work of a software architect without the title. The conference offers a special networking experience called Architectural Katas, where you get to practice being software architects. Attendees break up into small groups and work together on a project that needs development. Software architecture will be co-located with the Velocity conference

this year, which presents an excellent opportunity to increase your cloud native systems expertise. Get access to all of Velocity's keynotes and sessions on Wednesday and Thursday in addition to your software architecture pass access for just 445 euros. Listeners to Coding Blocks can get 20% off most passes to software architecture when you use the code BLOCKS during registration. We're at that point in the show now where if you haven't already, we ask that you leave us a review and we greatly appreciate it. You can find some helpful links at www.codingblocks.net slash review. And with that, we head into my favorite portion of the show.

Survey says. All right. So back in episode 112, we, what native language are you most interested in? And your choices were Rust, because safety first. Or Go, because I want to be fast and parallel. Or C, the old ways are best. Or C++, the good parts. Or, no thanks. I have deadlines. And lastly,

you forgot mine. You expletives. All right. So, uh, Joe, you're up, I think. So you go first.

This is a tough one. Um, you know, part of me wants to go with whatever one I think is hottest. So I would say like rust or Go is definitely cooler. But also, I think there's still a lot of interest in C. So I'm going to go with C. How much?

30%. C at 30%. All right. So I'm way less optimistic on this one. Only because I think most everybody's like there ain't no way. No thanks. I have deadlines. I'm going to go with 40%.

Okay. I have Joe with C at I already forgot 30%. Yep. And Alan with no thanks at 40%. Yep. And Alan with no thanks at 40%. Yep.

You both missed it. I'm sorry, guys. Really? Let's go. Well, okay. So, Alan, you got the answer, but you overshot. Okay. You got a little too optimistic.

Or pessimistic. Depending on how you want to look at it. There you go again. Right. So what was it? 33%? No. No Thanks I Have Deadlines was the top choice at 24% of the vote.

Oh, so it was spread out all over then. Yeah. I mean, it was, you know, Go go go was second okay that's the one i would have chosen if i was being an optimist that was 22 so right away i mean that's almost 50 of the vote right there uh-huh right what was next uh okay so so it went no thanks go c plus plus nice all right rust c and you forgot mine. Don't nobody love C. Yeah, I was kind of surprised to see C was like so far behind because it's still so relevant.

Yeah. Nobody wants to use it. I thought it was kind of hipster cool. Like it's like so old it's new again or something. I write my own flavor of Linux. Yeah. No. But maybe now that's where c++ has come

back around now it's the new hipster cool it's so old it's cool again maybe yeah it's the bell bottoms of the uh languages nice yeah well all right i don't know if i'm gonna support that that took an awkward turn bell bottoms oh you I mean, maybe they'll come back again. They did for a minute there. Did they? Yeah, I don't remember when. Did they really? I didn't have them, but, you know.

I saw Outlaw wearing them. Some out. Some out. Okay, wait. Show of hands. Who has a feeling that Alan has some bellbottoms in his closet? I don't know that I've ever worn any. Based off of what you said, I'm not going to be surprised.

Hey, you better watch out. That picture of you in bellb and bell bottoms about to show up never never happened that would be one heck of a good photoshop right there i was born wearing cargo shorts so it's not me yeah i love cargo shorts uh okay. All right. Well, all right. So then for this episode survey, we ask, would you be interested in doing a CodingBlocks fantasy football league? Sports ball. All right.

So your choices are, how has this not been a thing for six years? Yes. Or sports ball. Please. No. Or a fantasy game for soccer. Silly Americans. I don't know that we could do it this year.

If we get a lot of response back, I mean, maybe we could start one up in the middle of the year. That would be kind of fun. So drop them comments quick. Yeah, get them in there. Get them in there fast. So half of a fantasy football league. Yeah, you know, whatever. This episode is sponsored by Educative.io.

Every developer knows that being a developer means constantly learning. New frameworks, languages, patterns, and practices. But there's so many resources out there. Where should you go? Meet Educative.io. Educative.io is a browser-based learning environment allowing you to jump right in and learn as quickly as possible without needing to set up and configure your local environment. The courses are full of interactive exercises and playgrounds that are not only super visual, but more importantly, they're engaging. And the text-based courses allow you to easily skim the course back and forth like a book. No need to scrub through hours of video to get to the parts

you care about. Amazingly, all of the courses have free trials and a 30-day return policy, so there's no risk. You should try a course or a track today, like Become a Machine Learning Engineer, which is a new learning track consisting of five machine learning courses. It focuses on practical machine learning skills that you can get a job in the industry as soon as you're through. No abstract theoretical stuff. You can get plenty of practice as you go through the courses in the interactive environments. The courses are valued at $335, but the track only costs $199 as a bundle, but you can get a further 20% off. So about $160 if you go through our special link at educative.io slash coding blocks. Start learning today by going to educative.io slash codingblocks. Start learning today by going to educative.io slash codingblocks.

That's educative, E-D-U-C-A-T-I-V-E dot I-O slash codingblocks and get 20% off any course. All right, so now that you've heard about some of the bits of GraphQL, we're going to talk a little bit more deep about some of the actual parts of it so that you'll kind of have a better understanding of what it is and what it would mean to get involved with it. So first off, from the GraphQL page itself,

it says GraphQL is a query language for your API. I love that. That's exactly what it is. It isn't tied to any particular database or storage engine. It's backed by your existing code and data. That's the important part. You can kind of wrap it around anything. Which, like you mentioned before, could be some other REST API. REST APIs. It could be file system stuff. It could be anything you want. You literally wrap it around your existing code.

And this is the important part. Like we said, you shape your data. Queries are all about asking for specific fields on objects. The shape of your query will match the shape of the results. Like I said, customer order, customer order details. You're going to get that same graph back of what you requested. Well, I want to be more clear in that example. Like it could be in that shape that you're describing, it could be customer, and then

orders could be like an array, and then inside of each one of those orders that come back, it could have an array of line items, which you're calling order details. Well, actually, no, we could be more specific than that because the detail might include

a shipping address, it can include billing information, and then it can include an array of the line items. And to paint an even better picture, you might have, all right, customer, give me name, give me, I don't know, rewards points. Okay. And then under that, give me orders. And on the order, I want the date it was ordered and the total amount that was ordered. And then for each one of those, give me the product name, the quantity, et cetera.

Right? So very specific things, not just blanket saying like, I want all of the order details. Because it doesn't even work like that. Right. When you want to get back order details, you have to tell it what parts of the order detail you want. Right. And so. You can't star either.

Right. It's not part of the spec to be able to say, give me everything. Right. You have to tell it the fields that you want on each entity. And so that's the thing that's really powerful here is you can limit it to exactly what you want. Nothing more, nothing less. Yeah. is you can limit it to exactly what you want. Nothing more, nothing less. Yeah, and there are allowances too for things like filtering and sorting. So you could say like, give me the customer the last 10 orders.

It's going to be up to the specs to kind of build that stuff in because there's different use cases that they're trying to support there. So that's kind of been some of my frustration. Sometimes the filter will be filter, and here's how you pass it. Sometimes it's called where and it's passed a little bit differently. And so that's going to be up to the implementer. But for the most part,

it's pretty amazing that I'm frustrated that querying Postgres and querying SQL Server, depending on my plugin, requires me to use a different word. Oh, drats. Right. Yeah. So these queries also allow for traversing relationships,

as we just mentioned with the customers and the orders. So you can get everything you need in one request. Now, as was mentioned earlier by, I think both Joe and Outlaw three different queries. Or if it was smart enough with something like, like you said, an abstract syntax tree that, that stitches it all together and issues one query, it could be, it all depends on how somebody implemented it on the backend. Right. But from the client's perspective,

the person who's making these requests, it looks like one, one call. You think about, um, like how many admin screens you've built in your life where it shows a list of customers and maybe who have customer service calls in the queue or something and it shows some information. And then the customer service person says, wouldn't it be nice if it showed their lifetime order value? Or wouldn't it be nice to show their phone number right there? Wouldn't it be nice to? Wouldn't it be nice to? And some of that stuff is

information. So you have to say, well, how do you want me to do that? You want me to do some sort of stuff on the different addresses or, you know, getting that stuff in SQL is a pain in the butt. But if you've got this set up, then suddenly it's like, okay, well, let me just add a new field to the UI. Right. Yeah, and you handle it however you want, right? Because, I mean, honestly, it's kind of easy to do things in JavaScript or whatever you're trying to do. If you're just trying to manipulate data that comes back, you can format it however you want, right? It's a lot easier to do that than it is to hobble together some sort of SQL query that's doing that behind the scenes.

It's not like that lowering of the battery. We mentioned customer service was like, hey, it'd be really nice to get the data to the last order. And you say, wait, the last one or the last 10? What's more useful to you? They're like, what? This is so amazing. Let's hire GraphQL. Right, right.

It'll be done in 15 minutes. Thank you. Sorry, I think I just drifted in my own half fantasy there. The other half's coming on the back end of this. All right, so here's the other thing. So like Joe just said,

you can pass in filters, right? You can pass in these other things. So every single field and nested object has its own set of arguments that could be passed. So for instance, if you have a customer, you might pass in customer ID is a type of thing you could do. You might have customer name as an argument that could be passed to find the customers. Right. Um, but then the orders, you might have an order number or you might have an order amount that you could pass in or an order date.

Right. So each one of those fields has different arguments that you can pass in. And again, that's up to the implementer on the backend that says, Hey, these are the things you're allowed to query by. Right. Does it have a-in date formatting?

Not formatting. I think that's something you've got to do yourself. Okay. I'll deal with that. I think it'll pass. So that's actually – we'll get into that here in a minute. So I doubt it, and I'll tell you why in a minute. So, again, I think we'll get into the types here in a second. So we'll skip that.

Here's one of the things that's really cool. And you don't think about it until you go to do something. You're like, oh man, I really need this to happen. You have the ability to alias fields. So in queries, you do this all the time, right? Like maybe, maybe you'll see the Not for Joe Zach, you don't. Not for Joe Zach, you don't. He hates this. But, but like if you have an order, right, like, it might have been created by Outlaw but updated by Allen because, you know, I work in the customer service department. He's the customer that ordered it, right?

So he created it. I modified it. Well, those two users are probably in the same table, right? Like, there's a user's table. Typically what you'd say is, hey, select star or select something from orders, join users. Let's alias it as created and give me outlaws information from the user table. Now join users again on modified to an alias it modified so that we can get Alan's information, right? Well, you kind of need to be able to do the same thing in GraphQL. If I return it, if I return that order, then I want to say, hey,

give me the created by person and give me the modified by person so you can alias it. Both of them are a person, but I can alias one as the created by and alias the other as the modified by. So you have that ability in GraphQL. Makes a lot of sense. It would kind of almost be useless without it. We kind of touched on the Star Wars example, but played in these two movies that, uh, were took place on Tatooine or rather give me the movies that took place on Tatooine or whatever. And it will kind of go pull that information back.

And as a front end user, that's amazing. You know, that's like six lines, you don't have to mess with the backend. And then, yeah, I just think that's amazing.

Do we have the link for that in the show notes anywhere? Uh, for what?? The Star Wars API? Yeah, we're going to. Yeah, it's on there. Yeah, you should go play with that. Swappy SW API. I think that's the best introduction to GraphQL that anyone could ever have. It's really cool, and they wrap REST

APIs. Now it's all in Node.js, so if that's not your cup of tea, then I'm sorry, but at least it's a way to get familiar with it. Well, because if all you're caring about at this point is just playing around with the client side to see how the queries are formed and to explore the documentation that's created from it, then you shouldn't care what the server side is right now. Just go play with it, and then you'll be sold, and then you'll want to GraphQL all the things. Also, JavaScript won the war anyway, so the sooner the better. That's so cool. Give it the program.

All right, so the next thing that I think is pretty cool is a feature called Fragments. So what that really allows you to do is it allows you to sort of templatize your query so that you can reuse it. So imagine you have something that says, hey, give me an actor, give me the movies they were in, then give me like what planet it was on, whatever, right? Like this whole complicated nested graph that you have. Well, you need two of them, right? You need one for Luke Skywalker and you need one for Han Solo. You don't want to have to type that stuff out twice, right? You don't want it in there twice. So you can templatize what that return chunk will be, what that graph of data is that you want. And then you can just use it sort of like a, like an alias, like say, Hey, use this and pass this in. So it's a way to simplify your queries. You set up the, the one big chunk and then you just reuse it. It's kind of like calling a function

in any kind of programming language, sort of. So I have a little chunk of code in there. I'm not going to read it because it will bore you to tears. I trust this is super cool. It is cool. All right. And then, of course, this is all great, right? Like this is all hard coded queries. That's what we all do, right? Like we hard code everything in the UI. No, not so much. So there's the ability, the ability to use variables. So when you create this fragment, right? Like you say that you want Han Solo, right? Well, you can pass in his, his name and get information out, right? Cause it's a variable that it'll take in and then it can go retrieve the information based off that variable. That was really big for Gatsby, by the way. You would frequently do something like

take in the page name and pass that in as a parameter, you know, like your slug to whatever, look up whatever information you needed. Yeah. I mean, think about it. Any kind of form that you ever do, right? Like you have a dropdown that says, you know, give me this or that. Well, whatever that dropdown value is, is probably needs to be an input into the query to go get the data. So yeah, I mean, in any kind of real programming, you're going to need this feature. So the operations, and this is where Joe was surprised by something. I was also surprised by something because I knew about two of them. I didn't know about a third. All right. So there's three types of operations

supported in GraphQL. There's the query, which is how you get data, right? This is putting in your request. Mutation, this is how you modify data. I missed that completely. Yeah. The mutation is amazing. We'll get into some things with it here in a minute. And then there's subscription, which I didn't know about, which was this whole idea that, hey, I want to wait for GraphQL to tell me when some data updated, right? And it can push that two, by the way. Yeah, I didn't know, man. So that could push it down to you. I thought it was cool just with the query.

Right? Dude, that's actually the part that I kind of lost my mind about a year ago or whenever we first talked about this. So, yeah, I mean, amazing stuff here. So a few things that it sort of tells you, like this is kind of, some of these are best practices. Some of them are, you have to do it in some cases. So like providing an operation name. So they say it's not required. So for instance, you can just plug in a query and say, you know, give me the customer order information, like I said, right? But it's smart if you give it a name

upfront and say, Hey, get customer order information. And in some cases it has to happen. So if you're doing a multi-operation document, then you have to do it. But if you're just doing a regular query, you don't, but why would you want to? Because you can debug it. If you do that, it kind of passes through the GraphQL server side stuff. So if you need to log anything, you can kind of see where problems happen. And if you just had an anonymous query come in, much like an anonymous function in C Sharp or in JavaScript, it's a lot harder to troubleshoot.

That's a good point. Yeah, so it gives you the debugging and server side tracing. So that's all good. The queries are typically going to be dynamic. Like I said, it's not like you're hard coding everything on the page. So your queries also support variables. We talked about the fragments earlier do your queries do. And it's kind of interesting. So the way it's done is you'll define your variables in the query. So like dollar, you know, username, right? And then after the initial query request,

then you'll have another sort of like JSON looking block that has the variable values that get passed in. So it's like two separate chunks. There's your query chunk and then the variables that get passed in chunk. There are some cool things here. So the variables, they support scalars, they support enums. So if you have a list

of things or object inputs, and those have to be typed and available on the server. One of the cool things is these variables and types can be optional or required, which is really nice because I mean, it's another one of those things that probably they created this thing. And then afterwards they're like, Oh wait, we need this feature, right? So if you put an exclamation mark at the end of a variable or even a type in some cases, then it makes it required. And you can also do default values. So directives, you can use variables, you can shape the results of the query. Maybe you have like a dropdown on form. This is like show order details and you can use variables, you can shape the results of a query. Maybe you have like a drop-down on form, this is like show order details, and you can say yes, no, and this is what kind of lets you pop that stuff in or pop that out without having to do a bunch of like string building.

Now, mutations is the part that I have not messed with yet, and I was really surprised to hear because I just always associated so much with querying. But this is what allows for modifying data. So if you're talking about that Uber example or ordering a pizza is where you would place that order. And it does say, unlike GraphQL queries, which basically happen kind of all at once

comes back, the mutations do happen one at a time, which I thought was interesting. I guess if you hit that place order button three one at a time, which I thought was interesting. You know, I guess if you hit that place order button three times in a row, you want to make sure you get three orders, not just one. Well, I actually know that they're even taking it a step further.

So if you have in one query, if you say, I don't know, update or create order and then also update the rewards, right, for the customer, it actually makes sure that the first mutation completes successfully before it runs the second one so it's cool so it's all in one one request is basically what it's getting to um it's almost like it's acting as like a a promise like you're chaining together promises right but. But this one's done, then do the next one. Yeah. Like a dot, then dot, then.

Yep. Exactly like that. So whereas the queries, if you have multiple things, if you have multiple results sets that you wanted in a query, they're all happening at the same time and it just returns it back when it can. But how do you,

okay. But so that's great that you can ensure that it's going to do one after the other. But in terms of the whole ACID capabilities, if it was being done inside of one transaction on the server side, then it could be an all or nothing. But now we're not in this particular scenario that you've described, like you're losing that. So I guess the point is, is like, you might want to be careful about how you would do that or what use cases you might do that in. Right. If you needed, if you needed an acid type transaction, then my guess is you would pass everything in one mutation request and an object graph. Right. Yeah. Yeah. That's exactly. Yep exactly yep you know and you said a moment ago like uh

like when they create this thing when you were talking about like the the variables uh section i don't know that we ever defined who created this oh yeah kind of like a big that's kind of like a big talking point well we'll get there when we talk about the criticisms. Oh yeah. Yeah. Okay. Yeah. We'll do that. Fair enough. So one of the really cool things about mutations, I was telling Joe about this earlier is you can issue the mutation, right? Like, like I want to create an order for Joe Zach, right? But after that order is created,

I also want to get back the order number and all the other information. You can issue all that in the same request, right? So you have your mutation and then you also have the graph of data that you want to come back after it's done. Kind of like in your SQL server, if you were to do like an insert into output star. Yep. Except now you can tell it what you want at the output instead of just that thing. So it's kind of cool, right? Like you could create your whole nested query thing to,

to go get what you need afterwards. Yeah. Um, all right. We'll get up next. Somebody else want to take this one? Uh, I don't know any about this. Okay. Well, we, we talked about this. This is an inline fragment. So the deal that you could have, like if you have common fields that are often returned together, like maybe a person's name, email address, and phone number, then you can define an inline fragment and return that in more than one spot. This is actually a little bit different. Oh.

This is – You take it then. Yeah. They call – so they call this inline fragments, and it's kind of weird. It's basically interfaces, more or less. So when you have an inline fragment, the example that I put here is if you have a salaried employee and an hourly employee, right? Salaried is probably going to have a salary and hourly is going to have an hourly wage. Well, both of those are interface types of a person, right?

They both have first names, last names, that kind of stuff. So if you need to get back, if you're making a query to say, hey, give me back all these people, and then you want the dot salary on the ones that have it and the dot hourly on the ones that have that, you use these inline fragments that basically allow you to say, hey, depending on the type that came back, get me the salary. If it was a salary, the person that came back, give me the salary. If it was an hourly person, give me the hourly. So it's the ability to use interfaces because it'll actually blow up. If you try and get back a person and you say, hey, give me the salary on person, it'll blow up and be like, I don't have that property. So you actually have to tell it kind of, you know, it's almost like a switch statement. Hey, if it's salaried, return this. If it's this, return that. Okay, that's cool. Yeah, it's

pretty nifty. I'm down with that. We also support metadata fields. Why would I ever want to return metadata? Why would I want to push metadata? So this is very similar, right? Like you kind of already use it for the inline fragment. So there's a, I forget what it's called. I think it's field type or something like that, that comes back with them if you want it to. And that's how it determines, hey, what was the type of this object that came back? Was it a salaried or an hourly person? And then they have additional metadata fields.

So if you need to do something that's kind of introspecting the data that's coming back, you can do that. Okay. And then this is where we sort of get into the Star Wars API thing. So the GraphQL schema language, this is where things happen on the server side, right? And we've given this link out way in the past. But this is the GitHub page for how they set up their server side implementation of the GraphQL schema

that essentially wraps a bunch of REST APIs. And really, objects are the building blocks of these schemas. So like you define a person, right? Uh, you define a type person, we'll call it. And that person's going to have a name,

uh, a first name, last name, et cetera. Right. And then maybe, maybe one of the properties of that is going to be siblings. Right.

And then that siblings is going to be an array or I think they call it an array. I might've called it a list. I can't remember, but those are also going to be type persons, right? So it's kind of interesting. So when we talked about, uh, when we talked about the, the optional or required thing, one of the things that's cool about it is like, if you think about that siblings field that you set up inside it, you might have person exclamation, meaning that you can't have a null person as a sibling. It doesn't make any sense.

Then you might also have outside of those square brackets with that person. You might have an exclamation point outside of it saying, hey, I'm always going to get an array back. It might be empty, but you always are going to give me an array back. So you can basically say that these things are required that way. Wow. Yeah, it's pretty cool stuff. Like you have some good control over it. I did not know any of this stuff.

Like I'm very much a beginner in this and I didn't even know this stuff was out there. Yeah, it's really cool stuff. And by the way, most of this is on the GraphQL site, like, you know, clicking through the documentation or whatever. Like you can find a lot of this, but you just kind of got to go through it all. But this is where I wanted to talk about earlier the date thing that you brought up, right? So it supports scalar types, integers, floats, strings, Booleans, and IDs. So ID is a special use case, basically meaning it's a unique identifier that's not supposed to be human readable. You know, it's just that. You can also create your own user

defined scalar type. Okay. So you could do a date time. So they don't call it out here specifically, so they probably don't support it. But if you needed a date time one, you could probably create your own and make that a scalar type that can you go. A scalar date type. In fact, they said, coincidentally, this just like, I'm not saying that this was like, because of my genius that I happen to know this. Just coincidentally, I happen to be on that particular part of the documentation as you bring this up. And they say in most GraphQL service implementations, there is also a way to specify custom scalar types for example we could define a date type and then they show scalar date beautiful so it's perfect so it's not one that exists now when you do create a user defined type you have to specify the serializer deserializer

and validator which fine i mean that seems like a low price to pay. Every time I see serializer and deserializer now, I think Kafka. Saturday? Yeah, Saturday. But anyway. And it supports – go ahead. I just got excited about this one. I jumped it ahead in the notes. So it supports interfaces.

So your custom types can say, like, it has to have these fields. And it's something that you can enforce so that it's not going to generate that endpoint unless those types implement those fields. Yep. And each one of these fields... We love interfaces. Yep. Each one of these fields can have zero or more arguments. We talked about that earlier.

You define them based on the field. If you want to make a customer searchable by name and something else, it's up to you. You can do that. And we got the lists are supported with square brackets, so we've got support for one to minis there. Yeah, so they did call them lists, not arrays. It

looks like JavaScript array notation, so it kills me. We mentioned variables, but you can also have complex input types too. They're defined not as type, but rather as input. I don't know what that means, but it sounds impressive. Yeah, so when you're setting up, like when I talked about earlier, when you set up like a person type with the fields, first name, last name, whatever, it's actually, you know,

type person is what it is, right? When you're setting up an input, this is something that you expect to take in as an argument to, to one of these calls that is actually going to be input, you know, um, God, I can't think of anything. Like if you're going to create an order, it might be input, create order, uh, request. Think of it this way. Like if you were going to create, if I were, if we were to talk about this in terms of C sharp right now, we're like, Hey, I need a, I need a customer class. You'd think, okay, public, class, customer, curly braces, blah, blah, blah, blah, blah. And what you're describing here is in the input one, then it would be, what did you say, customer request?

Yeah, customer order. So input, customer requests, and then your curly braces. Yep. So it's a special thing letting GraphQL know that this isn't a type that you get back. This is more an object that you're going to pass to a request as an argument. All right. So now the fun stuff. Yeah.

And so we talked a lot about good things about GraphQL. I think it's something that we're all kind of excited about and we all think is really cool. But I did want to take a few moments to talk about the criticisms of GraphQL. And there are a few. And the biggest one that you'll see everywhere on the internet, if you talk to your people at lunch or whatever and say, hey, what do you think about GraphQL? Then be prepared for the F word because it's coming. The F word is Facebook. Oh, that.

A lot of people don't like Facebook, particularly developers. People mistrust them. There was that snafu with the React licensing a couple years ago. That ended up getting worked out. But a lot of people just don't trust Facebook for whatever reason. And, you know, whatever. That's up to you. However, I do want to point out that GraphQL is a specification.

It is not an NPM package that you add to your code. It's not some bits that you download. This is an open specification. It's open sourced. People can fork it. And basically, it's kind of like an interface. It's a contract. And they say, if you meet this contract, if you implement these details in this way, then all these other tools are going to work with you. So it allows you to create kind of your own plugins and to use plugins kind of use created by other people in order to, to work with these systems. So this is something where whether or not,

you know, even if you do face hate on Facebook, I think that this would still be something that you might want to consider just because they maintain the spec, but not the technology. Yep. And even then though, their spec, but not the technology. Yep. And even then, though, their spec, any idea what license it is?

I know it's on GitHub and permissive. It's MIT. Yeah, it's the most permissive. So if I remember right, one of the big things with Facebook and these things is they had a restrictive license on some of this stuff at one point that was kind of covering their tail and it got such backlash that they kind of went and started doing this on more of the projects like i think react went through it i think graph graph ql went through it so so it's actually a very permissive open license now yeah like i know what reactive particular is getting kind of some flack now whatever we'll move past that but i really like the whole functional kind of tech side of react

i like how it works i like the one-way data flow i like their emphasis on functional programming and graphql is like another cool step in that direction like i i've got nothing bad to say about graphql in fact i like i wish it was more consistent between different tools, which is kind of a crazy thing to say because that makes it a little bit too specific. My biggest annoyance was when I looked at one plugin and I looked at another and they didn't do things exactly the same way. And that just goes to show

just how similar, wildly different things are. I was dealing with a file system in a database and I was angry that I had to filter them slightly differently, which if I was doing filter them slightly differently which if I was doing that on my own if I was cutting them creating web services it would have been a lot longer and it would have been a whole heck of a lot less consistent so one of my favorite ones too and I think this is really important and really valid is that it's kind of scary for back-end devs like

we talked about how easy it is for people to kind of keep adding new fields and defining the shape of their inputs and passing that stuff over to the server but if you're a back-end focused person you start thinking about what you have to do to support that request and to do it in such a way that it's going to be automatically kind of assembled to the front end like it can be a little scary to think about like security implications or columns that need to be white listed or blacklisted or what technologies i need to bring in services i need to bring in either to generate these endpoints or what i need to do to get my apis to kind of you know jive with this way of doing things and it is kind of scary you know i i would say i would argue that it's consistent you can see

things you can name your queries like it's got all the benefits of strong typing so it gives you a lot of ways to introspect and view and interact and see what's going on to tune that. But if you're looking at just kind of bringing this into an existing project, then there are some things to consider. Well, on that topic, I think one thing that's really important to point out is if you go to the GraphQL website, they actually have a best practices section towards the end of it, of their documentation. And so like the authentication or not the authentication, like the authorization bit of it, like they even show you, hey, this is how you should probably do this, right? One of the examples is, you know, hey, it might be tempting to put some of this stuff into the actual schema bits. And they were like, no, you know, hey, it might be tempting to put some of this stuff into the actual schema bits.

And they were like, no, you shouldn't do that. You should basically take the user that should be authorized or needs to validate authorization on, take the request that came in or the response. I can't remember. And then pass it to an application layer and say, you know, do the validation there, right? Keep it in your application tier. Don't mix it in with your GraphQL. So, so with any kind of technology, you're always going to get knee jerk reactions from people that aren't familiar with it or, or it's different than way that they've typically done it, they have a ton of answers. Like even the pagination, like one of the things that I found out, um, that I looked at back in the day was like, Hey, we don't have any way to do pagination. Basically you're gonna have to return it and handle it on the client. And I was like, well, that doesn't make any sense. Like if I got 20,000 things, I'm not returning that client. They've actually come up with a way to do that now. And it's, it's kind of crazy. Some of it that I've looked at,

because they'll return basically like ref cursor or cursors, ref cursors back to the, to the client. That's essentially kind of like an open connection, sort of that you return back up to the server if you need to go get the next set of data. And so it knows how to use that cursor, et cetera. But, but what I'm saying is they've figured out a lot of things over time. So a lot of these questions, like what you were saying, that will be scary for backend devs, this is stuff that came up a lot. And so they've come up with solutions to a lot of these problems. Yeah, and that's super valid.

When I put on my standard normal curmudgeon hat that I always wear, the curmudgeonly backend developer, if someone comes to my office and says, hey, there's this new technology. Let's me query whatever fields I want and you don't have to do any extra work. I'm going to take one look and say, like, there's a ton of work for me. You know, get out of my office. They're like, no, no, wait.

But you could generate it. Just use this tool and generate for every field in the database. I'm like, wait, that sounds terrible. Get out of my office. But I swear, just take another look. Every qualm, everything that, like, you know, needs your reaction that you might kind of feel as a back-end kind of focused person thinking about this, I encourage you to go take a look and see what people are doing to deal with those shortcomings and see how they've worked around it. And you might be learning something new or you might kind of think about things differently or you might be right. And that's fine too.

Well, you know something else that's kind of interesting that that has nothing to do with any of this but as a back-end dev you should also think about well this might be a valuable way for me to find out information about how our app is being used or what's being used right because if you can open that up and you give people the ability to query things that they need and you have your tracing in place to where you're logging this stuff, you can start finding out, hey, what pages are people hitting? Like what queries are being passed along? What kind of stuff? Because that might also inform you as a back-end dev,

hey, where do I need to implement caching? Or where do I need to implement some better strategies to improve performance or whatever, right? But in fairness, though, you don't need GraphQL for that. No, no, you don't. But it's all coming through a single whatever, right? But in fairness, though, you don't need GraphQL for that. No, no, you don't. But it's all coming through a single pipeline, right? Like it's no longer you have to add in logging for this stuff that you did over here and this.

Like it's one centralized place that you can kind of say, these queries were issued to this API endpoint. There's only one, right? So that's kind of what I'm getting at is like it would allow you to easily kind of tag along and find stuff out. Not saying you say like, hey, let's get rid of the middle name field. I don't think we even use anywhere. So, OK, well, let me go check and see if we use anywhere.

First thing I do is I search the code base to see if I see a middle name anywhere. Here's maybe there's some select star queries. You know, unfortunately, in my code base somewhere. Let me search for those. OK, I think I found a couple. Let me go look at those pages to see if they're calling middle name. You know, like that kind of stuff kind of stinks to do. But if I'm doing GraphQL where I know that those fields are like they have to be, there's no stars, you know, they have to be explicitly laid out.

I can easily query that and say like, hey, let me look at the last three months worth of GraphQL queries. Do I see middle name anywhere in there? No, kill it. Yeah. Yeah. So I'm not saying that you can't get metrics and that kind of stuff on existing API endpoints, but like we talked about earlier, you have a REST endpoint that returns back a person, you're getting first name, middle name, last name every single time. That's just how it works, right? So you can't even tell what usage is. This would actually give you some insights into, hey, what are we using here? How are we using this data?

So it's not necessarily the selling point, but it's kind of interesting that you have one centralized location to look at for how things are being used. I do find it interesting that one of the criticisms you have here, though, is that the no built-in versioning. And yet that's actually one of the things that is touted on the very front page of GraphQL.org as a benefit. Is it really? Yeah. They have a blurb that says, evolve your API without versions. Oh, that's funny. Oh, okay.

Yeah. And I know a little bit about that. So where I got this from is a blog post Yeah. And I know a little bit about that. So the, um, where I got this from is a blog post that I think I have linked in the show notes. Uh, yep.

That basically talked about the, you know, I looked for like kind of top five reasons you shouldn't use it. And when they were talking about versioning there, they were specifically talking about like, what if I've got an API that's going to version one dot two and one dot three. And so rest kind of has support for that in the URL where you can easily

kind of put that up there. GraphQL, you'd have to stand up a whole nother service, which doesn't, you know, that kind of stinks. However, GraphQL's way of combating that is basically by saying you can deprecate fields and you can add fields. And that way it doesn't break any existing queries that are out there and they'll get a little warning about deprecated fields. And eventually you can kind of trim those out of there. But yeah, I mean, it doesn't have a great answer to versioning, at least that I found, other than saying, you know, you can kind of not worry about. But it still kind of implies that things are still kind of on the same page, that all your services are kind of growing up together. Well, maybe, I i mean because again consider the source right right like you you referred to him as the f word yeah oh yeah and yeah so maybe

maybe they're thinking is like well do you really need to support multiple versions of your api like maybe that's just being overly complex right like it's great thatEST can do that. Sure. Cool. You can have API slash V1 slash whatever and API slash V2. Do you really want to have to support those? Maybe that's their point. You made a great point too. I Google

criticisms GraphQL and I found tons and tons of pages that mostly reference the same few things. But I did find a few people that went out and like really in depth, like put a lot of checkboxes and we'll have some, some links in the show notes, put a lot of like checkboxes like rest does this graph. Well,

does it graph? You'll does this rest doesn't. And, uh, some nice comparisons and that you could tell that they really deeply thought about it, but some of the things seem like kind of a stretch. Like it's got an X under performance for graph QL.

Like, well, why is rest necessarily any better than graph ql right like there's definitely you know we talked about like the overfetching and underfetching and like i feel like you could argue it either way that graph ql does some things has some things built in that's nicer performance than rest doesn't rest i guess it's only doing whatever you tell it to so i guess you could kind of make the argument that it's a minimum amount of work. And so maybe it's less work than GraphQL, but it definitely felt like some of the things they are really going after felt like a stretched mean. So that kind

of made me think like, maybe they just don't like Facebook. That's very possible. I mean, it's like you said, if you've got something, it's almost like entity framework. It's the same knock on entity framework, right? You let a developer write some sort of link query, and all of a sudden you brought the server down, right? So I totally see that you could abuse it, and you could do something that's just completely not smart. But, you know, that's education. So here's a couple more just because I can't resist. So tooling and API management. REST has limited.

Okay. GraphQL has X. I think the tooling is pretty good. Oh, the tooling on GraphQL is amazing. Graphical especially. That particular tool is killer. All right. What about printed books?

Like what? Like are there more? tool is killer. Alright. What about printed books? What? Of course there are more REST printed books because that's back when books existed. It was from a different time. It's competing with 30 years of books about REST. Come on. And Enterprise Ready? Facebook seems to think so. Yeah.

Facebook uses it on almost all their pages. Yeah, so I'm glad the person spent the extra time and thought about this stuff. It came up as a good example. It definitely felt a little, I don't know, a little rough. It's a tough grader. All right, so what else we got here? What if you need purpose-built stuff? Yeah, what if you've got these queries like we talked about where you have some highly performance stuff that's tough to do but put together?

And so you want to make a REST endpoint, for example, that takes in a minimum number of arguments, does some super crazy CTE-laden relational query, whatever. What if you need to make a REST call? I would say, like, we'll just do it then well you could or you could actually do the same type thing you could create a purpose-built type for graphql like you could totally fake it if you wanted right like performant um you know order query yeah it doesn't really limit you in any way to what you could do right whatever you want man all right yeah uh no information hiding that's the kind of thing we talked about where it's like Yeah, it doesn't really limit you in any way to what you could do. Create whatever you want, man. All right. Yeah.

No information hiding. That's the kind of thing we talked about where it's like, well, what if I don't want all my columns returned from this table? What if I've got a good customer bit field and I don't want someone in the client to be able to return that and see what we think of them? And what we said out there, there's whitel's white listing, black listing. But yeah, I get what you say. If you use some of these tools that generate stuff for you, maybe it's going to generate stuff that you don't necessarily want and you don't realize that that's not something you want to expose. Yeah, that makes sense. So that's kind of on you to make sure you're policing it well.

And then Sam mentioned prevents caching. And the deal there is like, you know, if you're doing REST, you got those gets, like strictly speaking, the browser can cache those REST calls. It's kind of part of the notion of REST is that you're allowed to cache stuff. And if you were doing GraphQL,

it's like, well, can I cache or not? I don't know. So, to call it out here, you are specifically talking about browser caching because we're not talking about data caching because that could happen anywhere. Well, specifically, we're talking about get requests. Get requests, right.

So, yeah. I mean, all right, fine, whatever. I mean, I guess it does matter a little bit, right? Because a get request that returned you back 10 megs of data, you know, if that was cached in your browser, then the next time you hit it, it's going to look at the cache and it's available, right? As opposed to a GraphQL, it's going to have to go pull that 10 megs of data again. Yep. That one's legit.

I feel like that one holds a little bit of water. What if you combined it with your PWA? Heck yeah, man. Your PWA? Yeah, PWA. You can fetch those,

you can cache those fetch requests and there's nothing that GraphQL could do about it. But you probably shouldn't. Probably pass them on if you can. So here's the real question I kind of had of this thing. So I want to know like

how important GraphQL is. Like if I'm either front end or back end developer, how important is it that I learn GraphQL over well over the next couple years like are we talking like you know medium is this like how like if you could compare this to a technology is it as transformative as rest is this transformative as docker or is it so if i could if i could make a comparison to an article that i read once. So basically what we're saying is the article is like, hey, is Docker the new Git?

So is GraphQL the new Docker? Yeah. That sounds like a great article. I agree. I think that I personally, when I first saw it, I was like, I can't believe we've been doing it wrong for so long. Like, that's my gut reaction to GraphQL and the thinking of it. So I think, yes, it is absolutely transformative. Like it's as important as some of those things like Docker or whatever, like just rethinking how you get data for your UIs.

Yeah, I would say I'm going to go slightly under Docker on this one. I think Docker is just so big and Git's so big and REST has just changed the way that people think about the Internet and services. So I don't think it's quite as big of a deal as those. I think you can get away with never learning GraphQL. That's my prediction as of right now. I think it's not going to be five years from now everyone's doing web services now everyone's doing like everyone's doing web services right now right it's not i don't think it's going to be as popular of that as that but i still think it's really cool and i do think that there's a lot of problems out there like the ubers and like graph type problems that are just now really

starting to get kind of solved in like the app worlds because the tools have gotten better and made it easier to do things like this and so like this, how this ties into the refactor app and it kind of really plays nicely with like streaming architectures and kind of responsive UIs. I think that it's a really important part of that picture. And so I'm going to say it's just it's like two steps under Docker for me. Yeah, I guess here's my question. i think i i totally think that's legit how if you're going to build a new app how likely would you be to give graphql a real shot versus rest and that's kind of what it is for me it's like if i'm building a new app i'm absolutely

doing docker like i'm gonna be thinking docker from the beginning because that's kind of what it is for me. It's like if I'm building a new app, I'm absolutely doing Docker. Like I'm going to be thinking Docker from the beginning because that's how I deploy it. So it's like it's kind of becoming critical to my workflow. When it comes to GraphQL, only because I don't know it, it's almost like, okay, well, is this thing going to be good enough for me to want to spend the extra 10, 20 hours to kind of get up to speed and tools for GraphQL? And I don't know the answer to that yet. It's something I definitely want to play with. But generating those REST APIs isn't a huge pain point for me right now. So while I guess what I'm saying is that it feels like a nice to have to me,

but I think that as time goes on, it's going to become, you know, all those nice things. Like the story of technology is essentially the story of like nice to have, where you make things just a little bit better. Next thing you know, you're 10 stuff. Like the story of technology is essentially the story of like nice to house where you make things just a little bit better. Next thing you know, you're 10 steps ahead of your competitor. Yeah. I think,

I think for me, what does it is the thought that I don't have to write any more of these end points, right? Like it's just, Oh, I have my schema. Oh,

I can just do work now. Right? Like it's, I I'm with you, the investment of time to learn it, to implement it, to do all that. Yeah.

That kind of sucks. Right. And that's always the man. I don't know that I investment of time to learn it, to implement it, to do all that. Yeah. That kind of sucks. Right. And that's always the man. I don't know that I want to do that right now, but if you had that, then how much does it ease your development flow? Right. And that's, that's, I don't know. That's where I'm kind of like, man, it's up there. And I agree. I think that Docker is probably one of the biggest things that's hit in forever. But yeah, I don't know. What about you, Outlaw? I'm kind of torn on it because a part of me wants to say like, well, there's a chance that if you already care about Docker,

then, okay, here's where I'm trying to like prevent my mind from going. If you care about Docker, then you might already care about the ability to scale something out. But then I'm like, no, no, no, no, no, no. Let's not confuse something like Docker Swarm or Kubernetes with Docker. Right. So like the example that Joe brought up, where he's like just talking about it from like a development

and deployment kind of strategy. Right. So then I'm like, okay, well, if we, if we, if we put on this strict, you know,

blinders about how we talk about Docker as not trying to use it to solve any kind of scaling or use it for scaling, then I guess, cause you're really going to, I think you're going to care about graphQL more if you're talking about bigger... Maybe I'm wrong in thinking that. It's application development. But I think you brought up a great point. It's real easy to think about Docker and scaling and Docker and deployments when that part is way harder.

Right? Like Kubernetes is what? Approaching 2 million lines of code? Right. Like, that's not a small chunk to bite off, right? So just getting up and running with Docker, pretty quick. It can happen pretty quick. I would say I would rank Kubernetes as highly transformative, too.

And things like on the front end, like CSS Grid hugely transformative view and react hugely transformative angular when it came out totally changed everything like everybody jumped ship to angular almost immediately like overnight and then immediately left and then left because they said oh no 1.3 won't work with two um yeah yeah i don't know i i still think it's pretty high because I think if I was somebody that was working on building an application, the fact that I could iterate so fast by just having that data available when I want it would be amazing. I got it.

I got it. Kind of. I think I'm going to agree with Joe though. It's not as big. Do you, I think if I had to rank them, I look at it like this. Okay. Here, this. Okay, here's how I view it. If you were going to do any development on a new project, without a question, you're going to use Git.

Right? In the current world we live in. Right? Yeah, I'm not even going to go look for alternatives. Right. You're just going to use Git. So that's a given and it's highly likely that you're going to use docker to dev on to dev against dev on to deploy out your idea so that one is quite likely quite possibly going to be something you're going to do. You might not. You might not. You might just use, you know, like Express and, you know, have a node, a local node server and be done with it. And like, you know, that's it, right?

So that means the Docker is kind of like a maybe, right? I like how you're ranking this. And now it's like, okay, well, how am I going to query data? Well, I might go the GraphQL route, but depending on how big or small this thing is going to be, I might only have a very few simple endpoints, and GraphQL might just be overkill for my needs. And so I might just say, you know what?

I only need a couple of rest endpoints, right? So if it was super easy to set up, that would probably influence your decision. Like if it was trivial to get started. Right. If you could just push a button and you're there. Well, you still have to write the web services though, right? So you're like, I guess if the UI work warrants the effort to,

if the UI work I have to do, I'm going to save more time doing that with GraphQL than it's going to take me to get up to speed and set up GraphQL. Yeah, it's interesting. And it's hard to know without having done it all, right? Like, one of the links that I've got in the resources is there's this graphql.org slash code page. And they basically have all the language implementation, maybe not not all, they have a lot of language

implementation. So like if we wanted to do it for.net, right? Like you go up there and click on C sharp.net and then they have graph QL for.net. So maybe depending on how quick it is to set that thing up and run it, that, that might be your determining factor, right? Well, I mean, I see Erlang, so. Right. That's what you're going to do, obviously. So, so yeah, I'm with you. I kind of like how you rank that outlaw. Like GitHub is like a foregone or not GitHub. Git is a foregone conclusion. Right. Docker is a probably I'm going to use it. And then what, what's your endpoint going to be right now? More than likely all three of us would be like, well, we know how to do REST and regular web API type stuff. That's easy. This is going to require more thought. But if we've done it once or twice, then maybe it would be a foregone conclusion there too, right?

Like you'd be like, oh, well, this isn't bad. I know the steps. It's kind of like what your natural flow of anything is, right? Like you're going to kind of take the path of least resistance when you actually want to accomplish something quickly. Yep. One other argument though, so Gatsby bundles GraphQL and Gatsby is really popular.

Tools like Apollo and Prisma are also, you know, making a lot of headway and making things easier. So I think Meteor may even come with like GraphQL kind of out of the box now too. So if the front end tools start exposing more and more data and we start seeing more and more node packages that deal with graphql it may get to a point where it's like harder not to set graphql up with your stuff so that it you know it can interact with these other tools sure so that's kind of my maybe so that's how i'm hedging like maybe we'll see a even bigger uptick but i've definitely got my eye on graphic well it's definitely interesting especially when

we're going to talk about those other two factors we see how it kind of plays in with those subscriptions like i think web sockets are here to stay i think that's transformative and i think this plays really nicely with it so i'm interested i'm intrigued yeah well you know i had one interesting thing that i thought we would call out with this. You know how I love my games. Which is older, GraphQL or coding blocks? I think we are. Oh, my gosh.

I think we are. Yeah, we're going on seven years, right? So, yeah. Please I think we are. Yeah, we're going on seven years, right? So, yeah. Please tell me we are. So, that's your final answer? Yeah, it is. Well, GraphQL is from 2012. Oh, man, we missed it.

Yeah. So, that's the interesting thing is like if you go to GraphQL.org, right, they call out that Facebook was using it since 2012, but it was publicly released in the initial release on the Wikipedia pages 2015. Well, doggone it. Yeah. It's funny. You still have some people saying like, well, GraphQL is not mature enough for me. It's like, you know, seven years is kind of a long time in technology. Maybe it's all right now.

Let's be honest. Is there a site on the planet that has to scale like Facebook does? If they're using it, they've probably figured some things out, you know? Yeah. So, yeah, that's pretty cool. It kind of hurts a little bit that they're older than we are. Yeah. I'm trying to remember like,

cause our first episode came out in like a September timeframe, 2013, right? Yeah. I think, I believe pretty sure. Yeah. We old,

you know, if you go to Facebook, can you like watch for graphical queries? Yeah, I believe. Pretty sure. Yeah. We old. You know, if you go to Facebook, can you watch for GraphQL queries? Probably. I'd venture to say. So I'm looking at it now. Sorry. Oh, I'm not looking at the Facebook thing that he just asked about but uh our first post was by you alan on august 15th 2013 so yeah you're a day late dollar short to beat graph qo yeah well but now that wasn't when we released our first episode though no that was the following month. October, right?

Well, September would have been the following. Oh, you said August. Okay, so September. But... I is for interface. Yeah. But yeah, I think you're right there. I think that we didn't go live until October. So yeah, GraphQL is older

than coding blocks. So yeah, to Joe's mature point. Yeah, we're definitely mature. We're not that mature compared to GraphQL is older than coding blocks. So yeah, to Joe's mature point. Yeah, we're definitely mature. We're not that mature compared to GraphQL. Yeah, we're totally mature. I did look at Facebook and their requests are crazy. I've never looked at them before, but it looks like they're probably compressed. I doubt they're encrypted.

So you can't even really see what they're querying for or what they're passing. Like it's some crazy gobbledygook. But I can see that there's an endpoint specifically called GraphQL. So I'm assuming that's GraphQL endpoint. But the data that they're passing to it is all, you know, it looks like it's x64 encoded. And I don't really know. Yeah.

That's cool, though. So they're using it. That's important. That's what it looks like. Since 2012. Excellent. All right. So I guess wrapping up here. Oh, no it looks like. Since 2012. Excellent. All right. So I guess wrapping up here.

Oh, no, we can't wrap up. So we got resources we like. Yeah, definitely Swappie. Yep. Swappie for sure. The three-factor app is going to be one. We don't have it in there. That's amazing.

There's a – oh, yeah. We should probably have that in here, I think. Whoops. Yeah, I mean, there's a whole collection of links. Like as we were talking throughout the episode, I was just grabbing links and they're going to be in there. So I'll be sure to include all that. Cool.

And with that, we head into Alan's favorite portion of the show. It's the tip of the week. So I found this really cool article and I need to, I haven't had a chance to go through it all yet because I found this like right before we were recording, but it was like the top post on Hacker News. But Google has have Google has released or have released. Google has released, uh, their engineering practices related to code reviews.

So I thought this would be an interesting read to see like how Google deals with these, you know, like what their recommendations are for code reviews. And then, you know, to try to apply that to our own environments. Man, that's a lot of reading. Yeah, it put a lot of thought into it. They have some interesting stuff.

I just looked at how fast should code reviews be. It's like you should do it within one day. You should be able to respond within 24 hours. Yeah, I mean like the high level bullet points here were the standard of a code review, what to look for in a code review,

navigating a CL in review, speed of code reviews, which is the one you just mentioned, how to write code review comments, and handling pushback in code reviews. Courtesy. That's something that they talk about, like basically personal productivity versus team productivity. And they're like, by delaying code reviews, you're slowing down the whole team.

So, you know, don't break. If you're in the middle of like some intensive code tasks, don't break. Other than that, chop, chop. Yeah, this is really good. Yeah. Yeah, it's going to be super awesome. So I'm really excited about that. So I thought I'd go ahead and share that.

But the tip of the week that I planned on giving before I found this article was, you know how Joe sometimes will give you like something obscure as, as his tip of the week. And, and it won't be anything like related to like, Oh, Hey, here's this great keyboard shortcut. Or, you know, Hey, here's this great, uh, uh, you know, command that you could do that you didn't know about. Right. You know, we're like, Hey, here's like 15 different parameters you can add to this get command and look at what it does. So, so I thought, you know,

okay, I can, I can channel my inner Joe here. Right. And I can come up with like a media tip of the week. So if you haven't already seen the boys, you have got, this is, this, I, this is my new favorite show of all time this show is great it is good this is i i don't want no spoilers don't ruin it for anybody but do yourself a favor

and go watch this show on prime amazon prime amazon prime yes yeah i i liked it actually you know what i wonder can you also just buy it if you're not an amazon prime customer i gotta imagine they would let you i don't know it seems like 100 bucks or 120 now it's kind of expensive watch on one show so let's see i don't know maybe because i'm prime i don't get to see that kind of option. Sort it out. Figure it out. That's all I can say. It's a fun watch. Yeah, you should see this. My tip of the week is something I accidentally did the other day. As soon as I did it, I was like, what?

Is this magic? I was in visual studio and I don't know why I hit ctrl shift v I have no clue what was going through my head if anything was at all but I get this pop-up that shows up on the screen with my past clipboard items. And I was like, Oh my God. So this is a little bit. So like, have you ever been in the middle of doing things like we're moving stuff around or whatever? And you're like, Oh man, I don't want to control. See that other one. Cause I'm going to lose what was in my clipboard. Right? Like, I don't, I don't want to do that. So it's so like, it would like minorly stress me out as I did stuff. Like I've got to do it in this order. So I don't want to do that. And so, and so like, it would like minorly stress me out as I did stuff. Like I've got to do it in this order. So I don't have to go back and read, dude, if you control

shift V, you can go to your second clipboard item or your third or your fourth or whatever. Like it is amazing. And I don't know how I've never found this before. So, um, yeah, man, control shift V in visual studio, just life changing for me. Um, it was so exciting to me that I actually came in and created our show notes page so that I could put that in as my tip. So I wouldn't forget it. So that's number one. All right. And then visual studio shortcut. All right. So the next thing, this credit goes out to Sung Kim, also known as Dance to Die, one of our awesome slackers and Twitter guys. And he's everywhere, man. He's amazing.

I sent out like two blog posts I ran into in the same day where I was like Googling two random things. And I found like I stumbled upon his blog answering my question. It was awesome. Yeah, he does an amazing job of basically everything. So, man, I'm just sorry. I want to just focus in on this Control Shift V because mind blown. Right? So, like I found this cheat sheet of like shortcuts and the way that the description here was paste,

plural pastes an item from the clipboard ring tab of the toolbox at the cursor in the file and automatically selects the pasted item cycle through the items on the clipboard by pressing the key, the shortcut keys repeatedly. I don't even do that. I just do up and down arrow. Like you can arrow through them, man. Dude, it's amazing.

That's all I can say. So it's not just Control Shift V though. Control Shift Insert would also do it. Would do it. Okay, cool. Yeah. That's pretty cool. So on Twitter, I was having a rough.

I have a tendency not to turn off my computer, right? Like ever, more or less, until it just forces me to. And I started up on a Monday morning, picked up where I left off on a Friday working with X509 certificates. Kill me now. So I open up my computer and I have like, I don't know, a hundred tabs in Chrome. Right. And I thought it'd be funny. Hey, let me screenshot this and put it on Twitter. Like, Hey, this is when you know that you're frustrated, right? Like when you got that many tabs open, it's only because you just keep clicking on things to try and find answers. Right. Well, song sent a link to a site called

work on a.com and it's really cool. It's a thing that will allow you to sort of organize your crazy tab problem. So they have, I think in subscription, but they might also have a free tier, but it allows you to sort of organize what you're working on. So you can create like little groupings for your tabs, right? So like they even have an animation on the homepage that's, you know, they've got their July campaign or the blog post or whatever. And then they'll have links that are associated with that. So instead of having, you know, five gazillion tabs open in Chrome or whatever your browser is,

you can go here and you'll actually have them organized. So it's kind of nice if you want to be able to group things together. So it's just like, instead of having all those tabs open, now you're going to have it bookmarked on this thing? That's sort of what it looks like.

Yeah, so you can keep track of what you did. Now, I will say, so this is cool, but there are a couple of funny things. So Dave Follett, he's apparently like me. I think he said he had 100 tabs open in his mobile Chrome. On his phone, yeah. That was amazing. But I will say, there are times, and I don't know if you guys do this,

I'll have the same page open five times. By accident, yeah. No, no, no, no, no, no, no. They're all at different points in the page. Oh, if it's a long page. Because I don't want to scroll around. I don't want to lose my place. Like, hey, I found some valuable information in paragraph 23.

Right. And 59, right? Like, I don't want to lose those. So one thing I did find out, though, is Chrome will actually start disappearing tabs on you. After you hit some limit, they disappear. Like you don't even see them anymore. Wow. Well, you mean, wait, wait, wait.

No, no, there's no scroll. The tab closes? No, no, no. It's there. Or you mean like it's there, but when you reopen it, it has to like refetch the page. No, no, no, no. You can't see the tab. Oh, oh.

Your tabs have gotten so small. It's gone. Okay. Yeah, you don't see this new tab you created. Now you can control tab to it. You can control shift tab, but there's no just looking up there and clicking on it. Right. It doesn't exist.

So yeah, that was fun. But, yeah, this was an awesome tip. I think the only place where this wouldn't work for me, though, where work on a wouldn't work for me, though, is that, like, if I was already going to be organized enough to use this thing, I wouldn't have the thousand tabs already open. I kind of thought that, but, you know, I have hope for my future self. See, there's no hope here. None. All hope is lost.

Hey, Jessica, she actually liked it. I think she actually started using it based off Song putting that up there. Thank you for the tip. I think that was an awesome one. Yeah, absolutely. Does that make it my turn? Yeah, it does make it your turn. I'm done. I'm out of tips. just relaunched chrome so i don't know how many how many tabs you get it was going to be like uh here listen to this podcast or more than i have fingers oh so this uh i restarted for a reason i relaunched for a reason. So, Hube Dave, while we were recording the show, tweeted us and said, hey, this would be a good tip. And it was a link to Allie Spill, who I'm a big fan of, who's also on the Ladybugs podcast, which you should go listen to right now.

You should go sub. And she just let me know that you can install themes and set up custom themes for your chrome's dev tools i mean i knew you could do like a the built-in like dark tool but you're talking about in addition custom themes there's a flag you have to enable it's a developer tools experiment they have to turn on and the relaunch chrome that will let you enable custom colors for your dev tools. And there's extensions in the Chrome store that will do it for you and make it a little bit easier, like Dracula, not to be confused with Dracula, or what's it called?

Darkula? Darkula, yeah. Darkula. No, this is Dracula like the vampire. And so you can go in and turn it on and now i've got a dark theme developer console that's pretty cool huh yeah and that's for y'all because i don't actually like dark themes but i don't like darkula it's now this one looks pretty good and yeah this one's nice but yeah yeah, Darkula and IntelliJ's products

irritates me. Yep. But in the meantime, I also changed my chrome theme and now it's like cobalt blue and I can't read any of my bookmarks. So that's unfortunate. I'm going to fix that. But I'll get back to the show. I just used the built-in one where you can

specify the dark. But is it Darkula dark? It's not Darkula dark. I give up. Well, the Darkula, though, isn't really all that dark. Yeah, that's what I like. It's like a gray. Yeah.

But I like Darkula. I know a lot of people don't. But also, this is Dracula. So what I'm talking about, though, is if you're in your Chrome DevTools and you click on the ellipse in the top right in the dev tools go to settings and then in the preferences there's a appearance and you could select right there from the top theme and it's you know light by default or you know you can select dark i need more options than that. Yeah, apparently. Yeah. I need Dracula. Right.

Definitely. Yeah. Here you go. Advance to Saki Oba-Dot. Yeah. Now how many tabs do you have open? Three! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah! Ah!

Ah! Ah! Ah! Ah! Ah! Ah! All right. Well, all right. So, hope you've enjoyed this is uh part one of the three factor app and uh with that be sure to subscribe to us on itunes spotify us to share more using your favorite podcast app in case you happen to be listening to us uh from some way that isn't via subscription and uh like I said before, you know, we would greatly appreciate it if you'd leave us a review,

if you haven't already, and you can find some helpful links at www.codingblocks.net slash review. Ah, Joe's not hijacking me today. Look at this while you're up there at codingblocks.net. Check out our show notes, examples, discussions,

notes, and more. And if you could help me get rid of this COBOL theme, I'd be really appreciative. I can't even tell how many tabs I have open because I can't read them anymore. I don't know how to get back to the show notes. What do I usually say? Send your feedback questions, rants to Slack? Yes.

You're doing good so far. We've got some social links at the top of the page, and you can follow us on Twitter at CodingBlocks. Look at that, man. All from memory? We are only 115 episodes. We're almost as old as GraphQL at this point. So, yeah, he's had a minute to learn it. Never memorize what you can query.

That's right. Oh, amen, brother.