WEBVTT

1
00:00:06.200 --> 00:00:09.560
<v Speaker 1>Hey, everybody, and welcome to another episode of Ruby Robes.

2
00:00:09.919 --> 00:00:13.519
<v Speaker 1>This week, con our panel, we have John Luke.

3
00:00:13.759 --> 00:00:14.800
<v Speaker 2>Hello, Dave.

4
00:00:15.160 --> 00:00:17.839
<v Speaker 1>Hey, everyone feels so much more familiar to not say

5
00:00:17.839 --> 00:00:20.000
<v Speaker 1>your last names. I'm Charles Maxwood or Chuck.

6
00:00:20.079 --> 00:00:20.559
<v Speaker 3>I'm Chuck.

7
00:00:20.879 --> 00:00:22.920
<v Speaker 1>And this week we're talking to Dmitri. Dmitri, I, do

8
00:00:22.920 --> 00:00:24.559
<v Speaker 1>you want to say hi and let us know who

9
00:00:24.559 --> 00:00:24.839
<v Speaker 1>you are?

10
00:00:25.199 --> 00:00:28.239
<v Speaker 2>Yeah? Sure, Hi? Ever want? My name is Dmitri and

11
00:00:28.320 --> 00:00:30.280
<v Speaker 2>you can call me Dima if it's simpler, because I

12
00:00:30.320 --> 00:00:33.479
<v Speaker 2>know that Russian names start sometimes. I started my software

13
00:00:33.479 --> 00:00:37.560
<v Speaker 2>development career in twenty and twelve and decided to focus

14
00:00:37.600 --> 00:00:40.960
<v Speaker 2>on Ruby and Rails in twenty fourteen. Before that, I

15
00:00:41.000 --> 00:00:44.359
<v Speaker 2>did some totten and development, front and development and iOS

16
00:00:44.399 --> 00:00:48.039
<v Speaker 2>and since southern and eighteen, I guess I work as

17
00:00:48.079 --> 00:00:50.640
<v Speaker 2>a back end developer at people Marshus. I spent a

18
00:00:50.640 --> 00:00:54.880
<v Speaker 2>lot of time working on open source. I committed to Urga, Rails, grab, Kluba,

19
00:00:55.000 --> 00:00:58.079
<v Speaker 2>has some smaller gems, and I also maintained some of

20
00:00:58.119 --> 00:01:00.679
<v Speaker 2>my own jams. And I started working the graph field

21
00:01:00.880 --> 00:01:03.640
<v Speaker 2>I guess in two thousand and seven gen, so it's

22
00:01:03.719 --> 00:01:07.680
<v Speaker 2>like four years not for yes, so far nice.

23
00:01:07.760 --> 00:01:10.879
<v Speaker 1>So the discerning listener probably heard graph ql about four

24
00:01:10.920 --> 00:01:12.680
<v Speaker 1>times in your introduction, and that's we're going to be

25
00:01:12.680 --> 00:01:15.439
<v Speaker 1>talking about specifically graph QL and rails. We talked about

26
00:01:15.439 --> 00:01:17.680
<v Speaker 1>graffiti a couple months ago, and so this will be

27
00:01:17.680 --> 00:01:20.400
<v Speaker 1>interesting to kind of compare the approaches and things like that.

28
00:01:20.519 --> 00:01:23.480
<v Speaker 1>I know that some people love graph ql and some

29
00:01:23.560 --> 00:01:27.120
<v Speaker 1>people love to hate graph ql. So I'm a little

30
00:01:27.159 --> 00:01:29.359
<v Speaker 1>curious as we get going, can you just kind of

31
00:01:29.359 --> 00:01:31.439
<v Speaker 1>give us the elevator pitch for graph ql. I know

32
00:01:31.799 --> 00:01:34.280
<v Speaker 1>most people are probably at least somewhat familiar with what

33
00:01:34.319 --> 00:01:35.879
<v Speaker 1>it is. But if we can start there, then we

34
00:01:35.920 --> 00:01:39.840
<v Speaker 1>can start talking about why substitute this for REST, or

35
00:01:39.920 --> 00:01:42.159
<v Speaker 1>use it in conjunction with REST, or what the trade

36
00:01:42.200 --> 00:01:44.239
<v Speaker 1>offs are, or how to set it up or all

37
00:01:44.280 --> 00:01:46.079
<v Speaker 1>that other stuff. But knowing what it is first is

38
00:01:46.079 --> 00:01:46.920
<v Speaker 1>a good place to start.

39
00:01:47.280 --> 00:01:50.680
<v Speaker 2>Yeah, sure, that's strand out. So if you're using RESS,

40
00:01:50.840 --> 00:01:53.319
<v Speaker 2>probably got to use to a concept of a resource

41
00:01:53.560 --> 00:01:56.040
<v Speaker 2>that each kind of data you have is a resource,

42
00:01:56.040 --> 00:01:58.519
<v Speaker 2>and you have at least affections you can perform them,

43
00:01:58.599 --> 00:02:01.599
<v Speaker 2>and you have these rest points that I allow you

44
00:02:01.680 --> 00:02:04.079
<v Speaker 2>to fetch the data you need. But the problem is

45
00:02:04.120 --> 00:02:06.719
<v Speaker 2>that sometimes you need a different set of data for

46
00:02:06.799 --> 00:02:09.439
<v Speaker 2>each platform. For instance, when you're working with your own

47
00:02:09.560 --> 00:02:12.960
<v Speaker 2>website and your mobiliplication. And in this case we have

48
00:02:13.080 --> 00:02:15.759
<v Speaker 2>two problems which come from the same place. The first

49
00:02:15.759 --> 00:02:18.439
<v Speaker 2>one is under fetching, which means that when you finish

50
00:02:18.520 --> 00:02:21.240
<v Speaker 2>some data and you want to get the additional data

51
00:02:21.240 --> 00:02:24.080
<v Speaker 2>about the additional resource, you have to make another quest

52
00:02:24.159 --> 00:02:26.080
<v Speaker 2>or sometimes you have to make a lot of requests

53
00:02:26.080 --> 00:02:28.759
<v Speaker 2>to get the full page. Imagine that you're working on

54
00:02:28.840 --> 00:02:31.639
<v Speaker 2>Baseborg or something. You have a feed, a rist of friends,

55
00:02:31.639 --> 00:02:33.599
<v Speaker 2>all that stuff, and you have to make additional requests

56
00:02:33.800 --> 00:02:36.479
<v Speaker 2>or you can you know, have a special request that

57
00:02:36.599 --> 00:02:38.639
<v Speaker 2>allows you to fetch all things you need. But it

58
00:02:38.919 --> 00:02:41.319
<v Speaker 2>also sounds wrong because when you have the mobile AUP,

59
00:02:41.360 --> 00:02:43.319
<v Speaker 2>you don't need to load all your friends and they

60
00:02:43.319 --> 00:02:44.840
<v Speaker 2>fit at the same time, so you have you know,

61
00:02:45.000 --> 00:02:48.520
<v Speaker 2>separate APIs for the mobile application and your website. The

62
00:02:48.560 --> 00:02:51.360
<v Speaker 2>second problem is overfetching. It's almost the same thing. When

63
00:02:51.360 --> 00:02:53.919
<v Speaker 2>you work on the mobile app and you get all

64
00:02:54.000 --> 00:02:56.919
<v Speaker 2>these data for the website you don't need you don't need,

65
00:02:57.039 --> 00:02:59.879
<v Speaker 2>but you have to download it processed and you know,

66
00:03:00.080 --> 00:03:02.400
<v Speaker 2>use the network for that. So graph Gale tries to

67
00:03:02.479 --> 00:03:05.560
<v Speaker 2>solve this problem. You can get any data you want,

68
00:03:05.719 --> 00:03:08.039
<v Speaker 2>but you don't get any additional data that you don't

69
00:03:08.039 --> 00:03:11.520
<v Speaker 2>want to get. The special benefit to get from graphical

70
00:03:11.719 --> 00:03:15.479
<v Speaker 2>is the documentation, because the heart of the graph Kale

71
00:03:15.520 --> 00:03:19.080
<v Speaker 2>system is it's schema. Schemo defies your graph So you

72
00:03:19.199 --> 00:03:22.280
<v Speaker 2>have a list of entities which are called tag and

73
00:03:22.319 --> 00:03:24.919
<v Speaker 2>these steps can have connections between each other. So you

74
00:03:25.039 --> 00:03:28.400
<v Speaker 2>have all these connections described and you know what data

75
00:03:28.479 --> 00:03:30.639
<v Speaker 2>can you get from each point. And in this case

76
00:03:30.680 --> 00:03:33.599
<v Speaker 2>you don't need to have the separate documentation because you

77
00:03:33.639 --> 00:03:35.800
<v Speaker 2>already have it. You just need to explain what does

78
00:03:35.840 --> 00:03:37.960
<v Speaker 2>it mean in your system? For instance, what is the user,

79
00:03:38.039 --> 00:03:40.560
<v Speaker 2>what is customer? All this stuff and that's it. You

80
00:03:40.560 --> 00:03:43.439
<v Speaker 2>cannot have the outdated decommindation because in this case your

81
00:03:43.479 --> 00:03:46.280
<v Speaker 2>graphical system just won't work at all. So I guess

82
00:03:46.360 --> 00:03:48.759
<v Speaker 2>that's the main setting point for me. And also one

83
00:03:48.879 --> 00:03:51.120
<v Speaker 2>more thing, but not the last one. I guess there

84
00:03:51.199 --> 00:03:54.800
<v Speaker 2>is a special thing called subscriptions. Sometimes you don't want

85
00:03:54.840 --> 00:03:56.960
<v Speaker 2>to get the data right now, but you want to

86
00:03:57.000 --> 00:03:59.719
<v Speaker 2>get the updates, for instance, new messages in the chart

87
00:03:59.879 --> 00:04:02.199
<v Speaker 2>or new notifications of the stuff. And when you work

88
00:04:02.199 --> 00:04:04.680
<v Speaker 2>with the rest, you have to build something from scratch,

89
00:04:04.800 --> 00:04:07.840
<v Speaker 2>like make the ajax request make all ink makes sockets

90
00:04:07.879 --> 00:04:11.159
<v Speaker 2>by yourself all the stop. Graphicel solves this problem by subscriptions.

91
00:04:11.199 --> 00:04:13.520
<v Speaker 2>In this case you can describe the where you want

92
00:04:13.560 --> 00:04:16.600
<v Speaker 2>to make and wait until the event happens. In this case,

93
00:04:16.639 --> 00:04:19.639
<v Speaker 2>graph kill would send the data to you and you

94
00:04:19.680 --> 00:04:22.079
<v Speaker 2>don't need to think about how it came to your

95
00:04:22.079 --> 00:04:25.639
<v Speaker 2>ilientification because it doesn't really make any difference between the

96
00:04:25.759 --> 00:04:28.560
<v Speaker 2>regular quay or subscription call. And this is the part

97
00:04:28.600 --> 00:04:31.079
<v Speaker 2>of the technologies, so you do not even need to

98
00:04:31.160 --> 00:04:33.920
<v Speaker 2>care about how it works because it's usually a part

99
00:04:33.959 --> 00:04:36.720
<v Speaker 2>of the library. You think that's the benefits of GRAPHAEL.

100
00:04:36.759 --> 00:04:38.319
<v Speaker 2>I wanted to mention to kick it off.

101
00:04:38.439 --> 00:04:41.040
<v Speaker 1>I'm a little curious as we get going, John Luke

102
00:04:41.079 --> 00:04:43.560
<v Speaker 1>and Dave, what all have you done with graph ql.

103
00:04:43.519 --> 00:04:47.600
<v Speaker 4>You mean, other than avoid it or complain about it. Yeah,

104
00:04:47.759 --> 00:04:50.600
<v Speaker 4>now I'm joking. So I think that graph qul is

105
00:04:50.639 --> 00:04:54.279
<v Speaker 4>really cool from the perspective, like Dmitri was saying, it

106
00:04:54.360 --> 00:04:58.600
<v Speaker 4>has a lot of benefits, especially to end users consuming

107
00:04:58.680 --> 00:05:02.560
<v Speaker 4>the API where where they can only really fetch the

108
00:05:02.720 --> 00:05:06.160
<v Speaker 4>data that they need, not everything, especially when you're talking

109
00:05:06.199 --> 00:05:10.639
<v Speaker 4>about really large data sets and really complicated data sets

110
00:05:10.839 --> 00:05:15.639
<v Speaker 4>which maybe have a lot of associations associated with the

111
00:05:15.680 --> 00:05:18.240
<v Speaker 4>main record that you were wanting to get back. So

112
00:05:18.600 --> 00:05:21.680
<v Speaker 4>having the ability to just make one API call to

113
00:05:21.839 --> 00:05:25.439
<v Speaker 4>this back end application serving graphic well is really nice

114
00:05:25.519 --> 00:05:28.319
<v Speaker 4>opposed to having to make ten different calls. So not

115
00:05:28.399 --> 00:05:32.519
<v Speaker 4>only is that more efficient from the perspective of one

116
00:05:32.639 --> 00:05:37.839
<v Speaker 4>verse ten calls, but you also then have more ability

117
00:05:37.920 --> 00:05:41.360
<v Speaker 4>to let's say pull it often, especially if the back

118
00:05:41.439 --> 00:05:44.279
<v Speaker 4>end has some kind of rate limitter and in order

119
00:05:44.319 --> 00:05:47.319
<v Speaker 4>to serve this one page or this one application, you

120
00:05:47.439 --> 00:05:51.120
<v Speaker 4>had to make fifteen to twenty simultaneous requests to get

121
00:05:51.120 --> 00:05:53.519
<v Speaker 4>all that data. Well, if you're doing any kind of

122
00:05:53.600 --> 00:05:57.319
<v Speaker 4>rack attack or rate limiting, then you were consuming twenty

123
00:05:57.399 --> 00:06:00.720
<v Speaker 4>times for just one page, you know. So it definitely

124
00:06:00.720 --> 00:06:03.920
<v Speaker 4>has some benefits from that perspective. But now here's my

125
00:06:04.000 --> 00:06:08.240
<v Speaker 4>big buttz. Despite all of those glorious benefits, I think

126
00:06:08.360 --> 00:06:11.759
<v Speaker 4>if I am developing a API back end that's going

127
00:06:11.800 --> 00:06:16.040
<v Speaker 4>to be consumed by an internal or an iOS or

128
00:06:16.160 --> 00:06:20.120
<v Speaker 4>Android application that I'm publishing to the store, or by

129
00:06:20.199 --> 00:06:24.879
<v Speaker 4>another in house product or by a third party who

130
00:06:25.040 --> 00:06:28.920
<v Speaker 4>is very comfortable with working with rest APIs, I'm going

131
00:06:29.000 --> 00:06:31.600
<v Speaker 4>to go with RESPI every day. But if I am

132
00:06:31.680 --> 00:06:35.879
<v Speaker 4>going to create a API that I'm expecting all of

133
00:06:35.920 --> 00:06:40.600
<v Speaker 4>my customers or users of the application to heavily write

134
00:06:40.680 --> 00:06:44.160
<v Speaker 4>their own interfaces to everything. I'm just really providing a

135
00:06:44.319 --> 00:06:48.519
<v Speaker 4>data source in a formatted way. Then Rephkuel might make

136
00:06:48.560 --> 00:06:49.759
<v Speaker 4>a bit more sense.

137
00:06:50.120 --> 00:06:52.639
<v Speaker 2>I can totally agree with Dave, and there is no

138
00:06:52.759 --> 00:06:55.839
<v Speaker 2>reason to just start writing all the applications we have

139
00:06:56.160 --> 00:06:58.519
<v Speaker 2>with golf kill. And also if you have a client

140
00:06:58.600 --> 00:07:01.399
<v Speaker 2>that wants to work with REST and if it's still

141
00:07:01.399 --> 00:07:04.240
<v Speaker 2>comfortable to work with the REST, that's completely fine, I guess.

142
00:07:04.240 --> 00:07:06.680
<v Speaker 2>But sometimes it makes sense to start new projects with

143
00:07:06.720 --> 00:07:08.920
<v Speaker 2>the graph Gale even if you don't have any experience

144
00:07:08.920 --> 00:07:12.000
<v Speaker 2>with it at all, because sometimes you can find benefits.

145
00:07:12.040 --> 00:07:14.199
<v Speaker 2>And by the way, there is a special trick in

146
00:07:14.240 --> 00:07:17.160
<v Speaker 2>graph Gale which I also to awoid all these different

147
00:07:17.160 --> 00:07:20.560
<v Speaker 2>small requests, which is called batching. I guess all modern

148
00:07:20.759 --> 00:07:23.360
<v Speaker 2>front and trap cal frame A frameworks can do that.

149
00:07:23.560 --> 00:07:28.759
<v Speaker 2>Batching is a thing that doesn't immediately make. It just

150
00:07:28.879 --> 00:07:31.600
<v Speaker 2>builds a lest of requests and send then once, let's

151
00:07:31.639 --> 00:07:34.160
<v Speaker 2>say once a second or something. It helps a lot

152
00:07:34.199 --> 00:07:36.600
<v Speaker 2>when you have to render a lot of things from

153
00:07:36.639 --> 00:07:38.600
<v Speaker 2>the same page, at least in the initial lot.

154
00:07:38.800 --> 00:07:41.759
<v Speaker 5>Yeah, I don't disagree with save at all. I think

155
00:07:42.000 --> 00:07:44.959
<v Speaker 5>for whatever reason, maybe this has always gone on. But

156
00:07:45.000 --> 00:07:46.800
<v Speaker 5>I feel like the last few years there's been a

157
00:07:46.800 --> 00:07:49.839
<v Speaker 5>lot of hey suite new tech comes out, like I

158
00:07:49.879 --> 00:07:52.959
<v Speaker 5>have this new hammer and everything is a nail. And

159
00:07:53.399 --> 00:07:56.160
<v Speaker 5>I feel like graph cel totally was a thing like that,

160
00:07:56.199 --> 00:07:59.360
<v Speaker 5>where everyone was using graph qol for everything, even when

161
00:07:59.600 --> 00:08:02.720
<v Speaker 5>I could find any of the benefits of graph ql

162
00:08:02.759 --> 00:08:04.680
<v Speaker 5>lining up with their problems right Like it was like

163
00:08:04.759 --> 00:08:09.519
<v Speaker 5>everyone using Mango to try and replicate relational databases, which

164
00:08:09.680 --> 00:08:10.680
<v Speaker 5>Mongo is not good at.

165
00:08:10.800 --> 00:08:12.319
<v Speaker 3>You know, that's my only beef.

166
00:08:12.360 --> 00:08:14.720
<v Speaker 5>I think that graph ql is awesome to be frank,

167
00:08:14.800 --> 00:08:18.279
<v Speaker 5>I've even said before and I still think it's probably true.

168
00:08:18.439 --> 00:08:19.639
<v Speaker 3>So REST is kind.

169
00:08:19.480 --> 00:08:23.240
<v Speaker 5>Of like a standard, right graph Ql is a technology,

170
00:08:23.319 --> 00:08:26.160
<v Speaker 5>and I think that distinction, to me is important because

171
00:08:26.160 --> 00:08:28.319
<v Speaker 5>if we can create a standard on top of graph

172
00:08:28.399 --> 00:08:30.560
<v Speaker 5>ql that looks a little bit more like REST, I

173
00:08:30.600 --> 00:08:33.240
<v Speaker 5>think that, in my opinion, I think it's likely that

174
00:08:33.320 --> 00:08:35.240
<v Speaker 5>we'll see that graph ql is a lot more powerful

175
00:08:35.240 --> 00:08:36.399
<v Speaker 5>than it looks right now.

176
00:08:36.399 --> 00:08:38.320
<v Speaker 3>Because to me, it looks very wild westy.

177
00:08:38.440 --> 00:08:41.519
<v Speaker 5>It's like, you have this cool new technology and everyone's

178
00:08:41.639 --> 00:08:44.399
<v Speaker 5>all over the place with it, and so it's just

179
00:08:44.480 --> 00:08:47.559
<v Speaker 5>a gigantic mess, and everyone's blaming the technology instead of

180
00:08:47.559 --> 00:08:49.679
<v Speaker 5>blaming the discipline of the people that are using the

181
00:08:49.720 --> 00:08:52.240
<v Speaker 5>technology that to me appears to be the source of

182
00:08:52.279 --> 00:08:54.440
<v Speaker 5>most of the problems. I've only used it on toy

183
00:08:54.480 --> 00:08:57.720
<v Speaker 5>apps so far. I haven't actually had a real problem

184
00:08:57.720 --> 00:09:00.759
<v Speaker 5>in my life that made sense to match it up with. Yeah,

185
00:09:00.799 --> 00:09:02.879
<v Speaker 5>but I still think it's sweet. It changes the way

186
00:09:02.879 --> 00:09:03.720
<v Speaker 5>that I think about things.

187
00:09:03.720 --> 00:09:05.879
<v Speaker 1>At the very least, Luke, have you done anything with

188
00:09:05.960 --> 00:09:06.759
<v Speaker 1>graph you are no.

189
00:09:06.879 --> 00:09:09.840
<v Speaker 6>I interviewed for a position with a company that made.

190
00:09:09.679 --> 00:09:13.840
<v Speaker 7>White label, white label apps and they were heavily in

191
00:09:13.879 --> 00:09:18.120
<v Speaker 7>the UK. They were heavily heavily into their GRAPHQL, and

192
00:09:18.600 --> 00:09:21.320
<v Speaker 7>I was talking to CTO and asked him why because

193
00:09:21.360 --> 00:09:23.559
<v Speaker 7>again there were a rail shop why they kind of

194
00:09:23.600 --> 00:09:28.240
<v Speaker 7>put everything into GRAPHQL. And they were very mobile focused,

195
00:09:28.360 --> 00:09:31.440
<v Speaker 7>and they felt that one of the benefits from using

196
00:09:31.600 --> 00:09:34.360
<v Speaker 7>graph ca OB was the kind of huge benefit on mobile,

197
00:09:34.480 --> 00:09:39.120
<v Speaker 7>especially with more efficient network usage. So for them, any

198
00:09:39.159 --> 00:09:42.240
<v Speaker 7>amount of complexity was worth the trade off to get

199
00:09:42.240 --> 00:09:45.360
<v Speaker 7>their apps running more responsive. So the fact it was

200
00:09:45.360 --> 00:09:47.639
<v Speaker 7>a kind of a newer technology didn't care. They just

201
00:09:47.679 --> 00:09:50.679
<v Speaker 7>wanted that improved customer experience. So I'm really interested to

202
00:09:50.759 --> 00:09:53.440
<v Speaker 7>hear what Dmitri's saying, where you're saying this is not

203
00:09:53.639 --> 00:09:57.000
<v Speaker 7>just about efficiency, this is actually a better way of

204
00:09:57.240 --> 00:10:01.120
<v Speaker 7>organizing the interface between the client in the server. And

205
00:10:01.200 --> 00:10:04.240
<v Speaker 7>I think you said something like having a schema was

206
00:10:04.279 --> 00:10:07.279
<v Speaker 7>one of the big winds which you don't get with

207
00:10:07.440 --> 00:10:10.840
<v Speaker 7>the rest based at So it's interesting to hear what

208
00:10:10.960 --> 00:10:14.120
<v Speaker 7>why isn't didn't schemers go away with XML?

209
00:10:14.440 --> 00:10:16.679
<v Speaker 6>That was the last time I had to deal with schemers.

210
00:10:16.720 --> 00:10:18.240
<v Speaker 6>Are schemer is good now?

211
00:10:18.600 --> 00:10:21.000
<v Speaker 2>Yeah, that's a good question, and I totally agree that

212
00:10:21.039 --> 00:10:23.759
<v Speaker 2>it sounds like the more schema, but yeah, schemers are

213
00:10:23.879 --> 00:10:27.000
<v Speaker 2>better now. I guess I'm too young to understand all

214
00:10:27.000 --> 00:10:29.679
<v Speaker 2>the pain with schemes because I didn't work with them

215
00:10:29.679 --> 00:10:32.919
<v Speaker 2>a lot. But yeah, the schema language in Garcao is

216
00:10:33.039 --> 00:10:36.360
<v Speaker 2>very simple, looks like Gison, just regular gson. You just

217
00:10:36.440 --> 00:10:40.039
<v Speaker 2>define a type, you just call type user and define

218
00:10:40.080 --> 00:10:42.960
<v Speaker 2>list of fields like title is string and I don't know,

219
00:10:43.159 --> 00:10:45.960
<v Speaker 2>orders is a list of order which where order is

220
00:10:46.000 --> 00:10:48.639
<v Speaker 2>another type for instance. And they said you define all

221
00:10:48.679 --> 00:10:51.919
<v Speaker 2>this stuff with text and for instance, in Ruby you

222
00:10:51.960 --> 00:10:54.399
<v Speaker 2>don't even have to define the scheme by yourself. You

223
00:10:54.480 --> 00:10:57.480
<v Speaker 2>just define classes and it makes all the magic behind

224
00:10:57.519 --> 00:10:59.559
<v Speaker 2>the skins. You don't need to do anything at all.

225
00:10:59.600 --> 00:11:02.799
<v Speaker 2>And then you can use this schema to center your clients.

226
00:11:02.840 --> 00:11:06.600
<v Speaker 2>For instance, some i ET tools use scheme must have

227
00:11:06.759 --> 00:11:09.559
<v Speaker 2>nice autocomplete and will date to e client request that

228
00:11:09.799 --> 00:11:12.200
<v Speaker 2>they at least quest the fields you have, for instance.

229
00:11:12.240 --> 00:11:14.759
<v Speaker 2>And also you can use any intercommutation tool you want

230
00:11:14.799 --> 00:11:17.399
<v Speaker 2>to just show the place where you can find the

231
00:11:17.559 --> 00:11:21.600
<v Speaker 2>chema and it will show abutal screened with all the fields, connections, types,

232
00:11:21.639 --> 00:11:22.279
<v Speaker 2>all that stuff.

233
00:11:22.480 --> 00:11:24.840
<v Speaker 1>Yeah, now, speaking of the schema, I mean, this was

234
00:11:24.879 --> 00:11:27.039
<v Speaker 1>the painful part at least when I've laid with graph

235
00:11:27.159 --> 00:11:30.919
<v Speaker 1>QL in rails, is that I wind up essentially fighting

236
00:11:30.960 --> 00:11:32.600
<v Speaker 1>the engine a little bit because I have to set

237
00:11:32.639 --> 00:11:35.320
<v Speaker 1>up that schema for every type in the system. It

238
00:11:35.480 --> 00:11:37.639
<v Speaker 1>you know, at least, and I haven't tried it for

239
00:11:37.679 --> 00:11:39.559
<v Speaker 1>a year or so, so the tooling might have gotten better.

240
00:11:39.600 --> 00:11:41.480
<v Speaker 1>But yeah, so essentially I had to tell it. You know,

241
00:11:41.559 --> 00:11:44.440
<v Speaker 1>the user's name is a string, and the user's user

242
00:11:44.519 --> 00:11:46.600
<v Speaker 1>name is a string, and the users you know this

243
00:11:46.639 --> 00:11:48.759
<v Speaker 1>that and the other is a number, and you know,

244
00:11:49.000 --> 00:11:51.440
<v Speaker 1>in RAILS, if you're doing rest it just kind of

245
00:11:51.559 --> 00:11:53.279
<v Speaker 1>all works, you know, and I didn't have to do

246
00:11:53.320 --> 00:11:55.919
<v Speaker 1>any extra work to get that kind of an endpoint

247
00:11:56.080 --> 00:11:59.919
<v Speaker 1>up within GRAPHQL. So yeah, that's my major beef with it.

248
00:11:59.879 --> 00:12:01.799
<v Speaker 1>It's just that it created a whole bunch of work

249
00:12:01.840 --> 00:12:03.200
<v Speaker 1>on the back end that I wouldn't have had to

250
00:12:03.279 --> 00:12:04.320
<v Speaker 1>do if I was doing rest.

251
00:12:04.559 --> 00:12:06.360
<v Speaker 5>I may argue you had to do that on the

252
00:12:06.399 --> 00:12:08.559
<v Speaker 5>front end, right, because you got all that through Jason.

253
00:12:08.840 --> 00:12:11.159
<v Speaker 5>It was all the string and then you had to decide, well,

254
00:12:11.320 --> 00:12:13.639
<v Speaker 5>what is this? Is this the number? Should I be

255
00:12:13.639 --> 00:12:16.320
<v Speaker 5>parsing ends, you know, or is this actually a string

256
00:12:16.440 --> 00:12:18.519
<v Speaker 5>or is it something else? If it was objects, you

257
00:12:18.559 --> 00:12:20.840
<v Speaker 5>were cool. But otherwise, yeah, you had to play with

258
00:12:20.919 --> 00:12:21.279
<v Speaker 5>it there.

259
00:12:21.679 --> 00:12:24.039
<v Speaker 1>Yes, and no, I mean I agree with you, and

260
00:12:24.120 --> 00:12:26.519
<v Speaker 1>I don't. One thing that JavaScript has going for it

261
00:12:26.559 --> 00:12:30.000
<v Speaker 1>is coercion, and so it winds up doing a lot

262
00:12:30.080 --> 00:12:32.480
<v Speaker 1>of the you know, it winds up doing a lot

263
00:12:32.519 --> 00:12:34.639
<v Speaker 1>of the work for you on that front right, And

264
00:12:34.679 --> 00:12:38.519
<v Speaker 1>so unless you need like some very specific functionality out

265
00:12:38.519 --> 00:12:40.840
<v Speaker 1>of it, you can just count on you know, JavaScript

266
00:12:40.919 --> 00:12:43.320
<v Speaker 1>doing the right thing when you do a coercive comparison

267
00:12:43.399 --> 00:12:45.919
<v Speaker 1>or things like that. And so, yeah, I don't do

268
00:12:46.039 --> 00:12:48.240
<v Speaker 1>a lot of type casting in JavaScript. So for the

269
00:12:48.240 --> 00:12:50.440
<v Speaker 1>most part, that doesn't matter as much to me.

270
00:12:50.600 --> 00:12:52.639
<v Speaker 5>Yeah, I don't want to pretend like I had to

271
00:12:52.639 --> 00:12:54.000
<v Speaker 5>do it all the time, but it was a thing

272
00:12:54.000 --> 00:12:56.440
<v Speaker 5>that I did have to care about more often than

273
00:12:56.480 --> 00:12:59.200
<v Speaker 5>I wanted to. Probably at least a few times a

274
00:12:59.279 --> 00:13:01.799
<v Speaker 5>year I was dealing with something where I was doing

275
00:13:01.799 --> 00:13:04.759
<v Speaker 5>a comparison or something and you know, for whatever reason,

276
00:13:04.840 --> 00:13:06.960
<v Speaker 5>something that came from data was still a string and

277
00:13:07.000 --> 00:13:08.559
<v Speaker 5>I had to fix that.

278
00:13:08.919 --> 00:13:12.159
<v Speaker 2>And also, when you work with playing rails and you

279
00:13:12.200 --> 00:13:15.360
<v Speaker 2>want to set up some kind of recommendation, for instance, swagger,

280
00:13:15.480 --> 00:13:19.279
<v Speaker 2>you have to write all these comments near your actions

281
00:13:19.399 --> 00:13:21.720
<v Speaker 2>by hand, and there is a chance that you'll forget

282
00:13:21.759 --> 00:13:25.159
<v Speaker 2>to change anything and your swagger will be outdated and

283
00:13:25.159 --> 00:13:27.200
<v Speaker 2>no one will not end. When you have schemas, there

284
00:13:27.240 --> 00:13:29.240
<v Speaker 2>is no chance that it will be outdated because it's

285
00:13:29.240 --> 00:13:31.799
<v Speaker 2>your schema that's used for peputing your cold.

286
00:13:32.240 --> 00:13:34.279
<v Speaker 5>So going down the schema route a little bit more.

287
00:13:34.399 --> 00:13:36.679
<v Speaker 5>I used to use soap back in the day, and

288
00:13:36.919 --> 00:13:38.200
<v Speaker 5>I mean, I don't miss it at all.

289
00:13:38.320 --> 00:13:39.679
<v Speaker 1>This is me crying for you.

290
00:13:41.200 --> 00:13:43.360
<v Speaker 5>I don't miss it at all. But this isn't my

291
00:13:43.399 --> 00:13:46.320
<v Speaker 5>first rodeo with schemas. Sorry, I guess alets of thinks

292
00:13:46.360 --> 00:13:48.399
<v Speaker 5>I'm talking to her because I said soap.

293
00:13:48.519 --> 00:13:49.360
<v Speaker 3>I don't know whatever.

294
00:13:49.440 --> 00:13:51.120
<v Speaker 5>Anyway, I used to use so back in the day,

295
00:13:51.200 --> 00:13:54.919
<v Speaker 5>And I mean, there's some benefits that you get with schemas,

296
00:13:54.960 --> 00:13:57.279
<v Speaker 5>which I think is kind of what you're talking about here.

297
00:13:57.480 --> 00:14:00.000
<v Speaker 3>For me, the main thing that I.

298
00:13:59.679 --> 00:14:04.200
<v Speaker 5>Always felt like with schemas is I could pull information

299
00:14:04.279 --> 00:14:06.799
<v Speaker 5>from a completely new source. But I know that you're

300
00:14:06.840 --> 00:14:08.360
<v Speaker 5>not doing this all the time, but I could. I

301
00:14:08.360 --> 00:14:10.679
<v Speaker 5>could know nothing about what was going on underneath, but

302
00:14:10.720 --> 00:14:13.120
<v Speaker 5>I knew everything that I was allowed to do. That's

303
00:14:13.120 --> 00:14:16.399
<v Speaker 5>a lot harder to do with, you know, RESTful APIs as.

304
00:14:16.600 --> 00:14:19.360
<v Speaker 5>You know, we don't really provide that kind of thing.

305
00:14:19.480 --> 00:14:21.559
<v Speaker 5>It's not impossible to do. I guess you could provide

306
00:14:21.559 --> 00:14:23.720
<v Speaker 5>a page that does that or something, but nobody. It's

307
00:14:23.720 --> 00:14:26.799
<v Speaker 5>not a standard by any means. But I guess why.

308
00:14:26.840 --> 00:14:30.639
<v Speaker 5>For me, I can see benefits to it, and I

309
00:14:30.919 --> 00:14:34.320
<v Speaker 5>feel like people are happy with the exchange when they're

310
00:14:34.360 --> 00:14:38.039
<v Speaker 5>doing graph QL. Can you talk more about like why

311
00:14:38.320 --> 00:14:40.360
<v Speaker 5>the schema in this case is a good thing as

312
00:14:40.360 --> 00:14:43.559
<v Speaker 5>opposed to like soap where I always felt and Charles's

313
00:14:43.639 --> 00:14:46.320
<v Speaker 5>actually just Chuck just expressed this a few minutes ago,

314
00:14:46.399 --> 00:14:48.519
<v Speaker 5>He's like, well, I hate that. In rails, I had

315
00:14:48.559 --> 00:14:50.720
<v Speaker 5>to like do all this setup like every time, right,

316
00:14:50.799 --> 00:14:53.879
<v Speaker 5>Like we really hate writing boilerplate. That's why we write rails, right,

317
00:14:54.039 --> 00:14:58.039
<v Speaker 5>So why is this exchange good? I guess, Like, what

318
00:14:58.120 --> 00:14:59.600
<v Speaker 5>are we buying an exchange for it?

319
00:15:00.039 --> 00:15:02.320
<v Speaker 2>Well? I get. The problem is that in graph kill

320
00:15:02.440 --> 00:15:05.919
<v Speaker 2>World world, they prefer things to be explicit, So they

321
00:15:05.960 --> 00:15:08.000
<v Speaker 2>want you to define the list of fields you want

322
00:15:08.039 --> 00:15:10.120
<v Speaker 2>to fetch. The list to fills you a lot to

323
00:15:10.120 --> 00:15:12.639
<v Speaker 2>fetch all that stuff. And it could be possible to

324
00:15:12.720 --> 00:15:15.799
<v Speaker 2>just generate the list of fields based on your table structure.

325
00:15:15.879 --> 00:15:18.559
<v Speaker 2>That's not impossible. I believe there is even a gem

326
00:15:18.639 --> 00:15:21.720
<v Speaker 2>for that. But there is a huge benefit from having

327
00:15:21.759 --> 00:15:24.039
<v Speaker 2>a schema. When you want to change your data in

328
00:15:24.200 --> 00:15:28.039
<v Speaker 2>graph kiell World, it's called mutations. Mutation is a special

329
00:15:28.200 --> 00:15:31.440
<v Speaker 2>way that can change your data, and it looks like

330
00:15:31.559 --> 00:15:34.600
<v Speaker 2>a regular query, but it's usually expected to change the

331
00:15:34.679 --> 00:15:36.480
<v Speaker 2>data on the back and set. And the thing is

332
00:15:36.519 --> 00:15:39.559
<v Speaker 2>that when you define arguments. For instance, you want to

333
00:15:39.639 --> 00:15:43.240
<v Speaker 2>change the price of the item for your Internet store,

334
00:15:43.480 --> 00:15:45.960
<v Speaker 2>and you want this price to be numbered, and you

335
00:15:46.080 --> 00:15:48.559
<v Speaker 2>want it to be required. You can be sure that

336
00:15:48.639 --> 00:15:51.879
<v Speaker 2>it will be present in the arrangers, because otherwise graph

337
00:15:52.159 --> 00:15:54.799
<v Speaker 2>execution engine will just send the error to the client

338
00:15:54.919 --> 00:15:58.000
<v Speaker 2>telling him that he's wrong. So from the one point

339
00:15:58.000 --> 00:16:01.519
<v Speaker 2>of view, you're at some boilerpred But from the other hand,

340
00:16:01.600 --> 00:16:03.919
<v Speaker 2>you just remove the part when you avalidate the data

341
00:16:03.960 --> 00:16:06.480
<v Speaker 2>because you can ask your execution engine to make it

342
00:16:06.679 --> 00:16:08.159
<v Speaker 2>to make all the checks you want for you. I

343
00:16:08.159 --> 00:16:09.919
<v Speaker 2>think that's fair exchange.

344
00:16:10.039 --> 00:16:12.759
<v Speaker 3>So is the big bonus then on the writing side,

345
00:16:12.799 --> 00:16:13.679
<v Speaker 3>is that what we're saying.

346
00:16:13.840 --> 00:16:16.879
<v Speaker 2>Yeah, that's one of the benefits of having schema because

347
00:16:16.879 --> 00:16:19.279
<v Speaker 2>you can make sure that things that you expect will

348
00:16:19.399 --> 00:16:21.679
<v Speaker 2>arrive in a way that you're described in your cinema.

349
00:16:21.799 --> 00:16:25.480
<v Speaker 4>Yeah, it's been a year since I've really touched graphql,

350
00:16:25.519 --> 00:16:28.200
<v Speaker 4>but back when I did, one of the biggest issues

351
00:16:28.240 --> 00:16:31.080
<v Speaker 4>that I had with it is that my code wasn't pretty.

352
00:16:31.200 --> 00:16:36.120
<v Speaker 4>It seemed like Graphql complicated it beyond what a res

353
00:16:36.200 --> 00:16:39.759
<v Speaker 4>API would do, and from that perspective, I just found

354
00:16:39.799 --> 00:16:44.559
<v Speaker 4>it easier and more maintainable to stick with res api

355
00:16:44.759 --> 00:16:48.720
<v Speaker 4>despite some of the benefits that graphql provided. Now I

356
00:16:48.759 --> 00:16:51.919
<v Speaker 4>know that with I believe Facebook created the concept of

357
00:16:51.960 --> 00:16:55.600
<v Speaker 4>graphul or created graphic youl, and what they were dealing

358
00:16:55.639 --> 00:17:00.080
<v Speaker 4>with I'm sure is a lot worse than what graphql provides.

359
00:17:00.120 --> 00:17:03.320
<v Speaker 4>But I think with what Rails provides just out of

360
00:17:03.360 --> 00:17:07.319
<v Speaker 4>the box, or with just one or two serializer gems,

361
00:17:07.559 --> 00:17:11.440
<v Speaker 4>then you have a much cleaner look without the graph

362
00:17:11.519 --> 00:17:13.000
<v Speaker 4>Ql and just stick with the rest.

363
00:17:13.440 --> 00:17:16.599
<v Speaker 2>So ft correctly, you mean that you don't like the code.

364
00:17:16.640 --> 00:17:20.920
<v Speaker 2>You're right. When you're writing craft, you know we'll be right. Yeah, basically, Yeah,

365
00:17:20.920 --> 00:17:23.119
<v Speaker 2>I guess it's a much taste, and I can agree

366
00:17:23.160 --> 00:17:25.319
<v Speaker 2>that writing a list of fields each time we had

367
00:17:25.440 --> 00:17:27.599
<v Speaker 2>a new entity can be not that great as a

368
00:17:27.839 --> 00:17:28.640
<v Speaker 2>developer experience.

369
00:17:28.839 --> 00:17:31.400
<v Speaker 1>Well, it wasn't just that for me. It was writing

370
00:17:31.440 --> 00:17:33.599
<v Speaker 1>the fields and then writing the resolvers for all the

371
00:17:33.680 --> 00:17:35.759
<v Speaker 1>extra stuff. I mean, it felt like it added a

372
00:17:35.839 --> 00:17:37.440
<v Speaker 1>ton of work that I wouldn't have to do if

373
00:17:37.440 --> 00:17:38.200
<v Speaker 1>I was doing rest.

374
00:17:38.440 --> 00:17:41.680
<v Speaker 4>Yeah. I think the gym that was really popular a

375
00:17:41.799 --> 00:17:44.319
<v Speaker 4>year or so ago for graph ql had a very

376
00:17:44.519 --> 00:17:47.680
<v Speaker 4>strange DSL that they used, or at least it just

377
00:17:47.759 --> 00:17:51.559
<v Speaker 4>seemed like it was over complicated, but that was probably

378
00:17:51.680 --> 00:17:54.839
<v Speaker 4>just due to the necessities of what was required by

379
00:17:55.000 --> 00:17:55.640
<v Speaker 4>graph Ql.

380
00:17:55.880 --> 00:17:58.119
<v Speaker 7>I'm going to ask some really dumb questions here, so

381
00:17:58.440 --> 00:18:01.880
<v Speaker 7>stand by all right, is running the graph ql. I've

382
00:18:01.960 --> 00:18:05.119
<v Speaker 7>looked at it and I don't quite understand. I understand

383
00:18:05.160 --> 00:18:08.240
<v Speaker 7>the process. You put your scheme together, you write some

384
00:18:08.319 --> 00:18:09.079
<v Speaker 7>supporting code.

385
00:18:09.240 --> 00:18:10.519
<v Speaker 6>Yeah, is the graph.

386
00:18:10.400 --> 00:18:13.920
<v Speaker 7>Col query hitting that can't hit rails directly, can it?

387
00:18:14.039 --> 00:18:17.079
<v Speaker 7>It's going through something? Is it hitting a node server

388
00:18:17.319 --> 00:18:18.119
<v Speaker 7>running on the server?

389
00:18:18.480 --> 00:18:18.519
<v Speaker 6>No.

390
00:18:18.720 --> 00:18:23.599
<v Speaker 4>Graph qul is basically just a as John mentioned technology,

391
00:18:23.720 --> 00:18:27.119
<v Speaker 4>So you're not having to parse it through another service,

392
00:18:27.319 --> 00:18:30.400
<v Speaker 4>per se or external service. It's just you have a

393
00:18:30.519 --> 00:18:34.279
<v Speaker 4>standard of what the graph ql should be structured as

394
00:18:34.519 --> 00:18:38.400
<v Speaker 4>as it's consumed and how you are posting back to

395
00:18:38.599 --> 00:18:42.079
<v Speaker 4>it for mutable changes and requests and stuff. But it's

396
00:18:42.119 --> 00:18:45.559
<v Speaker 4>not actually going through a external service or anything.

397
00:18:45.880 --> 00:18:49.039
<v Speaker 3>It could. But your rail server can also be your

398
00:18:49.079 --> 00:18:49.880
<v Speaker 3>graphul server.

399
00:18:50.160 --> 00:18:53.759
<v Speaker 1>Yeah, it just translates it down into calls through your model,

400
00:18:53.880 --> 00:18:54.880
<v Speaker 1>just like anything else.

401
00:18:55.279 --> 00:18:57.839
<v Speaker 5>It's kind of like you could pick Puma, or you

402
00:18:57.920 --> 00:19:00.559
<v Speaker 5>could run a patche or engine X. Whatever you want

403
00:19:00.640 --> 00:19:02.799
<v Speaker 5>can be your web server. You just have to adhere

404
00:19:02.839 --> 00:19:04.480
<v Speaker 5>to certain things in order to be that.

405
00:19:04.880 --> 00:19:08.160
<v Speaker 7>Oh this is my my weird bit, one of my

406
00:19:08.240 --> 00:19:11.599
<v Speaker 7>weird bits for this week. So I've been working on. Noticeably,

407
00:19:11.720 --> 00:19:14.559
<v Speaker 7>graph kill has got a kind of subscription service you mentioned,

408
00:19:14.599 --> 00:19:17.680
<v Speaker 7>which looks like a kind of web sockets based live updates.

409
00:19:17.799 --> 00:19:21.240
<v Speaker 7>I've been trying to make my own without using web sockets,

410
00:19:21.559 --> 00:19:24.920
<v Speaker 7>using a long pulling and I was using Finn because

411
00:19:24.960 --> 00:19:28.119
<v Speaker 7>it's quite easy to use Finn to do asynchronous staff

412
00:19:28.279 --> 00:19:32.160
<v Speaker 7>using event machine. But Finn appears to be missing, presumed dead,

413
00:19:32.279 --> 00:19:35.240
<v Speaker 7>and everyone's using Puma now right, you're getting nods here,

414
00:19:35.400 --> 00:19:36.599
<v Speaker 7>so event machine.

415
00:19:36.480 --> 00:19:38.160
<v Speaker 1>Yeah, I guess people can't hear my nods.

416
00:19:38.279 --> 00:19:40.759
<v Speaker 6>Yes, yeah, yeah, there's an absolutely agreement.

417
00:19:40.920 --> 00:19:43.640
<v Speaker 7>So I've been trying to get you working using the

418
00:19:44.359 --> 00:19:46.920
<v Speaker 7>rack hijack, yeah, which is the kind of way of

419
00:19:47.039 --> 00:19:50.279
<v Speaker 7>keeping a connection open with Puma. My word, that is

420
00:19:50.319 --> 00:19:53.240
<v Speaker 7>a total nightmare. I can't tell you how long. I mean,

421
00:19:53.279 --> 00:19:55.759
<v Speaker 7>it was took me to about two am to six

422
00:19:55.799 --> 00:19:59.000
<v Speaker 7>am to get a hijack working. And now my web

423
00:19:59.079 --> 00:20:03.960
<v Speaker 7>server stack is engine x into Passenger, into Puma into

424
00:20:04.079 --> 00:20:04.519
<v Speaker 7>my app.

425
00:20:04.759 --> 00:20:07.119
<v Speaker 6>Is this is this excessive? Do you think to run

426
00:20:07.279 --> 00:20:09.440
<v Speaker 6>to run all of those for one web request?

427
00:20:09.720 --> 00:20:12.880
<v Speaker 3>So this is not grabbed you? Well, but yeah, one

428
00:20:12.960 --> 00:20:13.920
<v Speaker 3>hundred percent agree with this.

429
00:20:14.519 --> 00:20:17.279
<v Speaker 5>I actually reverse proxy to Puma in almost all of

430
00:20:17.319 --> 00:20:20.200
<v Speaker 5>my setups, but I don't use enginex plus Passenger and

431
00:20:20.279 --> 00:20:22.000
<v Speaker 5>then also add Puma on top.

432
00:20:22.240 --> 00:20:23.880
<v Speaker 7>You wouldn't believe how long it took me to get

433
00:20:23.880 --> 00:20:26.000
<v Speaker 7>it working. But now that I have got it working,

434
00:20:26.079 --> 00:20:28.240
<v Speaker 7>I quite like it. And it kind of feels like

435
00:20:28.279 --> 00:20:29.920
<v Speaker 7>I've got a bit of a gang on the server

436
00:20:30.079 --> 00:20:32.960
<v Speaker 7>and constead of kind of lonely process serving web pages.

437
00:20:33.240 --> 00:20:35.960
<v Speaker 4>You like it until there's a problem in production.

438
00:20:37.599 --> 00:20:41.640
<v Speaker 7>Why I like Passengers. If I'm in production, Passenger tells

439
00:20:41.720 --> 00:20:44.079
<v Speaker 7>me like help. You know, I just run the Passenger

440
00:20:44.160 --> 00:20:46.559
<v Speaker 7>status and it tells me what's going on, and you don't.

441
00:20:46.640 --> 00:20:48.359
<v Speaker 7>You don't get an at with the with the Puma,

442
00:20:48.440 --> 00:20:51.000
<v Speaker 7>there's no kind of happy here. Is how what I'm

443
00:20:51.039 --> 00:20:52.039
<v Speaker 7>doing Puma command.

444
00:20:52.240 --> 00:20:54.680
<v Speaker 4>Yeah, so enginex is going to be your web server

445
00:20:54.920 --> 00:20:58.599
<v Speaker 4>that's going to serve the HTTP content, and then Passenger,

446
00:20:59.079 --> 00:21:02.880
<v Speaker 4>Puma unic Horn are going to be your application service,

447
00:21:02.960 --> 00:21:06.680
<v Speaker 4>which is essentially going to talk to the rails application,

448
00:21:06.920 --> 00:21:12.119
<v Speaker 4>convert all that ERB slim or hamil code over into HTML,

449
00:21:12.319 --> 00:21:14.240
<v Speaker 4>and then give that to the web server to then

450
00:21:14.359 --> 00:21:16.319
<v Speaker 4>serve to the client. I know it's off topic.

451
00:21:16.799 --> 00:21:20.839
<v Speaker 7>Well, the reason I'm diverting here is because I've got

452
00:21:20.880 --> 00:21:22.960
<v Speaker 7>my happy long pulling setup.

453
00:21:22.640 --> 00:21:24.440
<v Speaker 6>And that works really well on our part.

454
00:21:24.519 --> 00:21:28.160
<v Speaker 7>From the huge, huge stack of process that goes through.

455
00:21:28.359 --> 00:21:30.680
<v Speaker 7>But now I've got that, I'm kind of looking at.

456
00:21:30.960 --> 00:21:35.279
<v Speaker 7>What I want to achieve is a site that sends

457
00:21:35.680 --> 00:21:40.200
<v Speaker 7>state simultaneously to lots of different clients live. So it's

458
00:21:40.200 --> 00:21:43.440
<v Speaker 7>a production system. Maybe you've got sixty terminals, and I

459
00:21:43.519 --> 00:21:47.920
<v Speaker 7>want state changes to propagate automatically so that with somebody

460
00:21:47.960 --> 00:21:51.319
<v Speaker 7>at one terminal hits a button, the others can see that, yeah,

461
00:21:51.480 --> 00:21:52.119
<v Speaker 7>in real time.

462
00:21:52.200 --> 00:21:53.640
<v Speaker 6>So this is my motivation.

463
00:21:53.920 --> 00:21:56.160
<v Speaker 7>So that would be if there was a slightly less

464
00:21:56.640 --> 00:21:59.880
<v Speaker 7>arcane way of doing that using graph QL, that would

465
00:22:00.039 --> 00:22:02.799
<v Speaker 7>interest me, you see, because my choices at the moment

466
00:22:03.000 --> 00:22:06.400
<v Speaker 7>are roll my own web socket system, which I've done

467
00:22:06.559 --> 00:22:08.960
<v Speaker 7>but it feels a bit home brew, or look at

468
00:22:09.000 --> 00:22:11.240
<v Speaker 7>something which has already solved this problem, which is a

469
00:22:11.279 --> 00:22:12.160
<v Speaker 7>bit more standard.

470
00:22:12.759 --> 00:22:16.960
<v Speaker 2>So in graph CAEL there is a subscription special subscription

471
00:22:17.079 --> 00:22:19.839
<v Speaker 2>type which looks like query and it can be run

472
00:22:19.960 --> 00:22:22.880
<v Speaker 2>on different transports as far as I remember, along with

473
00:22:23.079 --> 00:22:26.559
<v Speaker 2>action Cable, it supports some other paid services. So you

474
00:22:26.680 --> 00:22:30.160
<v Speaker 2>set up your transport engine and after that your client

475
00:22:30.680 --> 00:22:34.599
<v Speaker 2>client application will just start using subscriptions as a regular requests.

476
00:22:34.680 --> 00:22:37.119
<v Speaker 2>Because in this case it doesn't really matter where the

477
00:22:37.240 --> 00:22:39.799
<v Speaker 2>data came from because the data has the same type. So,

478
00:22:39.880 --> 00:22:41.680
<v Speaker 2>for instance, if you have a list of notifications and

479
00:22:41.720 --> 00:22:44.000
<v Speaker 2>you have a quit to get all the all the

480
00:22:44.200 --> 00:22:46.920
<v Speaker 2>let's say a notifications for the current user, you get

481
00:22:46.960 --> 00:22:49.200
<v Speaker 2>the list from the query, and then as soon as

482
00:22:49.279 --> 00:22:53.240
<v Speaker 2>the new notification rates, you get the new notification from

483
00:22:53.279 --> 00:22:56.200
<v Speaker 2>the subscription. So it can be done with when actually

484
00:22:56.319 --> 00:22:57.079
<v Speaker 2>cables it down.

485
00:22:57.359 --> 00:22:59.640
<v Speaker 5>So is this a thing that I can get out

486
00:22:59.680 --> 00:23:02.599
<v Speaker 5>of the b really easily or is this thing that

487
00:23:02.759 --> 00:23:04.680
<v Speaker 5>I have to set up right so I have to

488
00:23:04.759 --> 00:23:07.160
<v Speaker 5>go set up some action cable stuff, tie it in

489
00:23:07.519 --> 00:23:11.720
<v Speaker 5>to whichever graphul gym I'm using, or maybe I'm using graffiti,

490
00:23:11.799 --> 00:23:14.160
<v Speaker 5>which we talked about recently or whatever, but I haven't

491
00:23:14.160 --> 00:23:15.920
<v Speaker 5>tried yet. Is this a thing that's like easy to

492
00:23:16.000 --> 00:23:18.240
<v Speaker 5>set up with some out of the box rails gems

493
00:23:18.359 --> 00:23:21.160
<v Speaker 5>that are easy to find, or is this a thing

494
00:23:21.480 --> 00:23:23.640
<v Speaker 5>that I'm going to have to go read three tutorials

495
00:23:23.720 --> 00:23:25.240
<v Speaker 5>and kind of bumble my way through it.

496
00:23:25.519 --> 00:23:28.240
<v Speaker 2>Let's say it's not super hard to set it up. Fortunately,

497
00:23:28.480 --> 00:23:31.599
<v Speaker 2>I have veedutorial how to set up subscriptions and all

498
00:23:31.799 --> 00:23:34.119
<v Speaker 2>the stuff you need to start your grap cal application.

499
00:23:34.440 --> 00:23:36.480
<v Speaker 2>And yes, that's a part of the standard jam. The

500
00:23:36.519 --> 00:23:39.680
<v Speaker 2>only thing you have to change if you're using any cable.

501
00:23:39.839 --> 00:23:41.880
<v Speaker 2>Have you heard about any cable by the way, So

502
00:23:42.119 --> 00:23:44.160
<v Speaker 2>in this case you'll have to set up one more

503
00:23:44.200 --> 00:23:45.680
<v Speaker 2>additional gem and it will work.

504
00:23:45.880 --> 00:23:46.559
<v Speaker 3>Okay, sweet.

505
00:23:46.839 --> 00:23:49.839
<v Speaker 1>So one thing that I'm wondering about is, yeah, you know,

506
00:23:50.000 --> 00:23:51.880
<v Speaker 1>we've talked a bit about the boilerplate that has to

507
00:23:51.920 --> 00:23:54.839
<v Speaker 1>be written. So is there a generator or something that

508
00:23:54.920 --> 00:23:56.240
<v Speaker 1>I can run that will take care of a lot

509
00:23:56.279 --> 00:23:57.119
<v Speaker 1>of that stuff for me?

510
00:23:57.400 --> 00:24:00.880
<v Speaker 2>There are actional generator in the graph cal gem that

511
00:24:01.039 --> 00:24:03.200
<v Speaker 2>will create all the stuff you need to start, all

512
00:24:03.279 --> 00:24:06.680
<v Speaker 2>the base types, control and a year old. So yeah,

513
00:24:06.880 --> 00:24:10.200
<v Speaker 2>not to that you have very simple schema with one tip.

514
00:24:10.319 --> 00:24:13.519
<v Speaker 5>I guess just trying to track what is the gem

515
00:24:13.640 --> 00:24:16.000
<v Speaker 5>that's kind of been around for like I don't want

516
00:24:16.039 --> 00:24:18.440
<v Speaker 5>to say, like three or four years for Ruby stuff.

517
00:24:18.599 --> 00:24:20.839
<v Speaker 5>Is it graph quo Ruby or is it a different one?

518
00:24:21.039 --> 00:24:24.240
<v Speaker 2>It's a graph You guys mentioned that there was a

519
00:24:24.279 --> 00:24:27.160
<v Speaker 2>strange syntax. I guess you work it with the previous

520
00:24:27.279 --> 00:24:30.599
<v Speaker 2>version with blocks look like gelscript right, a lot of braces.

521
00:24:30.799 --> 00:24:32.079
<v Speaker 4>Yeah, that's very possible.

522
00:24:32.279 --> 00:24:35.640
<v Speaker 2>So sometimes ago they completely written the EPA and just

523
00:24:35.839 --> 00:24:38.000
<v Speaker 2>use classes as all other Ruby jumps to do.

524
00:24:38.279 --> 00:24:41.160
<v Speaker 4>Yeah, as long as I can right, clean, maintainable code,

525
00:24:41.359 --> 00:24:44.759
<v Speaker 4>then I think graphke well, you know, is viable in

526
00:24:44.880 --> 00:24:48.799
<v Speaker 4>a rail's application. But as John said at the beginning,

527
00:24:49.039 --> 00:24:52.640
<v Speaker 4>it's not a hammer that will fit every nail. You

528
00:24:52.759 --> 00:24:55.640
<v Speaker 4>have to use it when it's appropriate, not just because

529
00:24:55.640 --> 00:24:58.200
<v Speaker 4>it's what you're familiar with or because it's the latest

530
00:24:58.240 --> 00:25:00.400
<v Speaker 4>and greatest. If it's right tool for the job, then

531
00:25:00.440 --> 00:25:01.400
<v Speaker 4>absolutely use it.

532
00:25:01.720 --> 00:25:01.920
<v Speaker 2>Yeah.

533
00:25:02.079 --> 00:25:04.400
<v Speaker 5>I think for me like the issue is trying to

534
00:25:04.519 --> 00:25:07.079
<v Speaker 5>understand a sort of nuanced view of when is the

535
00:25:07.160 --> 00:25:09.519
<v Speaker 5>right time to use it. I think my understanding, thus,

536
00:25:09.599 --> 00:25:12.640
<v Speaker 5>far from a very simple standpoint, is very similar to

537
00:25:12.720 --> 00:25:16.039
<v Speaker 5>what you said earlier, Dave. If I have control of

538
00:25:16.160 --> 00:25:18.440
<v Speaker 5>the client right so I can write it myself, and

539
00:25:19.119 --> 00:25:22.519
<v Speaker 5>I have resources that very easily fit sort of the

540
00:25:22.640 --> 00:25:25.640
<v Speaker 5>rest kind of framework, then I don't really have a

541
00:25:25.680 --> 00:25:27.880
<v Speaker 5>lot of motivation right now to diverge from that and

542
00:25:28.000 --> 00:25:31.319
<v Speaker 5>go to GRAPHQOL. But if I start to leave that,

543
00:25:31.640 --> 00:25:34.440
<v Speaker 5>if I start to look like Facebook, where I need

544
00:25:34.559 --> 00:25:37.240
<v Speaker 5>to know about you know, person X and a whole

545
00:25:37.240 --> 00:25:39.799
<v Speaker 5>bunch of stuff about person ex as friends, That's where

546
00:25:39.799 --> 00:25:41.759
<v Speaker 5>I feel like I start to go down the road

547
00:25:42.119 --> 00:25:44.440
<v Speaker 5>where graph ql is good. And so I don't know

548
00:25:44.640 --> 00:25:46.799
<v Speaker 5>if any of you guys or Dimitri, if you guys

549
00:25:46.880 --> 00:25:50.079
<v Speaker 5>have like a more nuanced view of where you're like, oh,

550
00:25:50.240 --> 00:25:52.799
<v Speaker 5>here's the line in the sand when you might want

551
00:25:52.799 --> 00:25:54.680
<v Speaker 5>to consider that, But I don't have a very good

552
00:25:54.759 --> 00:25:55.519
<v Speaker 5>line at all.

553
00:25:56.039 --> 00:25:59.160
<v Speaker 2>Well, as I mentioned before, when you have more than

554
00:25:59.200 --> 00:26:01.799
<v Speaker 2>one client, there is a chance that you'll have more

555
00:26:01.839 --> 00:26:04.119
<v Speaker 2>than one client in your future. That might be it

556
00:26:04.359 --> 00:26:06.400
<v Speaker 2>the baseline you can touch you in graph kill because

557
00:26:06.440 --> 00:26:08.799
<v Speaker 2>in this case you want to worry about what data

558
00:26:08.839 --> 00:26:10.599
<v Speaker 2>would be needed on each platform.

559
00:26:10.799 --> 00:26:12.799
<v Speaker 1>Yeah, yeah, that makes sense. I mean the way that

560
00:26:12.839 --> 00:26:15.720
<v Speaker 1>I'm kind of envisioning it is, say I build a Dragon,

561
00:26:15.839 --> 00:26:19.440
<v Speaker 1>Ruby or a React Native or something, you know, build

562
00:26:19.440 --> 00:26:21.920
<v Speaker 1>an app with those. And I'm actually looking at some

563
00:26:22.039 --> 00:26:24.200
<v Speaker 1>of this stuff for some of my personal things, Right,

564
00:26:24.359 --> 00:26:26.480
<v Speaker 1>so I could build a front end off of the

565
00:26:26.799 --> 00:26:29.680
<v Speaker 1>graph ql, you know, and React or view or Angular

566
00:26:30.000 --> 00:26:31.880
<v Speaker 1>or you know, have some kind of tie ins with

567
00:26:31.920 --> 00:26:34.240
<v Speaker 1>Stimulus or something, depending on how I wanted to structure

568
00:26:34.759 --> 00:26:36.559
<v Speaker 1>the front end of the web app. But then the

569
00:26:36.640 --> 00:26:38.799
<v Speaker 1>mobile app, I'm finding more and more people want to

570
00:26:38.880 --> 00:26:42.640
<v Speaker 1>interact with apps on their phones, right, and so you know,

571
00:26:42.880 --> 00:26:45.880
<v Speaker 1>I may have slightly different interface or slightly different needs

572
00:26:46.039 --> 00:26:48.400
<v Speaker 1>on a mobile interface on the web, or I may

573
00:26:48.519 --> 00:26:50.680
<v Speaker 1>offer an app, you know, like we said before, written

574
00:26:50.720 --> 00:26:53.799
<v Speaker 1>in graph ql or something and or sorry and react native.

575
00:26:53.839 --> 00:26:56.359
<v Speaker 1>And so if I'm doing that, then having that option

576
00:26:56.519 --> 00:26:59.680
<v Speaker 1>available as well also works. One thing that I'm wondering about, though,

577
00:26:59.799 --> 00:27:05.119
<v Speaker 1>is the authentication flow and like permissions and security and

578
00:27:05.160 --> 00:27:07.400
<v Speaker 1>things like that. Right, So, one thing that I'm working

579
00:27:07.440 --> 00:27:09.680
<v Speaker 1>on right now is I'm trying to pull together like

580
00:27:10.000 --> 00:27:14.319
<v Speaker 1>basically a dashboard for the podcasts that essentially, you know,

581
00:27:14.440 --> 00:27:16.440
<v Speaker 1>I can say, okay, you guys are all hosts on

582
00:27:16.640 --> 00:27:18.759
<v Speaker 1>Ruby Rogues and so you know, here are all the

583
00:27:18.880 --> 00:27:22.079
<v Speaker 1>upcoming episodes. Here's all the prep information. Right, So instead

584
00:27:22.079 --> 00:27:25.200
<v Speaker 1>of it going through zap year and Google Docs, which

585
00:27:25.240 --> 00:27:26.839
<v Speaker 1>is what we're doing right now, you know, it just

586
00:27:26.920 --> 00:27:29.759
<v Speaker 1>pops up a notification on your device and says, hey,

587
00:27:29.839 --> 00:27:31.680
<v Speaker 1>you've got you got this new thing, you know, come

588
00:27:31.799 --> 00:27:33.960
<v Speaker 1>check it out, come prep whatever you know, and stuff

589
00:27:34.039 --> 00:27:35.799
<v Speaker 1>like that. But I'd like to be able to manage

590
00:27:35.799 --> 00:27:37.680
<v Speaker 1>all that stuff on my phone, and so I'm not

591
00:27:37.799 --> 00:27:40.279
<v Speaker 1>sure how to set things up so that the device

592
00:27:40.400 --> 00:27:42.839
<v Speaker 1>can actually you know, authenticate. So they go to the

593
00:27:42.920 --> 00:27:45.680
<v Speaker 1>login screen and React native and it sends the login

594
00:27:45.759 --> 00:27:49.119
<v Speaker 1>information over the wire to graphql. Do I do my

595
00:27:49.240 --> 00:27:52.440
<v Speaker 1>authentication through graphql or do I do it through a

596
00:27:52.599 --> 00:27:56.079
<v Speaker 1>device rest endpoint and then just kind of pass around

597
00:27:56.160 --> 00:27:58.960
<v Speaker 1>a JavaScript web token or how do you manage all

598
00:27:59.000 --> 00:27:59.440
<v Speaker 1>that stuff?

599
00:28:00.039 --> 00:28:02.000
<v Speaker 2>Fun thing is that when you try to find this

600
00:28:02.119 --> 00:28:04.440
<v Speaker 2>out in the documentation, they say that we don't care

601
00:28:04.480 --> 00:28:07.960
<v Speaker 2>about the authent authentication, just do it as you do it.

602
00:28:08.079 --> 00:28:10.960
<v Speaker 2>Usually in this case, yes, you'll have to set up

603
00:28:11.000 --> 00:28:14.839
<v Speaker 2>something token or device endpoint or something else. And in

604
00:28:14.920 --> 00:28:17.680
<v Speaker 2>this case, when you do some old stuff, you don't

605
00:28:17.799 --> 00:28:20.400
<v Speaker 2>have any shows you have to use rest because when

606
00:28:20.480 --> 00:28:22.720
<v Speaker 2>you get the couple from let's say Facebook, gil have

607
00:28:22.839 --> 00:28:25.440
<v Speaker 2>to set up this resting plant. But then when you

608
00:28:25.519 --> 00:28:28.279
<v Speaker 2>have the token, you just put it somewhere into heater,

609
00:28:28.440 --> 00:28:31.799
<v Speaker 2>into cookies as usual, and perform the authentication on the

610
00:28:32.039 --> 00:28:35.359
<v Speaker 2>rails level, on the rest level. Because graph kl claims

611
00:28:35.440 --> 00:28:38.160
<v Speaker 2>that it's transfer diagnostic and they don't care about the

612
00:28:38.200 --> 00:28:40.480
<v Speaker 2>protocol vi use. They do care about the protocol vid USE.

613
00:28:40.680 --> 00:28:42.480
<v Speaker 1>So I would put my token, say in the header

614
00:28:42.680 --> 00:28:45.319
<v Speaker 1>or something like that, and then is there some level

615
00:28:45.400 --> 00:28:48.640
<v Speaker 1>of checking that I can do before it executes a query?

616
00:28:49.119 --> 00:28:52.480
<v Speaker 2>Yeah, so let's briefally talk about how graph kill CUSS

617
00:28:52.559 --> 00:28:55.599
<v Speaker 2>is processed in RAILS. So there will be after you

618
00:28:55.720 --> 00:28:58.000
<v Speaker 2>run the generator we discussed before, there will be a

619
00:28:58.039 --> 00:29:01.559
<v Speaker 2>special role called graph curl. It will be posed because

620
00:29:01.799 --> 00:29:04.880
<v Speaker 2>sometimes query is big enough to not fit into get

621
00:29:04.960 --> 00:29:06.799
<v Speaker 2>your bests, So there will be a post into a

622
00:29:06.799 --> 00:29:09.799
<v Speaker 2>special control which is called graphkill control with a single

623
00:29:09.960 --> 00:29:13.599
<v Speaker 2>action called execute, and these control action contains a single

624
00:29:13.640 --> 00:29:16.799
<v Speaker 2>culture graph caill schema. There is an object called graphicill schema.

625
00:29:16.920 --> 00:29:20.799
<v Speaker 2>With the execute method, you pass your query, your variables

626
00:29:21.039 --> 00:29:23.519
<v Speaker 2>that came from the land, and then you can pass

627
00:29:23.599 --> 00:29:26.960
<v Speaker 2>a context. And context is just an object, a hash

628
00:29:27.079 --> 00:29:29.880
<v Speaker 2>which can contain anything you want, and in our case

629
00:29:30.039 --> 00:29:33.319
<v Speaker 2>it will contain current user object. So you can authenticate

630
00:29:33.519 --> 00:29:36.319
<v Speaker 2>user to make a decision about his permissions and put

631
00:29:36.359 --> 00:29:39.039
<v Speaker 2>it into the context. And these current users in the

632
00:29:39.200 --> 00:29:43.200
<v Speaker 2>context will be available everywhere inside your graph kill tabs, resolvers,

633
00:29:43.319 --> 00:29:46.119
<v Speaker 2>all that stuff. So it's pretty similar to just regular

634
00:29:46.200 --> 00:29:49.839
<v Speaker 2>application control. We're all right every day. You also mentioned

635
00:29:50.119 --> 00:29:51.599
<v Speaker 2>some authorization questions.

636
00:29:51.880 --> 00:29:54.119
<v Speaker 6>This is the end plus one for the optimization.

637
00:29:55.720 --> 00:29:56.240
<v Speaker 1>Did you freeze?

638
00:29:56.559 --> 00:29:58.359
<v Speaker 6>Yeah, I guess people do that a lot when I

639
00:29:58.440 --> 00:30:00.240
<v Speaker 6>ask some questions. I think it might be big.

640
00:30:00.519 --> 00:30:03.880
<v Speaker 2>Yeah, So the question was about amplus one autimization. There

641
00:30:03.960 --> 00:30:06.640
<v Speaker 2>is a big problem in graph call with amplus one

642
00:30:06.720 --> 00:30:10.160
<v Speaker 2>because sometimes you get requests to feage some entity and

643
00:30:10.440 --> 00:30:13.079
<v Speaker 2>a list of entities inside of this entity, and if

644
00:30:13.160 --> 00:30:15.880
<v Speaker 2>you miss something, there is a chance that you want

645
00:30:15.880 --> 00:30:18.720
<v Speaker 2>to make a joint in your database and you will

646
00:30:18.799 --> 00:30:21.880
<v Speaker 2>have a lot of small database calls. Just a classical

647
00:30:21.920 --> 00:30:24.039
<v Speaker 2>and plus one problem, but it's a little bit different

648
00:30:24.160 --> 00:30:27.000
<v Speaker 2>in graphkill work because there is a channel that you

649
00:30:27.079 --> 00:30:30.519
<v Speaker 2>will make a ton of smaller quests during the one

650
00:30:30.559 --> 00:30:33.599
<v Speaker 2>graph killer request. And there are a lot of solutions

651
00:30:33.680 --> 00:30:37.559
<v Speaker 2>to this problem. So the most simple and native approach

652
00:30:37.640 --> 00:30:39.920
<v Speaker 2>is to just eagle lodge everything you need. When your

653
00:30:40.039 --> 00:30:43.200
<v Speaker 2>application is small enough, you can just you know, list

654
00:30:43.359 --> 00:30:46.400
<v Speaker 2>all the possible associations on the top level in your

655
00:30:46.519 --> 00:30:49.319
<v Speaker 2>career tap and they will be loaded. Sometimes it works

656
00:30:49.359 --> 00:30:51.960
<v Speaker 2>because some applications are small enough, and also there is

657
00:30:52.079 --> 00:30:55.359
<v Speaker 2>no alternative solution. I have a gem called active cot

658
00:30:55.480 --> 00:30:58.359
<v Speaker 2>lasery Lot. It works in exact same way, but it

659
00:30:58.440 --> 00:31:01.519
<v Speaker 2>doesn't really lodge every think you listed right now. It

660
00:31:01.680 --> 00:31:04.759
<v Speaker 2>loads it as soon as someone tries to access the association.

661
00:31:05.039 --> 00:31:07.039
<v Speaker 2>In this case, you can list everything you need, but

662
00:31:07.279 --> 00:31:09.640
<v Speaker 2>it won't make a lot of requests on the request

663
00:31:09.720 --> 00:31:11.920
<v Speaker 2>that you need to make. But of course it doesn't

664
00:31:11.960 --> 00:31:15.160
<v Speaker 2>really work on the huge applications, so there is a

665
00:31:15.200 --> 00:31:18.519
<v Speaker 2>different solution. The solution is called loc ahead and it's

666
00:31:18.839 --> 00:31:21.799
<v Speaker 2>a part of Graphical Ruby a GM. The idea is

667
00:31:21.960 --> 00:31:25.440
<v Speaker 2>that you always can ask the execution engine if it

668
00:31:25.640 --> 00:31:28.599
<v Speaker 2>wants to feish a specific field on any level you want. So,

669
00:31:28.640 --> 00:31:31.720
<v Speaker 2>for instance, when you're resolving a user who can have orders,

670
00:31:31.839 --> 00:31:34.279
<v Speaker 2>you can ask, hey, are going to lot orders right now?

671
00:31:34.400 --> 00:31:36.559
<v Speaker 2>And if it says that you're going to lot orders,

672
00:31:36.960 --> 00:31:39.359
<v Speaker 2>you can make a special quest to database to a

673
00:31:39.440 --> 00:31:42.400
<v Speaker 2>wed DLUS one. And the last, the most complex solution

674
00:31:42.559 --> 00:31:46.000
<v Speaker 2>but it works in huge applications, is called graphkel Badge

675
00:31:46.279 --> 00:31:49.559
<v Speaker 2>is a GM by Shopify. The idea is that they

676
00:31:49.680 --> 00:31:53.759
<v Speaker 2>use leasier resolving. They stop resolving your field as soon

677
00:31:53.799 --> 00:31:56.200
<v Speaker 2>as it understands that you're going to have a possible

678
00:31:56.319 --> 00:31:59.079
<v Speaker 2>DUS one. It collects all the ideas that it wants

679
00:31:59.200 --> 00:32:01.759
<v Speaker 2>to lod and then makes a single request for all

680
00:32:01.920 --> 00:32:04.359
<v Speaker 2>the entities who wanted a lot and then just puts

681
00:32:04.559 --> 00:32:07.759
<v Speaker 2>the data into the slots. Let's say, so I think

682
00:32:07.880 --> 00:32:10.400
<v Speaker 2>and one problem is solvable in this case.

683
00:32:10.640 --> 00:32:12.680
<v Speaker 1>So another thing we have on our list of discussion

684
00:32:12.720 --> 00:32:15.200
<v Speaker 1>points is caching. So does I guess where does that

685
00:32:15.359 --> 00:32:18.200
<v Speaker 1>cashing occur? Because if you can kind of request anything

686
00:32:18.240 --> 00:32:20.759
<v Speaker 1>with graphuel, then I'm assuming that it happens at a

687
00:32:20.799 --> 00:32:24.839
<v Speaker 1>lower level where it caches the fields or the result

688
00:32:24.960 --> 00:32:27.839
<v Speaker 1>that it gets somehow and then builds the response from there.

689
00:32:28.200 --> 00:32:30.400
<v Speaker 2>Yeah, there are a lot of problems with catching. So

690
00:32:30.519 --> 00:32:33.240
<v Speaker 2>first of all, as I mentioned, graphicular requests are usually

691
00:32:33.319 --> 00:32:37.160
<v Speaker 2>post requests and it's impossible to use HP cash with pots,

692
00:32:37.359 --> 00:32:39.680
<v Speaker 2>and there is a solution for that. There is a

693
00:32:39.759 --> 00:32:43.000
<v Speaker 2>special technique called graph ciel persisted queries. The idea is

694
00:32:43.119 --> 00:32:46.240
<v Speaker 2>that when you send a requests to the server from

695
00:32:46.319 --> 00:32:49.000
<v Speaker 2>the client, sometimes you know that you're going to send

696
00:32:49.079 --> 00:32:51.480
<v Speaker 2>these requests more and more the same one, and in

697
00:32:51.559 --> 00:32:54.559
<v Speaker 2>this case you can just send a fingerprint of this request.

698
00:32:54.680 --> 00:32:57.880
<v Speaker 2>There is a special way to calculate these fingerprint that

699
00:32:58.119 --> 00:33:00.359
<v Speaker 2>is known by sir end client and this you can

700
00:33:00.440 --> 00:33:03.000
<v Speaker 2>send the fingerprint and severe knows what he wants to

701
00:33:03.119 --> 00:33:05.599
<v Speaker 2>return and if it doesn't know what queer you want

702
00:33:05.640 --> 00:33:07.640
<v Speaker 2>to make it to a respond that he doesn't know

703
00:33:07.759 --> 00:33:10.240
<v Speaker 2>about the query and ask the full version. When you

704
00:33:10.400 --> 00:33:12.799
<v Speaker 2>use this technique, you can use get requests because there

705
00:33:12.920 --> 00:33:15.319
<v Speaker 2>is no chance that you will send these huge quier

706
00:33:16.119 --> 00:33:19.240
<v Speaker 2>using GAT. In this case, you can use aestification if

707
00:33:19.279 --> 00:33:21.559
<v Speaker 2>you want, as far as I remember, it's possible to

708
00:33:21.599 --> 00:33:24.240
<v Speaker 2>do it, you think, using GRACoL Ruby, but only in

709
00:33:24.400 --> 00:33:27.119
<v Speaker 2>pro version. So I've written my own jem for that.

710
00:33:27.480 --> 00:33:30.119
<v Speaker 1>That's interesting. So essentially what you're saying is that, Yeah,

711
00:33:30.240 --> 00:33:32.400
<v Speaker 1>you can create a fingerprint for the query that you made,

712
00:33:32.519 --> 00:33:34.279
<v Speaker 1>and then you can make a get request and take

713
00:33:34.319 --> 00:33:37.200
<v Speaker 1>advantage of the HTTP cashing anyway, as long as you're

714
00:33:37.200 --> 00:33:38.359
<v Speaker 1>working the exact same query.

715
00:33:38.559 --> 00:33:41.599
<v Speaker 2>Yeah, because of the variables, you usually make the same

716
00:33:41.640 --> 00:33:44.400
<v Speaker 2>requests from not only a single client, but from all

717
00:33:44.440 --> 00:33:46.480
<v Speaker 2>the clients for the same version, so most of the

718
00:33:46.599 --> 00:33:48.079
<v Speaker 2>time you have cash hit.

719
00:33:48.359 --> 00:33:52.880
<v Speaker 1>Then does it invalidate the cash responses if some data changes,

720
00:33:53.079 --> 00:33:54.440
<v Speaker 1>like does it keep track of it the same way

721
00:33:54.480 --> 00:33:56.119
<v Speaker 1>that rails does for other cashing.

722
00:33:56.359 --> 00:33:58.640
<v Speaker 2>So in this case we don't really care about the

723
00:33:58.680 --> 00:34:02.079
<v Speaker 2>invaliation because we cash on the queer itself. So the

724
00:34:02.160 --> 00:34:05.720
<v Speaker 2>text of the quer and estification has to be invalidated

725
00:34:05.799 --> 00:34:09.119
<v Speaker 2>by RAILS. So many there is no solution. I tried

726
00:34:09.159 --> 00:34:12.079
<v Speaker 2>to implement something, but stopped and figured out that we

727
00:34:12.199 --> 00:34:14.800
<v Speaker 2>need to use a different solution. There is an idea

728
00:34:14.880 --> 00:34:18.760
<v Speaker 2>that we can cash graph car responses. From the first perspective,

729
00:34:18.800 --> 00:34:21.800
<v Speaker 2>it seems like it's impossible because each time client makes requests,

730
00:34:21.920 --> 00:34:24.760
<v Speaker 2>it can ask for any data we want, but it's

731
00:34:24.800 --> 00:34:27.519
<v Speaker 2>possible to catch the part of the query that you

732
00:34:27.840 --> 00:34:30.039
<v Speaker 2>don't want to resolve each time. For instance, when you

733
00:34:30.119 --> 00:34:32.679
<v Speaker 2>have the econmerce set and you have a list of

734
00:34:32.800 --> 00:34:35.599
<v Speaker 2>popular items, you probably want to show the same list

735
00:34:35.639 --> 00:34:38.039
<v Speaker 2>of popular items to everyone, and you don't want to

736
00:34:38.079 --> 00:34:40.480
<v Speaker 2>go to the database to fage them. That's why we

737
00:34:40.840 --> 00:34:44.000
<v Speaker 2>created a special gem for that called Graphy of Ammunication.

738
00:34:44.320 --> 00:34:47.880
<v Speaker 2>It was extracted from one of Evil Martials projects, initially

739
00:34:48.119 --> 00:34:51.519
<v Speaker 2>implemented by Blood mendument If and Nicola Switchkov. The idea

740
00:34:51.719 --> 00:34:55.920
<v Speaker 2>was that we want to remember the part of the response,

741
00:34:56.079 --> 00:34:58.840
<v Speaker 2>and when a client wants to get the same thing,

742
00:34:58.920 --> 00:35:01.000
<v Speaker 2>we just take the part of this song from the

743
00:35:01.239 --> 00:35:03.679
<v Speaker 2>cash from Redis or somewhere else and just send it

744
00:35:03.760 --> 00:35:06.719
<v Speaker 2>to the client without resolving it. Unfortunately, it wasn't possible

745
00:35:06.760 --> 00:35:09.559
<v Speaker 2>to do it in grapt you rubly because there were

746
00:35:09.679 --> 00:35:12.159
<v Speaker 2>no mechanisms to stop executions, so I had to make

747
00:35:12.199 --> 00:35:14.480
<v Speaker 2>a poor quest to add this mechanism. So right now

748
00:35:14.519 --> 00:35:17.960
<v Speaker 2>it's possible to use these being even if you're not

749
00:35:18.239 --> 00:35:20.480
<v Speaker 2>using the JAM. But when you use the gym, you

750
00:35:20.559 --> 00:35:23.400
<v Speaker 2>can specify the cash gear it will be built by

751
00:35:23.559 --> 00:35:26.239
<v Speaker 2>the JAM, and of course you can always invalidate this

752
00:35:26.400 --> 00:35:28.480
<v Speaker 2>cash if you want, and also you can also specify

753
00:35:28.880 --> 00:35:29.400
<v Speaker 2>time to live.

754
00:35:29.559 --> 00:35:32.320
<v Speaker 5>That seems super useful. All right, So is there anything

755
00:35:32.400 --> 00:35:35.840
<v Speaker 5>else Dmitri that you feel like maybe we should be

756
00:35:35.960 --> 00:35:39.599
<v Speaker 5>doing with GRAPHQL that's sort of not common practice, Like

757
00:35:39.800 --> 00:35:41.960
<v Speaker 5>is there best practice that we've sort of missed or

758
00:35:42.000 --> 00:35:44.800
<v Speaker 5>anything along those lines that we just haven't gotten to today.

759
00:35:45.039 --> 00:35:47.440
<v Speaker 2>Yeah, I think we could talk about some best practices.

760
00:35:48.000 --> 00:35:50.920
<v Speaker 2>Some of them are so similar to things we do

761
00:35:51.039 --> 00:35:53.360
<v Speaker 2>in rest, but a little bit different because it's a

762
00:35:53.599 --> 00:35:57.599
<v Speaker 2>different technology. So there are some possible security issues that

763
00:35:58.000 --> 00:36:01.000
<v Speaker 2>can happen with you when you're used in graph kill. So,

764
00:36:01.360 --> 00:36:05.000
<v Speaker 2>as we mentioned before, it's possible to ask everything you want,

765
00:36:05.159 --> 00:36:06.960
<v Speaker 2>but there is a chance that a client will make

766
00:36:07.039 --> 00:36:09.800
<v Speaker 2>requests that will just blow up your database because it

767
00:36:09.840 --> 00:36:12.400
<v Speaker 2>will be a huge select with a lot of giants.

768
00:36:12.480 --> 00:36:14.480
<v Speaker 2>And there is a solution for that, as far as

769
00:36:14.519 --> 00:36:16.639
<v Speaker 2>I remember it's not a part of the specification, but

770
00:36:17.079 --> 00:36:20.599
<v Speaker 2>most of the collabraries have these build chain. The idea

771
00:36:20.679 --> 00:36:23.639
<v Speaker 2>is that they calculate the depth or the quer and

772
00:36:23.800 --> 00:36:27.400
<v Speaker 2>the complexity. Depth is amount of entities you touch when

773
00:36:27.440 --> 00:36:30.519
<v Speaker 2>you go down the graph and complexity is a complex

774
00:36:30.599 --> 00:36:34.320
<v Speaker 2>method that includes amount of fields you are grassed, depth

775
00:36:34.440 --> 00:36:37.280
<v Speaker 2>and so on. And you can limit these two variables

776
00:36:37.719 --> 00:36:40.840
<v Speaker 2>on your execution engine. In this case, when someone tries

777
00:36:40.920 --> 00:36:43.079
<v Speaker 2>to make a huge request that you know that won't

778
00:36:43.159 --> 00:36:45.880
<v Speaker 2>be made by your real clients, it will just ask

779
00:36:45.960 --> 00:36:48.239
<v Speaker 2>the client to make a simpler one. I guess we

780
00:36:48.360 --> 00:36:50.960
<v Speaker 2>didn't face such promost with the rest. And also there

781
00:36:51.039 --> 00:36:54.280
<v Speaker 2>is one more interesting thing. As we mentioned before, it's

782
00:36:54.320 --> 00:36:58.599
<v Speaker 2>possible to expose your schema to have let's say public documentation.

783
00:36:58.760 --> 00:37:01.760
<v Speaker 2>But also in this case, it's possible to see your

784
00:37:02.079 --> 00:37:04.440
<v Speaker 2>testitious chema using graph heel because there is a special

785
00:37:04.480 --> 00:37:08.159
<v Speaker 2>incode introspection, you can make queriers to see the schema.

786
00:37:08.440 --> 00:37:11.679
<v Speaker 2>I'm not sure why it's dangerous, but some security specialists

787
00:37:11.760 --> 00:37:15.400
<v Speaker 2>think that it's security problem that we should add introspection

788
00:37:15.599 --> 00:37:18.559
<v Speaker 2>from public users because they don't really need to see

789
00:37:18.559 --> 00:37:21.559
<v Speaker 2>it and use it only in development. And maybe stanging environments,

790
00:37:21.679 --> 00:37:24.639
<v Speaker 2>so sometimes it makes sense to turn off introspection into

791
00:37:24.800 --> 00:37:27.519
<v Speaker 2>the production environment. There is a special setting for that

792
00:37:27.639 --> 00:37:29.440
<v Speaker 2>in graphlo rob which you can just turn it off

793
00:37:29.480 --> 00:37:32.119
<v Speaker 2>and it disappears forever to be impossible to ask for

794
00:37:32.320 --> 00:37:32.800
<v Speaker 2>this data.

795
00:37:33.000 --> 00:37:35.880
<v Speaker 1>I'm going to change the topic unless there's more to

796
00:37:36.199 --> 00:37:37.400
<v Speaker 1>the best practices.

797
00:37:37.719 --> 00:37:40.559
<v Speaker 2>There's one more thing to mention. There are some best

798
00:37:40.639 --> 00:37:43.119
<v Speaker 2>practices related to code which would be hard to discuss

799
00:37:43.239 --> 00:37:46.079
<v Speaker 2>without who can't get code, like we shouldn't expose data

800
00:37:46.119 --> 00:37:48.199
<v Speaker 2>from other entities, all this stuff.

801
00:37:48.360 --> 00:37:50.239
<v Speaker 4>So I have a small.

802
00:37:49.960 --> 00:37:53.320
<v Speaker 2>RoboCop extension for that which will help you to check

803
00:37:53.480 --> 00:37:56.119
<v Speaker 2>your code. Of course these rules have been edd because

804
00:37:56.199 --> 00:37:58.719
<v Speaker 2>it was great by me, but sometimes it may be helpful.

805
00:37:58.960 --> 00:37:59.480
<v Speaker 3>Sounds good.

806
00:37:59.639 --> 00:38:01.800
<v Speaker 1>How do you test your graph QL? You just make

807
00:38:01.840 --> 00:38:03.519
<v Speaker 1>a bunch of queries? Is there a better way to

808
00:38:03.559 --> 00:38:03.719
<v Speaker 1>do it?

809
00:38:04.039 --> 00:38:07.480
<v Speaker 2>So it depends. There are two ways that I'm aware of.

810
00:38:08.000 --> 00:38:11.239
<v Speaker 2>The first one is making querers, So you can just

811
00:38:11.440 --> 00:38:14.800
<v Speaker 2>make a test for like graphical controller. So you define

812
00:38:14.880 --> 00:38:18.679
<v Speaker 2>your quer, then call the controller, and then make the

813
00:38:18.760 --> 00:38:21.400
<v Speaker 2>request to call your controller, and then you'll check the

814
00:38:21.480 --> 00:38:23.719
<v Speaker 2>response if it much to the DT do you expect

815
00:38:24.000 --> 00:38:26.719
<v Speaker 2>or not? But when you write a lot of such tests.

816
00:38:26.800 --> 00:38:29.559
<v Speaker 2>It sounds repetitive. So there are two ways that you

817
00:38:29.639 --> 00:38:31.880
<v Speaker 2>can await it. The first one is to write a

818
00:38:32.199 --> 00:38:34.840
<v Speaker 2>shared context in respect. In this case you have some

819
00:38:35.039 --> 00:38:37.159
<v Speaker 2>kind of DASL that you will handle things for you.

820
00:38:37.599 --> 00:38:40.039
<v Speaker 2>Or there is a different approach that I heard of.

821
00:38:40.199 --> 00:38:42.480
<v Speaker 2>There is a gem called fixed trauma. The idea is

822
00:38:42.559 --> 00:38:45.639
<v Speaker 2>that you put all the data you want to check

823
00:38:45.760 --> 00:38:48.599
<v Speaker 2>to yamo files, define a single test and just have

824
00:38:48.800 --> 00:38:51.239
<v Speaker 2>a lot of folders with these yamo files, like what

825
00:38:51.519 --> 00:38:54.280
<v Speaker 2>you ask for, what you expect and if you'll just

826
00:38:54.400 --> 00:38:57.880
<v Speaker 2>compare the result with the dat do you expected to

827
00:38:57.960 --> 00:39:01.360
<v Speaker 2>get It sounds like to be cool to test types directly,

828
00:39:01.480 --> 00:39:05.039
<v Speaker 2>but right now it's impossible because of the Graftco Ruby architecture.

829
00:39:05.159 --> 00:39:08.159
<v Speaker 2>It's impossible to just create type objects from the crete

830
00:39:08.239 --> 00:39:11.079
<v Speaker 2>and ask it to shallize something for you because it's

831
00:39:11.199 --> 00:39:13.960
<v Speaker 2>heavily relies on the execution engine. So right now it's

832
00:39:14.000 --> 00:39:16.199
<v Speaker 2>not possible, but maybe it will change in the future.

833
00:39:16.440 --> 00:39:19.480
<v Speaker 5>Did what Chuck did or Dave, You guys were complaining

834
00:39:19.480 --> 00:39:21.840
<v Speaker 5>a little bit about it earlier, Did you guys do

835
00:39:21.960 --> 00:39:24.920
<v Speaker 5>any testing with graph QO when you did your implementation?

836
00:39:25.320 --> 00:39:28.239
<v Speaker 4>It is this testing that you speak of test is

837
00:39:28.239 --> 00:39:30.320
<v Speaker 4>a four letter word, right, all right, all right, Now,

838
00:39:30.639 --> 00:39:32.840
<v Speaker 4>I did tinker around with it, but I didn't dive

839
00:39:32.920 --> 00:39:36.800
<v Speaker 4>into it too much, and it was really just simple

840
00:39:37.159 --> 00:39:40.880
<v Speaker 4>mini tests. Just make a request, expect this back, I

841
00:39:40.960 --> 00:39:43.480
<v Speaker 4>got it back. I mean, it's really not too too

842
00:39:43.639 --> 00:39:46.719
<v Speaker 4>different than doing other tests when the rest API.

843
00:39:47.039 --> 00:39:49.039
<v Speaker 1>Yeah, most of my testing was manual because I was

844
00:39:49.079 --> 00:39:51.400
<v Speaker 1>more playing with it than actually trying to get something

845
00:39:51.440 --> 00:39:53.840
<v Speaker 1>out of it. But having spent time on some of

846
00:39:53.880 --> 00:39:56.519
<v Speaker 1>the front end systems, I mean, that's where graph ql

847
00:39:56.679 --> 00:39:59.639
<v Speaker 1>is really really nice, especially if you're using something like

848
00:39:59.719 --> 00:40:02.159
<v Speaker 1>a that just gives you a whole bunch of powerful

849
00:40:02.199 --> 00:40:05.239
<v Speaker 1>features out of the box. Anything else, any other thoughts

850
00:40:05.360 --> 00:40:06.199
<v Speaker 1>or advice.

851
00:40:06.840 --> 00:40:08.920
<v Speaker 2>Nothing on the top of my head. The only thing

852
00:40:09.039 --> 00:40:11.880
<v Speaker 2>I wanted to mention is that I'm surprised that no

853
00:40:11.960 --> 00:40:14.880
<v Speaker 2>one asks about the performance, because sometimes people think that

854
00:40:15.239 --> 00:40:19.480
<v Speaker 2>it's so hard to mark these huge graphicel requests and

855
00:40:19.559 --> 00:40:22.239
<v Speaker 2>then respond to them, and that graph gill add some

856
00:40:22.440 --> 00:40:25.880
<v Speaker 2>overhead to your processing. I tried to improve it and

857
00:40:26.079 --> 00:40:28.679
<v Speaker 2>figure it out that it's not that big problem. I

858
00:40:28.800 --> 00:40:33.360
<v Speaker 2>have a benchmark that tests the memory consumption by graph

859
00:40:33.400 --> 00:40:36.519
<v Speaker 2>keel would be compared with jacent APAI, which I mean

860
00:40:36.639 --> 00:40:40.559
<v Speaker 2>gcon Pei standard that makes the similar thing that graphicell does,

861
00:40:40.880 --> 00:40:43.960
<v Speaker 2>and there is no significant difference between them. And also

862
00:40:43.960 --> 00:40:47.280
<v Speaker 2>I tried to process really be queer, like there were

863
00:40:47.480 --> 00:40:51.400
<v Speaker 2>eight fields and each field had ensted an unested entity

864
00:40:51.559 --> 00:40:53.920
<v Speaker 2>with eight fields and so on four times. So that

865
00:40:54.639 --> 00:40:57.159
<v Speaker 2>was a really cuture request and it took like one

866
00:40:57.280 --> 00:40:59.679
<v Speaker 2>second process, which is a big amount of ten. But

867
00:40:59.840 --> 00:41:02.760
<v Speaker 2>we usually don't make such requests, and that's why I

868
00:41:02.840 --> 00:41:05.639
<v Speaker 2>do not recommend to you badging that I was meanted before.

869
00:41:05.760 --> 00:41:10.159
<v Speaker 2>And also after I published these benchmark things became better

870
00:41:10.320 --> 00:41:12.880
<v Speaker 2>because right now there is a new execution engine in

871
00:41:13.119 --> 00:41:16.119
<v Speaker 2>Cyangraphic Orbit, so things are in foster now, so I

872
00:41:16.199 --> 00:41:18.840
<v Speaker 2>can say that it doesn't really add any or to

873
00:41:18.960 --> 00:41:19.639
<v Speaker 2>your system.

874
00:41:19.920 --> 00:41:22.719
<v Speaker 1>Yeah, we didn't bring up performance because rails can't scale.

875
00:41:22.519 --> 00:41:25.000
<v Speaker 3>So it's cool. People that don't know how to use

876
00:41:25.039 --> 00:41:26.920
<v Speaker 3>the tool can't make it work. I think that's normal.

877
00:41:28.079 --> 00:41:30.400
<v Speaker 4>Yeah, so instead they reach for stuff like react.

878
00:41:30.800 --> 00:41:36.679
<v Speaker 3>Oh oh, I definitely not trying to No, No, it's fine.

879
00:41:36.760 --> 00:41:39.800
<v Speaker 1>We can all pity the Jango devs. Anyway, any other

880
00:41:39.840 --> 00:41:41.360
<v Speaker 1>thoughts or things that we want to bring up before

881
00:41:41.400 --> 00:41:42.239
<v Speaker 1>we go to picks.

882
00:41:42.199 --> 00:41:45.039
<v Speaker 6>Yeah, why can't we just send sequel over website?

883
00:41:47.119 --> 00:41:49.800
<v Speaker 3>People do this probably somewhere.

884
00:41:50.000 --> 00:41:52.440
<v Speaker 4>We're supposed to buy everything in a C data tag.

885
00:41:52.599 --> 00:41:54.079
<v Speaker 3>Right, Yeah, there we go. Sweet.

886
00:41:54.760 --> 00:41:56.960
<v Speaker 1>Yeah, all right, let's do some pics, Dave. Why don't

887
00:41:56.960 --> 00:41:57.840
<v Speaker 1>you start us with picks?

888
00:41:57.920 --> 00:42:01.760
<v Speaker 4>All right, So I recently got a star Tech under

889
00:42:01.880 --> 00:42:05.360
<v Speaker 4>desk computer mount to free up some desk pace, and

890
00:42:05.559 --> 00:42:08.440
<v Speaker 4>this thing is really cool. I mean, granted I now

891
00:42:08.599 --> 00:42:11.719
<v Speaker 4>hit the computer with my knee a bit, but having

892
00:42:11.800 --> 00:42:14.360
<v Speaker 4>it off the desk is really nice. So that's my

893
00:42:14.639 --> 00:42:17.679
<v Speaker 4>first pick, and sur probably my computer weighs like thirty

894
00:42:17.960 --> 00:42:21.320
<v Speaker 4>five almost forty pounds, and it supports the weight nicely.

895
00:42:21.800 --> 00:42:25.440
<v Speaker 4>And then the second pick is not to offens. So

896
00:42:25.679 --> 00:42:28.920
<v Speaker 4>with the age of digital learning and two of my

897
00:42:29.119 --> 00:42:33.039
<v Speaker 4>three soon to be four kids we're expecting if you didn't.

898
00:42:32.840 --> 00:42:34.639
<v Speaker 6>Know, they congratulations.

899
00:42:34.880 --> 00:42:36.119
<v Speaker 3>Thank you. Yeah.

900
00:42:36.480 --> 00:42:39.079
<v Speaker 4>I think after three kids it's supposed to be condolences,

901
00:42:39.199 --> 00:42:39.840
<v Speaker 4>but thank you.

902
00:42:40.000 --> 00:42:42.360
<v Speaker 1>Anyways, I have five. You're going to name the next

903
00:42:42.400 --> 00:42:42.880
<v Speaker 1>one Pearl.

904
00:42:43.320 --> 00:42:43.519
<v Speaker 3>Yah.

905
00:42:43.800 --> 00:42:48.719
<v Speaker 4>No, I've been xnayed on any more develope programmer kid names.

906
00:42:48.800 --> 00:42:51.360
<v Speaker 4>I already got Ruby, so that's that's a win. But

907
00:42:51.760 --> 00:42:54.679
<v Speaker 4>with these computers that ended up building for them. I

908
00:42:54.800 --> 00:42:57.000
<v Speaker 4>just went to my local microcenter and bought a whole

909
00:42:57.039 --> 00:43:00.320
<v Speaker 4>bunch of parts. One thing I forgot to get was

910
00:43:00.800 --> 00:43:03.440
<v Speaker 4>case fans. It came with one case fan on the

911
00:43:03.480 --> 00:43:06.440
<v Speaker 4>back for exhaust, but I didn't have any intakes, and

912
00:43:06.559 --> 00:43:10.440
<v Speaker 4>so I had some spare RX five eight graphics cards

913
00:43:10.679 --> 00:43:12.920
<v Speaker 4>and did some load testing and let the kids play

914
00:43:12.960 --> 00:43:15.960
<v Speaker 4>some games, and that case got super hot. So I

915
00:43:16.079 --> 00:43:19.719
<v Speaker 4>went out and on Amazon ordered a couple of Noctua

916
00:43:19.960 --> 00:43:23.320
<v Speaker 4>case fans and those things are amazing. Not only they

917
00:43:23.519 --> 00:43:26.320
<v Speaker 4>quiet even when they ramp up, but it made a

918
00:43:26.559 --> 00:43:29.559
<v Speaker 4>huge difference in the cooling of the PC case.

919
00:43:29.679 --> 00:43:30.079
<v Speaker 6>So No.

920
00:43:30.239 --> 00:43:32.360
<v Speaker 4>Two Evans is my second pick, as well as just

921
00:43:32.480 --> 00:43:34.960
<v Speaker 4>like case fans in general, having enough of them.

922
00:43:35.079 --> 00:43:37.199
<v Speaker 5>Congrats on your kid, by the way, and I'll also

923
00:43:37.320 --> 00:43:39.679
<v Speaker 5>thumb up not to I think they make pretty reasonably

924
00:43:39.760 --> 00:43:40.239
<v Speaker 5>good fans.

925
00:43:40.480 --> 00:43:42.079
<v Speaker 3>They're usually belliant fans.

926
00:43:42.280 --> 00:43:45.000
<v Speaker 1>Did I was going to say something dumb, but I didn't, John, What.

927
00:43:45.039 --> 00:43:45.519
<v Speaker 3>Are your picks?

928
00:43:45.599 --> 00:43:48.199
<v Speaker 5>I feel like I should recommend like some general type

929
00:43:48.239 --> 00:43:50.440
<v Speaker 5>fans which you can't like buy anymore or something like that.

930
00:43:50.679 --> 00:43:52.559
<v Speaker 5>But they used to make these really cool fans that

931
00:43:52.719 --> 00:43:55.519
<v Speaker 5>were like super silent, but they're like impossible to get

932
00:43:55.800 --> 00:43:58.599
<v Speaker 5>super expensive now. So this week I just like want

933
00:43:58.679 --> 00:44:01.159
<v Speaker 5>to to give some pretty much a shout out to

934
00:44:01.280 --> 00:44:03.199
<v Speaker 5>let because I think that a lot of people are.

935
00:44:03.199 --> 00:44:07.079
<v Speaker 3>Familiar with sticker Mule. Yes, thank you. I just had

936
00:44:07.119 --> 00:44:09.480
<v Speaker 3>the name like five minutes ago and I just forgot it. Whatever.

937
00:44:09.719 --> 00:44:13.920
<v Speaker 5>Anyway, best experience ever getting stickers every time. I have

938
00:44:14.000 --> 00:44:16.239
<v Speaker 5>gotten stickers from multiple places in the past, and then

939
00:44:16.239 --> 00:44:18.360
<v Speaker 5>a few years ago I switched and started using sticker

940
00:44:18.440 --> 00:44:21.800
<v Speaker 5>Mule and I just got stickers again recently, and they're

941
00:44:21.880 --> 00:44:24.639
<v Speaker 5>just so like flipping amazing to work with. And they

942
00:44:24.760 --> 00:44:27.239
<v Speaker 5>let you freaking cut out your stickers in the shape

943
00:44:27.239 --> 00:44:29.519
<v Speaker 5>of your sticker, which is exactly what I want.

944
00:44:29.639 --> 00:44:33.519
<v Speaker 3>So they're awesome. Just saying they're doing icons or something. Yeah,

945
00:44:33.760 --> 00:44:34.239
<v Speaker 3>they're great.

946
00:44:34.400 --> 00:44:36.559
<v Speaker 4>I put them out in the sun rather, I do

947
00:44:36.719 --> 00:44:38.840
<v Speaker 4>the bumper test, So I put a sticker on my

948
00:44:38.960 --> 00:44:42.079
<v Speaker 4>bumper and see how it fares to the weather. I've

949
00:44:42.119 --> 00:44:45.320
<v Speaker 4>had a bunch of stickers which just faded over of

950
00:44:45.400 --> 00:44:48.239
<v Speaker 4>course of two months. Any Sticker Mule sticker I put

951
00:44:48.280 --> 00:44:51.280
<v Speaker 4>on the back of my car has always lasted years

952
00:44:51.360 --> 00:44:51.840
<v Speaker 4>and years.

953
00:44:52.119 --> 00:44:55.440
<v Speaker 5>Yeah, they're pretty awesome and as far as pricing goes,

954
00:44:55.599 --> 00:44:57.239
<v Speaker 5>like I don't know. I feel like they end up

955
00:44:57.280 --> 00:45:00.280
<v Speaker 5>somehow meant managing to be cheaper too than like already

956
00:45:00.280 --> 00:45:01.679
<v Speaker 5>get them from like Moo or something.

957
00:45:01.840 --> 00:45:04.119
<v Speaker 3>So yeah. Also Moo doesn't do the weird shapes that

958
00:45:04.199 --> 00:45:05.280
<v Speaker 3>I want. That's it. That's my pick.

959
00:45:05.400 --> 00:45:08.119
<v Speaker 1>Awesome, Yeah, I like stick from Mule theer awesome, Luke,

960
00:45:08.159 --> 00:45:08.800
<v Speaker 1>what are your picks?

961
00:45:09.000 --> 00:45:12.239
<v Speaker 7>I've got one for fans. This is a an EESC.

962
00:45:12.760 --> 00:45:15.480
<v Speaker 7>It's speed controller for a drone motor. Can get them

963
00:45:15.519 --> 00:45:18.039
<v Speaker 7>for about twenty thirty dollars or up. And this is

964
00:45:18.159 --> 00:45:22.800
<v Speaker 7>controlled by the same PWM signal that your computer fans

965
00:45:22.880 --> 00:45:25.760
<v Speaker 7>run off, and the vultage going in on this particular

966
00:45:25.880 --> 00:45:26.599
<v Speaker 7>one will.

967
00:45:26.480 --> 00:45:27.800
<v Speaker 6>Run off a twelve rail.

968
00:45:27.840 --> 00:45:29.920
<v Speaker 7>If you want to put it in your PC case,

969
00:45:29.960 --> 00:45:32.000
<v Speaker 7>you can hook up the minus twelve and a twelve

970
00:45:32.079 --> 00:45:34.480
<v Speaker 7>and run really quite insane one of these. So if

971
00:45:34.519 --> 00:45:37.360
<v Speaker 7>you want to make a really ridiculous computer fan, you

972
00:45:37.440 --> 00:45:39.519
<v Speaker 7>can hook one of these up with a cheap drone

973
00:45:39.559 --> 00:45:41.679
<v Speaker 7>motor and get them for again about twenty bucks and

974
00:45:42.000 --> 00:45:44.599
<v Speaker 7>put a carbon five propeller on it, and that will

975
00:45:44.679 --> 00:45:47.800
<v Speaker 7>move the most amazing amount of air your PC has

976
00:45:47.920 --> 00:45:51.920
<v Speaker 7>ever seen. It's really unsafe, obviously, because it's designed to lift.

977
00:45:52.159 --> 00:45:55.280
<v Speaker 7>It's designed to lift things, not to provide a gentle airflow.

978
00:45:55.320 --> 00:45:58.719
<v Speaker 7>But if you want, if you miss truly silent fans,

979
00:45:59.000 --> 00:46:02.000
<v Speaker 7>that is a great way to get a totally silent fan.

980
00:46:02.639 --> 00:46:05.280
<v Speaker 7>I've used one in the past. It's really hot here,

981
00:46:05.519 --> 00:46:08.519
<v Speaker 7>so I've used one for as a like a desk fan.

982
00:46:08.800 --> 00:46:11.719
<v Speaker 7>Obviously cats is not safe around cats.

983
00:46:12.039 --> 00:46:13.960
<v Speaker 3>How many of those does it take to lift up

984
00:46:14.000 --> 00:46:14.760
<v Speaker 3>your computer case?

985
00:46:15.079 --> 00:46:18.480
<v Speaker 7>Oh? Sure, So this particular model you can get about

986
00:46:18.559 --> 00:46:21.320
<v Speaker 7>three kilos of frost out of it if you really

987
00:46:21.440 --> 00:46:23.519
<v Speaker 7>push it and you get everything matched up.

988
00:46:23.679 --> 00:46:24.400
<v Speaker 3>So if you.

989
00:46:26.400 --> 00:46:29.440
<v Speaker 7>Okay, if you yeah, as long as you've got a

990
00:46:29.440 --> 00:46:31.920
<v Speaker 7>big enough peller, you can lift anything, right. It's kind

991
00:46:31.960 --> 00:46:35.239
<v Speaker 7>of so my pick for the week is not very

992
00:46:35.360 --> 00:46:39.599
<v Speaker 7>dangerous computer pans. It is my server request stack, my

993
00:46:39.760 --> 00:46:44.639
<v Speaker 7>much maligned Engine's Passenger Huma stack, which I'm using, and

994
00:46:45.320 --> 00:46:45.960
<v Speaker 7>that is my pick.

995
00:46:46.079 --> 00:46:47.599
<v Speaker 6>You might not like it, but I picked it.

996
00:46:47.719 --> 00:46:50.599
<v Speaker 7>And part of a motivation for this was a post

997
00:46:50.760 --> 00:46:55.760
<v Speaker 7>by the Passenger blog which talks about combating slow Loris

998
00:46:55.920 --> 00:46:59.559
<v Speaker 7>deedoss attacks by stacking up enginets and matter compuber and a.

999
00:46:59.679 --> 00:47:02.760
<v Speaker 7>They explain part of the motivation behind it. So that's

1000
00:47:02.840 --> 00:47:07.039
<v Speaker 7>my picklog post by Fusion from Partying like it's twenty eighteen.

1001
00:47:07.400 --> 00:47:09.119
<v Speaker 1>Awesome. I'm going to jump in here with a couple

1002
00:47:09.199 --> 00:47:12.199
<v Speaker 1>of picks myself. The first pick is, I've been reading

1003
00:47:12.280 --> 00:47:15.000
<v Speaker 1>these books by Brent Weeks. The first book is called

1004
00:47:15.039 --> 00:47:18.440
<v Speaker 1>The Black Prism and it's high fantasy. Really really been

1005
00:47:18.519 --> 00:47:21.079
<v Speaker 1>enjoying these books. I'm on book four right now. I

1006
00:47:21.199 --> 00:47:22.880
<v Speaker 1>can't remember what the name of the book is, so

1007
00:47:23.159 --> 00:47:26.239
<v Speaker 1>don't ask. But anyway, the Black Prism is the first book,

1008
00:47:26.440 --> 00:47:29.320
<v Speaker 1>and I guess the series is called the light Bringer Series.

1009
00:47:29.400 --> 00:47:31.920
<v Speaker 1>And anyway, I've been listening to it on Amazon. It's

1010
00:47:32.039 --> 00:47:35.960
<v Speaker 1>narrated by Simon Vance, who's an awesome narrator. So I'll

1011
00:47:36.000 --> 00:47:38.880
<v Speaker 1>put links in for the book and I'll drop my

1012
00:47:38.960 --> 00:47:41.960
<v Speaker 1>affiliate link for Audible because that's where I'm consuming it

1013
00:47:42.039 --> 00:47:44.039
<v Speaker 1>and really really enjoying it. And yeah, that's going to

1014
00:47:44.079 --> 00:47:45.880
<v Speaker 1>be my pick for today. Dmitri, Do you have some

1015
00:47:45.960 --> 00:47:46.480
<v Speaker 1>picks for us?

1016
00:47:46.920 --> 00:47:50.360
<v Speaker 2>Yeah, I just thought about the email I've got yesterday

1017
00:47:50.440 --> 00:47:53.280
<v Speaker 2>that this year, as usually, will have a October first

1018
00:47:53.400 --> 00:47:55.840
<v Speaker 2>in October, so that will be my big guess.

1019
00:47:56.159 --> 00:47:58.559
<v Speaker 1>Awesome, And if people want to connect with you online,

1020
00:47:58.760 --> 00:48:02.519
<v Speaker 1>do you have a blog or GitHub or Twitter or whatever.

1021
00:48:02.880 --> 00:48:06.079
<v Speaker 2>Yeah, I will send your links to my GitHub and

1022
00:48:06.159 --> 00:48:09.960
<v Speaker 2>Twitter profile. And also I sometimes write articles in the

1023
00:48:10.000 --> 00:48:13.679
<v Speaker 2>Evil Marshalls book, mostly biographical and the based stuff.

1024
00:48:13.840 --> 00:48:16.039
<v Speaker 1>Cool. All right, folks, we'll wrap this one up and

1025
00:48:16.440 --> 00:48:17.599
<v Speaker 1>until next time. That's out.