Speaker 1: Hey, everybody, and welcome to another episode of Ruby Robes.
Speaker 1: This week, con our panel, we have John Luke.
Speaker 2: Hello, Dave.
Speaker 1: Hey, everyone feels so much more familiar to not say
Speaker 1: your last names. I'm Charles Maxwood or Chuck.
Speaker 3: I'm Chuck.
Speaker 1: And this week we're talking to Dmitri. Dmitri, I, do
Speaker 1: you want to say hi and let us know who
Speaker 1: you are?
Speaker 2: Yeah? Sure, Hi? Ever want? My name is Dmitri and
Speaker 2: you can call me Dima if it's simpler, because I
Speaker 2: know that Russian names start sometimes. I started my software
Speaker 2: development career in twenty and twelve and decided to focus
Speaker 2: on Ruby and Rails in twenty fourteen. Before that, I
Speaker 2: did some totten and development, front and development and iOS
Speaker 2: and since southern and eighteen, I guess I work as
Speaker 2: a back end developer at people Marshus. I spent a
Speaker 2: lot of time working on open source. I committed to Urga, Rails, grab, Kluba,
Speaker 2: has some smaller gems, and I also maintained some of
Speaker 2: my own jams. And I started working the graph field
Speaker 2: I guess in two thousand and seven gen, so it's
Speaker 2: like four years not for yes, so far nice.
Speaker 1: So the discerning listener probably heard graph ql about four
Speaker 1: times in your introduction, and that's we're going to be
Speaker 1: talking about specifically graph QL and rails. We talked about
Speaker 1: graffiti a couple months ago, and so this will be
Speaker 1: interesting to kind of compare the approaches and things like that.
Speaker 1: I know that some people love graph ql and some
Speaker 1: people love to hate graph ql. So I'm a little
Speaker 1: curious as we get going, can you just kind of
Speaker 1: give us the elevator pitch for graph ql. I know
Speaker 1: most people are probably at least somewhat familiar with what
Speaker 1: it is. But if we can start there, then we
Speaker 1: can start talking about why substitute this for REST, or
Speaker 1: use it in conjunction with REST, or what the trade
Speaker 1: offs are, or how to set it up or all
Speaker 1: that other stuff. But knowing what it is first is
Speaker 1: a good place to start.
Speaker 2: Yeah, sure, that's strand out. So if you're using RESS,
Speaker 2: probably got to use to a concept of a resource
Speaker 2: that each kind of data you have is a resource,
Speaker 2: and you have at least affections you can perform them,
Speaker 2: and you have these rest points that I allow you
Speaker 2: to fetch the data you need. But the problem is
Speaker 2: that sometimes you need a different set of data for
Speaker 2: each platform. For instance, when you're working with your own
Speaker 2: website and your mobiliplication. And in this case we have
Speaker 2: two problems which come from the same place. The first
Speaker 2: one is under fetching, which means that when you finish
Speaker 2: some data and you want to get the additional data
Speaker 2: about the additional resource, you have to make another quest
Speaker 2: or sometimes you have to make a lot of requests
Speaker 2: to get the full page. Imagine that you're working on
Speaker 2: Baseborg or something. You have a feed, a rist of friends,
Speaker 2: all that stuff, and you have to make additional requests
Speaker 2: or you can you know, have a special request that
Speaker 2: allows you to fetch all things you need. But it
Speaker 2: also sounds wrong because when you have the mobile AUP,
Speaker 2: you don't need to load all your friends and they
Speaker 2: fit at the same time, so you have you know,
Speaker 2: separate APIs for the mobile application and your website. The
Speaker 2: second problem is overfetching. It's almost the same thing. When
Speaker 2: you work on the mobile app and you get all
Speaker 2: these data for the website you don't need you don't need,
Speaker 2: but you have to download it processed and you know,
Speaker 2: use the network for that. So graph Gale tries to
Speaker 2: solve this problem. You can get any data you want,
Speaker 2: but you don't get any additional data that you don't
Speaker 2: want to get. The special benefit to get from graphical
Speaker 2: is the documentation, because the heart of the graph Kale
Speaker 2: system is it's schema. Schemo defies your graph So you
Speaker 2: have a list of entities which are called tag and
Speaker 2: these steps can have connections between each other. So you
Speaker 2: have all these connections described and you know what data
Speaker 2: can you get from each point. And in this case
Speaker 2: you don't need to have the separate documentation because you
Speaker 2: already have it. You just need to explain what does
Speaker 2: it mean in your system? For instance, what is the user,
Speaker 2: what is customer? All this stuff and that's it. You
Speaker 2: cannot have the outdated decommindation because in this case your
Speaker 2: graphical system just won't work at all. So I guess
Speaker 2: that's the main setting point for me. And also one
Speaker 2: more thing, but not the last one. I guess there
Speaker 2: is a special thing called subscriptions. Sometimes you don't want
Speaker 2: to get the data right now, but you want to
Speaker 2: get the updates, for instance, new messages in the chart
Speaker 2: or new notifications of the stuff. And when you work
Speaker 2: with the rest, you have to build something from scratch,
Speaker 2: like make the ajax request make all ink makes sockets
Speaker 2: by yourself all the stop. Graphicel solves this problem by subscriptions.
Speaker 2: In this case you can describe the where you want
Speaker 2: to make and wait until the event happens. In this case,
Speaker 2: graph kill would send the data to you and you
Speaker 2: don't need to think about how it came to your
Speaker 2: ilientification because it doesn't really make any difference between the
Speaker 2: regular quay or subscription call. And this is the part
Speaker 2: of the technologies, so you do not even need to
Speaker 2: care about how it works because it's usually a part
Speaker 2: of the library. You think that's the benefits of GRAPHAEL.
Speaker 2: I wanted to mention to kick it off.
Speaker 1: I'm a little curious as we get going, John Luke
Speaker 1: and Dave, what all have you done with graph ql.
Speaker 4: You mean, other than avoid it or complain about it. Yeah,
Speaker 4: now I'm joking. So I think that graph qul is
Speaker 4: really cool from the perspective, like Dmitri was saying, it
Speaker 4: has a lot of benefits, especially to end users consuming
Speaker 4: the API where where they can only really fetch the
Speaker 4: data that they need, not everything, especially when you're talking
Speaker 4: about really large data sets and really complicated data sets
Speaker 4: which maybe have a lot of associations associated with the
Speaker 4: main record that you were wanting to get back. So
Speaker 4: having the ability to just make one API call to
Speaker 4: this back end application serving graphic well is really nice
Speaker 4: opposed to having to make ten different calls. So not
Speaker 4: only is that more efficient from the perspective of one
Speaker 4: verse ten calls, but you also then have more ability
Speaker 4: to let's say pull it often, especially if the back
Speaker 4: end has some kind of rate limitter and in order
Speaker 4: to serve this one page or this one application, you
Speaker 4: had to make fifteen to twenty simultaneous requests to get
Speaker 4: all that data. Well, if you're doing any kind of
Speaker 4: rack attack or rate limiting, then you were consuming twenty
Speaker 4: times for just one page, you know. So it definitely
Speaker 4: has some benefits from that perspective. But now here's my
Speaker 4: big buttz. Despite all of those glorious benefits, I think
Speaker 4: if I am developing a API back end that's going
Speaker 4: to be consumed by an internal or an iOS or
Speaker 4: Android application that I'm publishing to the store, or by
Speaker 4: another in house product or by a third party who
Speaker 4: is very comfortable with working with rest APIs, I'm going
Speaker 4: to go with RESPI every day. But if I am
Speaker 4: going to create a API that I'm expecting all of
Speaker 4: my customers or users of the application to heavily write
Speaker 4: their own interfaces to everything. I'm just really providing a
Speaker 4: data source in a formatted way. Then Rephkuel might make
Speaker 4: a bit more sense.
Speaker 2: I can totally agree with Dave, and there is no
Speaker 2: reason to just start writing all the applications we have
Speaker 2: with golf kill. And also if you have a client
Speaker 2: that wants to work with REST and if it's still
Speaker 2: comfortable to work with the REST, that's completely fine, I guess.
Speaker 2: But sometimes it makes sense to start new projects with
Speaker 2: the graph Gale even if you don't have any experience
Speaker 2: with it at all, because sometimes you can find benefits.
Speaker 2: And by the way, there is a special trick in
Speaker 2: graph Gale which I also to awoid all these different
Speaker 2: small requests, which is called batching. I guess all modern
Speaker 2: front and trap cal frame A frameworks can do that.
Speaker 2: Batching is a thing that doesn't immediately make. It just
Speaker 2: builds a lest of requests and send then once, let's
Speaker 2: say once a second or something. It helps a lot
Speaker 2: when you have to render a lot of things from
Speaker 2: the same page, at least in the initial lot.
Speaker 5: Yeah, I don't disagree with save at all. I think
Speaker 5: for whatever reason, maybe this has always gone on. But
Speaker 5: I feel like the last few years there's been a
Speaker 5: lot of hey suite new tech comes out, like I
Speaker 5: have this new hammer and everything is a nail. And
Speaker 5: I feel like graph cel totally was a thing like that,
Speaker 5: where everyone was using graph qol for everything, even when
Speaker 5: I could find any of the benefits of graph ql
Speaker 5: lining up with their problems right Like it was like
Speaker 5: everyone using Mango to try and replicate relational databases, which
Speaker 5: Mongo is not good at.
Speaker 3: You know, that's my only beef.
Speaker 5: I think that graph ql is awesome to be frank,
Speaker 5: I've even said before and I still think it's probably true.
Speaker 3: So REST is kind.
Speaker 5: Of like a standard, right graph Ql is a technology,
Speaker 5: and I think that distinction, to me is important because
Speaker 5: if we can create a standard on top of graph
Speaker 5: ql that looks a little bit more like REST, I
Speaker 5: think that, in my opinion, I think it's likely that
Speaker 5: we'll see that graph ql is a lot more powerful
Speaker 5: than it looks right now.
Speaker 3: Because to me, it looks very wild westy.
Speaker 5: It's like, you have this cool new technology and everyone's
Speaker 5: all over the place with it, and so it's just
Speaker 5: a gigantic mess, and everyone's blaming the technology instead of
Speaker 5: blaming the discipline of the people that are using the
Speaker 5: technology that to me appears to be the source of
Speaker 5: most of the problems. I've only used it on toy
Speaker 5: apps so far. I haven't actually had a real problem
Speaker 5: in my life that made sense to match it up with. Yeah,
Speaker 5: but I still think it's sweet. It changes the way
Speaker 5: that I think about things.
Speaker 1: At the very least, Luke, have you done anything with
Speaker 1: graph you are no.
Speaker 6: I interviewed for a position with a company that made.
Speaker 7: White label, white label apps and they were heavily in
Speaker 7: the UK. They were heavily heavily into their GRAPHQL, and
Speaker 7: I was talking to CTO and asked him why because
Speaker 7: again there were a rail shop why they kind of
Speaker 7: put everything into GRAPHQL. And they were very mobile focused,
Speaker 7: and they felt that one of the benefits from using
Speaker 7: graph ca OB was the kind of huge benefit on mobile,
Speaker 7: especially with more efficient network usage. So for them, any
Speaker 7: amount of complexity was worth the trade off to get
Speaker 7: their apps running more responsive. So the fact it was
Speaker 7: a kind of a newer technology didn't care. They just
Speaker 7: wanted that improved customer experience. So I'm really interested to
Speaker 7: hear what Dmitri's saying, where you're saying this is not
Speaker 7: just about efficiency, this is actually a better way of
Speaker 7: organizing the interface between the client in the server. And
Speaker 7: I think you said something like having a schema was
Speaker 7: one of the big winds which you don't get with
Speaker 7: the rest based at So it's interesting to hear what
Speaker 7: why isn't didn't schemers go away with XML?
Speaker 6: That was the last time I had to deal with schemers.
Speaker 6: Are schemer is good now?
Speaker 2: Yeah, that's a good question, and I totally agree that
Speaker 2: it sounds like the more schema, but yeah, schemers are
Speaker 2: better now. I guess I'm too young to understand all
Speaker 2: the pain with schemes because I didn't work with them
Speaker 2: a lot. But yeah, the schema language in Garcao is
Speaker 2: very simple, looks like Gison, just regular gson. You just
Speaker 2: define a type, you just call type user and define
Speaker 2: list of fields like title is string and I don't know,
Speaker 2: orders is a list of order which where order is
Speaker 2: another type for instance. And they said you define all
Speaker 2: this stuff with text and for instance, in Ruby you
Speaker 2: don't even have to define the scheme by yourself. You
Speaker 2: just define classes and it makes all the magic behind
Speaker 2: the skins. You don't need to do anything at all.
Speaker 2: And then you can use this schema to center your clients.
Speaker 2: For instance, some i ET tools use scheme must have
Speaker 2: nice autocomplete and will date to e client request that
Speaker 2: they at least quest the fields you have, for instance.
Speaker 2: And also you can use any intercommutation tool you want
Speaker 2: to just show the place where you can find the
Speaker 2: chema and it will show abutal screened with all the fields, connections, types,
Speaker 2: all that stuff.
Speaker 1: Yeah, now, speaking of the schema, I mean, this was
Speaker 1: the painful part at least when I've laid with graph
Speaker 1: QL in rails, is that I wind up essentially fighting
Speaker 1: the engine a little bit because I have to set
Speaker 1: up that schema for every type in the system. It
Speaker 1: you know, at least, and I haven't tried it for
Speaker 1: a year or so, so the tooling might have gotten better.
Speaker 1: But yeah, so essentially I had to tell it. You know,
Speaker 1: the user's name is a string, and the user's user
Speaker 1: name is a string, and the users you know this
Speaker 1: that and the other is a number, and you know,
Speaker 1: in RAILS, if you're doing rest it just kind of
Speaker 1: all works, you know, and I didn't have to do
Speaker 1: any extra work to get that kind of an endpoint
Speaker 1: up within GRAPHQL. So yeah, that's my major beef with it.
Speaker 1: It's just that it created a whole bunch of work
Speaker 1: on the back end that I wouldn't have had to
Speaker 1: do if I was doing rest.
Speaker 5: I may argue you had to do that on the
Speaker 5: front end, right, because you got all that through Jason.
Speaker 5: It was all the string and then you had to decide, well,
Speaker 5: what is this? Is this the number? Should I be
Speaker 5: parsing ends, you know, or is this actually a string
Speaker 5: or is it something else? If it was objects, you
Speaker 5: were cool. But otherwise, yeah, you had to play with
Speaker 5: it there.
Speaker 1: Yes, and no, I mean I agree with you, and
Speaker 1: I don't. One thing that JavaScript has going for it
Speaker 1: is coercion, and so it winds up doing a lot
Speaker 1: of the you know, it winds up doing a lot
Speaker 1: of the work for you on that front right, And
Speaker 1: so unless you need like some very specific functionality out
Speaker 1: of it, you can just count on you know, JavaScript
Speaker 1: doing the right thing when you do a coercive comparison
Speaker 1: or things like that. And so, yeah, I don't do
Speaker 1: a lot of type casting in JavaScript. So for the
Speaker 1: most part, that doesn't matter as much to me.
Speaker 5: Yeah, I don't want to pretend like I had to
Speaker 5: do it all the time, but it was a thing
Speaker 5: that I did have to care about more often than
Speaker 5: I wanted to. Probably at least a few times a
Speaker 5: year I was dealing with something where I was doing
Speaker 5: a comparison or something and you know, for whatever reason,
Speaker 5: something that came from data was still a string and
Speaker 5: I had to fix that.
Speaker 2: And also, when you work with playing rails and you
Speaker 2: want to set up some kind of recommendation, for instance, swagger,
Speaker 2: you have to write all these comments near your actions
Speaker 2: by hand, and there is a chance that you'll forget
Speaker 2: to change anything and your swagger will be outdated and
Speaker 2: no one will not end. When you have schemas, there
Speaker 2: is no chance that it will be outdated because it's
Speaker 2: your schema that's used for peputing your cold.
Speaker 5: So going down the schema route a little bit more.
Speaker 5: I used to use soap back in the day, and
Speaker 5: I mean, I don't miss it at all.
Speaker 1: This is me crying for you.
Speaker 5: I don't miss it at all. But this isn't my
Speaker 5: first rodeo with schemas. Sorry, I guess alets of thinks
Speaker 5: I'm talking to her because I said soap.
Speaker 3: I don't know whatever.
Speaker 5: Anyway, I used to use so back in the day,
Speaker 5: And I mean, there's some benefits that you get with schemas,
Speaker 5: which I think is kind of what you're talking about here.
Speaker 3: For me, the main thing that I.
Speaker 5: Always felt like with schemas is I could pull information
Speaker 5: from a completely new source. But I know that you're
Speaker 5: not doing this all the time, but I could. I
Speaker 5: could know nothing about what was going on underneath, but
Speaker 5: I knew everything that I was allowed to do. That's
Speaker 5: a lot harder to do with, you know, RESTful APIs as.
Speaker 5: You know, we don't really provide that kind of thing.
Speaker 5: It's not impossible to do. I guess you could provide
Speaker 5: a page that does that or something, but nobody. It's
Speaker 5: not a standard by any means. But I guess why.
Speaker 5: For me, I can see benefits to it, and I
Speaker 5: feel like people are happy with the exchange when they're
Speaker 5: doing graph QL. Can you talk more about like why
Speaker 5: the schema in this case is a good thing as
Speaker 5: opposed to like soap where I always felt and Charles's
Speaker 5: actually just Chuck just expressed this a few minutes ago,
Speaker 5: He's like, well, I hate that. In rails, I had
Speaker 5: to like do all this setup like every time, right,
Speaker 5: Like we really hate writing boilerplate. That's why we write rails, right,
Speaker 5: So why is this exchange good? I guess, Like, what
Speaker 5: are we buying an exchange for it?
Speaker 2: Well? I get. The problem is that in graph kill
Speaker 2: World world, they prefer things to be explicit, So they
Speaker 2: want you to define the list of fields you want
Speaker 2: to fetch. The list to fills you a lot to
Speaker 2: fetch all that stuff. And it could be possible to
Speaker 2: just generate the list of fields based on your table structure.
Speaker 2: That's not impossible. I believe there is even a gem
Speaker 2: for that. But there is a huge benefit from having
Speaker 2: a schema. When you want to change your data in
Speaker 2: graph kiell World, it's called mutations. Mutation is a special
Speaker 2: way that can change your data, and it looks like
Speaker 2: a regular query, but it's usually expected to change the
Speaker 2: data on the back and set. And the thing is
Speaker 2: that when you define arguments. For instance, you want to
Speaker 2: change the price of the item for your Internet store,
Speaker 2: and you want this price to be numbered, and you
Speaker 2: want it to be required. You can be sure that
Speaker 2: it will be present in the arrangers, because otherwise graph
Speaker 2: execution engine will just send the error to the client
Speaker 2: telling him that he's wrong. So from the one point
Speaker 2: of view, you're at some boilerpred But from the other hand,
Speaker 2: you just remove the part when you avalidate the data
Speaker 2: because you can ask your execution engine to make it
Speaker 2: to make all the checks you want for you. I
Speaker 2: think that's fair exchange.
Speaker 3: So is the big bonus then on the writing side,
Speaker 3: is that what we're saying.
Speaker 2: Yeah, that's one of the benefits of having schema because
Speaker 2: you can make sure that things that you expect will
Speaker 2: arrive in a way that you're described in your cinema.
Speaker 4: Yeah, it's been a year since I've really touched graphql,
Speaker 4: but back when I did, one of the biggest issues
Speaker 4: that I had with it is that my code wasn't pretty.
Speaker 4: It seemed like Graphql complicated it beyond what a res
Speaker 4: API would do, and from that perspective, I just found
Speaker 4: it easier and more maintainable to stick with res api
Speaker 4: despite some of the benefits that graphql provided. Now I
Speaker 4: know that with I believe Facebook created the concept of
Speaker 4: graphul or created graphic youl, and what they were dealing
Speaker 4: with I'm sure is a lot worse than what graphql provides.
Speaker 4: But I think with what Rails provides just out of
Speaker 4: the box, or with just one or two serializer gems,
Speaker 4: then you have a much cleaner look without the graph
Speaker 4: Ql and just stick with the rest.
Speaker 2: So ft correctly, you mean that you don't like the code.
Speaker 2: You're right. When you're writing craft, you know we'll be right. Yeah, basically, Yeah,
Speaker 2: I guess it's a much taste, and I can agree
Speaker 2: that writing a list of fields each time we had
Speaker 2: a new entity can be not that great as a
Speaker 2: developer experience.
Speaker 1: Well, it wasn't just that for me. It was writing
Speaker 1: the fields and then writing the resolvers for all the
Speaker 1: extra stuff. I mean, it felt like it added a
Speaker 1: ton of work that I wouldn't have to do if
Speaker 1: I was doing rest.
Speaker 4: Yeah. I think the gym that was really popular a
Speaker 4: year or so ago for graph ql had a very
Speaker 4: strange DSL that they used, or at least it just
Speaker 4: seemed like it was over complicated, but that was probably
Speaker 4: just due to the necessities of what was required by
Speaker 4: graph Ql.
Speaker 7: I'm going to ask some really dumb questions here, so
Speaker 7: stand by all right, is running the graph ql. I've
Speaker 7: looked at it and I don't quite understand. I understand
Speaker 7: the process. You put your scheme together, you write some
Speaker 7: supporting code.
Speaker 6: Yeah, is the graph.
Speaker 7: Col query hitting that can't hit rails directly, can it?
Speaker 7: It's going through something? Is it hitting a node server
Speaker 7: running on the server?
Speaker 6: No.
Speaker 4: Graph qul is basically just a as John mentioned technology,
Speaker 4: So you're not having to parse it through another service,
Speaker 4: per se or external service. It's just you have a
Speaker 4: standard of what the graph ql should be structured as
Speaker 4: as it's consumed and how you are posting back to
Speaker 4: it for mutable changes and requests and stuff. But it's
Speaker 4: not actually going through a external service or anything.
Speaker 3: It could. But your rail server can also be your
Speaker 3: graphul server.
Speaker 1: Yeah, it just translates it down into calls through your model,
Speaker 1: just like anything else.
Speaker 5: It's kind of like you could pick Puma, or you
Speaker 5: could run a patche or engine X. Whatever you want
Speaker 5: can be your web server. You just have to adhere
Speaker 5: to certain things in order to be that.
Speaker 7: Oh this is my my weird bit, one of my
Speaker 7: weird bits for this week. So I've been working on. Noticeably,
Speaker 7: graph kill has got a kind of subscription service you mentioned,
Speaker 7: which looks like a kind of web sockets based live updates.
Speaker 7: I've been trying to make my own without using web sockets,
Speaker 7: using a long pulling and I was using Finn because
Speaker 7: it's quite easy to use Finn to do asynchronous staff
Speaker 7: using event machine. But Finn appears to be missing, presumed dead,
Speaker 7: and everyone's using Puma now right, you're getting nods here,
Speaker 7: so event machine.
Speaker 1: Yeah, I guess people can't hear my nods.
Speaker 6: Yes, yeah, yeah, there's an absolutely agreement.
Speaker 7: So I've been trying to get you working using the
Speaker 7: rack hijack, yeah, which is the kind of way of
Speaker 7: keeping a connection open with Puma. My word, that is
Speaker 7: a total nightmare. I can't tell you how long. I mean,
Speaker 7: it was took me to about two am to six
Speaker 7: am to get a hijack working. And now my web
Speaker 7: server stack is engine x into Passenger, into Puma into
Speaker 7: my app.
Speaker 6: Is this is this excessive? Do you think to run
Speaker 6: to run all of those for one web request?
Speaker 3: So this is not grabbed you? Well, but yeah, one
Speaker 3: hundred percent agree with this.
Speaker 5: I actually reverse proxy to Puma in almost all of
Speaker 5: my setups, but I don't use enginex plus Passenger and
Speaker 5: then also add Puma on top.
Speaker 7: You wouldn't believe how long it took me to get
Speaker 7: it working. But now that I have got it working,
Speaker 7: I quite like it. And it kind of feels like
Speaker 7: I've got a bit of a gang on the server
Speaker 7: and constead of kind of lonely process serving web pages.
Speaker 4: You like it until there's a problem in production.
Speaker 7: Why I like Passengers. If I'm in production, Passenger tells
Speaker 7: me like help. You know, I just run the Passenger
Speaker 7: status and it tells me what's going on, and you don't.
Speaker 7: You don't get an at with the with the Puma,
Speaker 7: there's no kind of happy here. Is how what I'm
Speaker 7: doing Puma command.
Speaker 4: Yeah, so enginex is going to be your web server
Speaker 4: that's going to serve the HTTP content, and then Passenger,
Speaker 4: Puma unic Horn are going to be your application service,
Speaker 4: which is essentially going to talk to the rails application,
Speaker 4: convert all that ERB slim or hamil code over into HTML,
Speaker 4: and then give that to the web server to then
Speaker 4: serve to the client. I know it's off topic.
Speaker 7: Well, the reason I'm diverting here is because I've got
Speaker 7: my happy long pulling setup.
Speaker 6: And that works really well on our part.
Speaker 7: From the huge, huge stack of process that goes through.
Speaker 7: But now I've got that, I'm kind of looking at.
Speaker 7: What I want to achieve is a site that sends
Speaker 7: state simultaneously to lots of different clients live. So it's
Speaker 7: a production system. Maybe you've got sixty terminals, and I
Speaker 7: want state changes to propagate automatically so that with somebody
Speaker 7: at one terminal hits a button, the others can see that, yeah,
Speaker 7: in real time.
Speaker 6: So this is my motivation.
Speaker 7: So that would be if there was a slightly less
Speaker 7: arcane way of doing that using graph QL, that would
Speaker 7: interest me, you see, because my choices at the moment
Speaker 7: are roll my own web socket system, which I've done
Speaker 7: but it feels a bit home brew, or look at
Speaker 7: something which has already solved this problem, which is a
Speaker 7: bit more standard.
Speaker 2: So in graph CAEL there is a subscription special subscription
Speaker 2: type which looks like query and it can be run
Speaker 2: on different transports as far as I remember, along with
Speaker 2: action Cable, it supports some other paid services. So you
Speaker 2: set up your transport engine and after that your client
Speaker 2: client application will just start using subscriptions as a regular requests.
Speaker 2: Because in this case it doesn't really matter where the
Speaker 2: data came from because the data has the same type. So,
Speaker 2: for instance, if you have a list of notifications and
Speaker 2: you have a quit to get all the all the
Speaker 2: let's say a notifications for the current user, you get
Speaker 2: the list from the query, and then as soon as
Speaker 2: the new notification rates, you get the new notification from
Speaker 2: the subscription. So it can be done with when actually
Speaker 2: cables it down.
Speaker 5: So is this a thing that I can get out
Speaker 5: of the b really easily or is this thing that
Speaker 5: I have to set up right so I have to
Speaker 5: go set up some action cable stuff, tie it in
Speaker 5: to whichever graphul gym I'm using, or maybe I'm using graffiti,
Speaker 5: which we talked about recently or whatever, but I haven't
Speaker 5: tried yet. Is this a thing that's like easy to
Speaker 5: set up with some out of the box rails gems
Speaker 5: that are easy to find, or is this a thing
Speaker 5: that I'm going to have to go read three tutorials
Speaker 5: and kind of bumble my way through it.
Speaker 2: Let's say it's not super hard to set it up. Fortunately,
Speaker 2: I have veedutorial how to set up subscriptions and all
Speaker 2: the stuff you need to start your grap cal application.
Speaker 2: And yes, that's a part of the standard jam. The
Speaker 2: only thing you have to change if you're using any cable.
Speaker 2: Have you heard about any cable by the way, So
Speaker 2: in this case you'll have to set up one more
Speaker 2: additional gem and it will work.
Speaker 3: Okay, sweet.
Speaker 1: So one thing that I'm wondering about is, yeah, you know,
Speaker 1: we've talked a bit about the boilerplate that has to
Speaker 1: be written. So is there a generator or something that
Speaker 1: I can run that will take care of a lot
Speaker 1: of that stuff for me?
Speaker 2: There are actional generator in the graph cal gem that
Speaker 2: will create all the stuff you need to start, all
Speaker 2: the base types, control and a year old. So yeah,
Speaker 2: not to that you have very simple schema with one tip.
Speaker 5: I guess just trying to track what is the gem
Speaker 5: that's kind of been around for like I don't want
Speaker 5: to say, like three or four years for Ruby stuff.
Speaker 5: Is it graph quo Ruby or is it a different one?
Speaker 2: It's a graph You guys mentioned that there was a
Speaker 2: strange syntax. I guess you work it with the previous
Speaker 2: version with blocks look like gelscript right, a lot of braces.
Speaker 4: Yeah, that's very possible.
Speaker 2: So sometimes ago they completely written the EPA and just
Speaker 2: use classes as all other Ruby jumps to do.
Speaker 4: Yeah, as long as I can right, clean, maintainable code,
Speaker 4: then I think graphke well, you know, is viable in
Speaker 4: a rail's application. But as John said at the beginning,
Speaker 4: it's not a hammer that will fit every nail. You
Speaker 4: have to use it when it's appropriate, not just because
Speaker 4: it's what you're familiar with or because it's the latest
Speaker 4: and greatest. If it's right tool for the job, then
Speaker 4: absolutely use it.
Speaker 2: Yeah.
Speaker 5: I think for me like the issue is trying to
Speaker 5: understand a sort of nuanced view of when is the
Speaker 5: right time to use it. I think my understanding, thus,
Speaker 5: far from a very simple standpoint, is very similar to
Speaker 5: what you said earlier, Dave. If I have control of
Speaker 5: the client right so I can write it myself, and
Speaker 5: I have resources that very easily fit sort of the
Speaker 5: rest kind of framework, then I don't really have a
Speaker 5: lot of motivation right now to diverge from that and
Speaker 5: go to GRAPHQOL. But if I start to leave that,
Speaker 5: if I start to look like Facebook, where I need
Speaker 5: to know about you know, person X and a whole
Speaker 5: bunch of stuff about person ex as friends, That's where
Speaker 5: I feel like I start to go down the road
Speaker 5: where graph ql is good. And so I don't know
Speaker 5: if any of you guys or Dimitri, if you guys
Speaker 5: have like a more nuanced view of where you're like, oh,
Speaker 5: here's the line in the sand when you might want
Speaker 5: to consider that, But I don't have a very good
Speaker 5: line at all.
Speaker 2: Well, as I mentioned before, when you have more than
Speaker 2: one client, there is a chance that you'll have more
Speaker 2: than one client in your future. That might be it
Speaker 2: the baseline you can touch you in graph kill because
Speaker 2: in this case you want to worry about what data
Speaker 2: would be needed on each platform.
Speaker 1: Yeah, yeah, that makes sense. I mean the way that
Speaker 1: I'm kind of envisioning it is, say I build a Dragon,
Speaker 1: Ruby or a React Native or something, you know, build
Speaker 1: an app with those. And I'm actually looking at some
Speaker 1: of this stuff for some of my personal things, Right,
Speaker 1: so I could build a front end off of the
Speaker 1: graph ql, you know, and React or view or Angular
Speaker 1: or you know, have some kind of tie ins with
Speaker 1: Stimulus or something, depending on how I wanted to structure
Speaker 1: the front end of the web app. But then the
Speaker 1: mobile app, I'm finding more and more people want to
Speaker 1: interact with apps on their phones, right, and so you know,
Speaker 1: I may have slightly different interface or slightly different needs
Speaker 1: on a mobile interface on the web, or I may
Speaker 1: offer an app, you know, like we said before, written
Speaker 1: in graph ql or something and or sorry and react native.
Speaker 1: And so if I'm doing that, then having that option
Speaker 1: available as well also works. One thing that I'm wondering about, though,
Speaker 1: is the authentication flow and like permissions and security and
Speaker 1: things like that. Right, So, one thing that I'm working
Speaker 1: on right now is I'm trying to pull together like
Speaker 1: basically a dashboard for the podcasts that essentially, you know,
Speaker 1: I can say, okay, you guys are all hosts on
Speaker 1: Ruby Rogues and so you know, here are all the
Speaker 1: upcoming episodes. Here's all the prep information. Right, So instead
Speaker 1: of it going through zap year and Google Docs, which
Speaker 1: is what we're doing right now, you know, it just
Speaker 1: pops up a notification on your device and says, hey,
Speaker 1: you've got you got this new thing, you know, come
Speaker 1: check it out, come prep whatever you know, and stuff
Speaker 1: like that. But I'd like to be able to manage
Speaker 1: all that stuff on my phone, and so I'm not
Speaker 1: sure how to set things up so that the device
Speaker 1: can actually you know, authenticate. So they go to the
Speaker 1: login screen and React native and it sends the login
Speaker 1: information over the wire to graphql. Do I do my
Speaker 1: authentication through graphql or do I do it through a
Speaker 1: device rest endpoint and then just kind of pass around
Speaker 1: a JavaScript web token or how do you manage all
Speaker 1: that stuff?
Speaker 2: Fun thing is that when you try to find this
Speaker 2: out in the documentation, they say that we don't care
Speaker 2: about the authent authentication, just do it as you do it.
Speaker 2: Usually in this case, yes, you'll have to set up
Speaker 2: something token or device endpoint or something else. And in
Speaker 2: this case, when you do some old stuff, you don't
Speaker 2: have any shows you have to use rest because when
Speaker 2: you get the couple from let's say Facebook, gil have
Speaker 2: to set up this resting plant. But then when you
Speaker 2: have the token, you just put it somewhere into heater,
Speaker 2: into cookies as usual, and perform the authentication on the
Speaker 2: rails level, on the rest level. Because graph kl claims
Speaker 2: that it's transfer diagnostic and they don't care about the
Speaker 2: protocol vi use. They do care about the protocol vid USE.
Speaker 1: So I would put my token, say in the header
Speaker 1: or something like that, and then is there some level
Speaker 1: of checking that I can do before it executes a query?
Speaker 2: Yeah, so let's briefally talk about how graph kill CUSS
Speaker 2: is processed in RAILS. So there will be after you
Speaker 2: run the generator we discussed before, there will be a
Speaker 2: special role called graph curl. It will be posed because
Speaker 2: sometimes query is big enough to not fit into get
Speaker 2: your bests, So there will be a post into a
Speaker 2: special control which is called graphkill control with a single
Speaker 2: action called execute, and these control action contains a single
Speaker 2: culture graph caill schema. There is an object called graphicill schema.
Speaker 2: With the execute method, you pass your query, your variables
Speaker 2: that came from the land, and then you can pass
Speaker 2: a context. And context is just an object, a hash
Speaker 2: which can contain anything you want, and in our case
Speaker 2: it will contain current user object. So you can authenticate
Speaker 2: user to make a decision about his permissions and put
Speaker 2: it into the context. And these current users in the
Speaker 2: context will be available everywhere inside your graph kill tabs, resolvers,
Speaker 2: all that stuff. So it's pretty similar to just regular
Speaker 2: application control. We're all right every day. You also mentioned
Speaker 2: some authorization questions.
Speaker 6: This is the end plus one for the optimization.
Speaker 1: Did you freeze?
Speaker 6: Yeah, I guess people do that a lot when I
Speaker 6: ask some questions. I think it might be big.
Speaker 2: Yeah, So the question was about amplus one autimization. There
Speaker 2: is a big problem in graph call with amplus one
Speaker 2: because sometimes you get requests to feage some entity and
Speaker 2: a list of entities inside of this entity, and if
Speaker 2: you miss something, there is a chance that you want
Speaker 2: to make a joint in your database and you will
Speaker 2: have a lot of small database calls. Just a classical
Speaker 2: and plus one problem, but it's a little bit different
Speaker 2: in graphkill work because there is a channel that you
Speaker 2: will make a ton of smaller quests during the one
Speaker 2: graph killer request. And there are a lot of solutions
Speaker 2: to this problem. So the most simple and native approach
Speaker 2: is to just eagle lodge everything you need. When your
Speaker 2: application is small enough, you can just you know, list
Speaker 2: all the possible associations on the top level in your
Speaker 2: career tap and they will be loaded. Sometimes it works
Speaker 2: because some applications are small enough, and also there is
Speaker 2: no alternative solution. I have a gem called active cot
Speaker 2: lasery Lot. It works in exact same way, but it
Speaker 2: doesn't really lodge every think you listed right now. It
Speaker 2: loads it as soon as someone tries to access the association.
Speaker 2: In this case, you can list everything you need, but
Speaker 2: it won't make a lot of requests on the request
Speaker 2: that you need to make. But of course it doesn't
Speaker 2: really work on the huge applications, so there is a
Speaker 2: different solution. The solution is called loc ahead and it's
Speaker 2: a part of Graphical Ruby a GM. The idea is
Speaker 2: that you always can ask the execution engine if it
Speaker 2: wants to feish a specific field on any level you want. So,
Speaker 2: for instance, when you're resolving a user who can have orders,
Speaker 2: you can ask, hey, are going to lot orders right now?
Speaker 2: And if it says that you're going to lot orders,
Speaker 2: you can make a special quest to database to a
Speaker 2: wed DLUS one. And the last, the most complex solution
Speaker 2: but it works in huge applications, is called graphkel Badge
Speaker 2: is a GM by Shopify. The idea is that they
Speaker 2: use leasier resolving. They stop resolving your field as soon
Speaker 2: as it understands that you're going to have a possible
Speaker 2: DUS one. It collects all the ideas that it wants
Speaker 2: to lod and then makes a single request for all
Speaker 2: the entities who wanted a lot and then just puts
Speaker 2: the data into the slots. Let's say, so I think
Speaker 2: and one problem is solvable in this case.
Speaker 1: So another thing we have on our list of discussion
Speaker 1: points is caching. So does I guess where does that
Speaker 1: cashing occur? Because if you can kind of request anything
Speaker 1: with graphuel, then I'm assuming that it happens at a
Speaker 1: lower level where it caches the fields or the result
Speaker 1: that it gets somehow and then builds the response from there.
Speaker 2: Yeah, there are a lot of problems with catching. So
Speaker 2: first of all, as I mentioned, graphicular requests are usually
Speaker 2: post requests and it's impossible to use HP cash with pots,
Speaker 2: and there is a solution for that. There is a
Speaker 2: special technique called graph ciel persisted queries. The idea is
Speaker 2: that when you send a requests to the server from
Speaker 2: the client, sometimes you know that you're going to send
Speaker 2: these requests more and more the same one, and in
Speaker 2: this case you can just send a fingerprint of this request.
Speaker 2: There is a special way to calculate these fingerprint that
Speaker 2: is known by sir end client and this you can
Speaker 2: send the fingerprint and severe knows what he wants to
Speaker 2: return and if it doesn't know what queer you want
Speaker 2: to make it to a respond that he doesn't know
Speaker 2: about the query and ask the full version. When you
Speaker 2: use this technique, you can use get requests because there
Speaker 2: is no chance that you will send these huge quier
Speaker 2: using GAT. In this case, you can use aestification if
Speaker 2: you want, as far as I remember, it's possible to
Speaker 2: do it, you think, using GRACoL Ruby, but only in
Speaker 2: pro version. So I've written my own jem for that.
Speaker 1: That's interesting. So essentially what you're saying is that, Yeah,
Speaker 1: you can create a fingerprint for the query that you made,
Speaker 1: and then you can make a get request and take
Speaker 1: advantage of the HTTP cashing anyway, as long as you're
Speaker 1: working the exact same query.
Speaker 2: Yeah, because of the variables, you usually make the same
Speaker 2: requests from not only a single client, but from all
Speaker 2: the clients for the same version, so most of the
Speaker 2: time you have cash hit.
Speaker 1: Then does it invalidate the cash responses if some data changes,
Speaker 1: like does it keep track of it the same way
Speaker 1: that rails does for other cashing.
Speaker 2: So in this case we don't really care about the
Speaker 2: invaliation because we cash on the queer itself. So the
Speaker 2: text of the quer and estification has to be invalidated
Speaker 2: by RAILS. So many there is no solution. I tried
Speaker 2: to implement something, but stopped and figured out that we
Speaker 2: need to use a different solution. There is an idea
Speaker 2: that we can cash graph car responses. From the first perspective,
Speaker 2: it seems like it's impossible because each time client makes requests,
Speaker 2: it can ask for any data we want, but it's
Speaker 2: possible to catch the part of the query that you
Speaker 2: don't want to resolve each time. For instance, when you
Speaker 2: have the econmerce set and you have a list of
Speaker 2: popular items, you probably want to show the same list
Speaker 2: of popular items to everyone, and you don't want to
Speaker 2: go to the database to fage them. That's why we
Speaker 2: created a special gem for that called Graphy of Ammunication.
Speaker 2: It was extracted from one of Evil Martials projects, initially
Speaker 2: implemented by Blood mendument If and Nicola Switchkov. The idea
Speaker 2: was that we want to remember the part of the response,
Speaker 2: and when a client wants to get the same thing,
Speaker 2: we just take the part of this song from the
Speaker 2: cash from Redis or somewhere else and just send it
Speaker 2: to the client without resolving it. Unfortunately, it wasn't possible
Speaker 2: to do it in grapt you rubly because there were
Speaker 2: no mechanisms to stop executions, so I had to make
Speaker 2: a poor quest to add this mechanism. So right now
Speaker 2: it's possible to use these being even if you're not
Speaker 2: using the JAM. But when you use the gym, you
Speaker 2: can specify the cash gear it will be built by
Speaker 2: the JAM, and of course you can always invalidate this
Speaker 2: cash if you want, and also you can also specify
Speaker 2: time to live.
Speaker 5: That seems super useful. All right, So is there anything
Speaker 5: else Dmitri that you feel like maybe we should be
Speaker 5: doing with GRAPHQL that's sort of not common practice, Like
Speaker 5: is there best practice that we've sort of missed or
Speaker 5: anything along those lines that we just haven't gotten to today.
Speaker 2: Yeah, I think we could talk about some best practices.
Speaker 2: Some of them are so similar to things we do
Speaker 2: in rest, but a little bit different because it's a
Speaker 2: different technology. So there are some possible security issues that
Speaker 2: can happen with you when you're used in graph kill. So,
Speaker 2: as we mentioned before, it's possible to ask everything you want,
Speaker 2: but there is a chance that a client will make
Speaker 2: requests that will just blow up your database because it
Speaker 2: will be a huge select with a lot of giants.
Speaker 2: And there is a solution for that, as far as
Speaker 2: I remember it's not a part of the specification, but
Speaker 2: most of the collabraries have these build chain. The idea
Speaker 2: is that they calculate the depth or the quer and
Speaker 2: the complexity. Depth is amount of entities you touch when
Speaker 2: you go down the graph and complexity is a complex
Speaker 2: method that includes amount of fields you are grassed, depth
Speaker 2: and so on. And you can limit these two variables
Speaker 2: on your execution engine. In this case, when someone tries
Speaker 2: to make a huge request that you know that won't
Speaker 2: be made by your real clients, it will just ask
Speaker 2: the client to make a simpler one. I guess we
Speaker 2: didn't face such promost with the rest. And also there
Speaker 2: is one more interesting thing. As we mentioned before, it's
Speaker 2: possible to expose your schema to have let's say public documentation.
Speaker 2: But also in this case, it's possible to see your
Speaker 2: testitious chema using graph heel because there is a special
Speaker 2: incode introspection, you can make queriers to see the schema.
Speaker 2: I'm not sure why it's dangerous, but some security specialists
Speaker 2: think that it's security problem that we should add introspection
Speaker 2: from public users because they don't really need to see
Speaker 2: it and use it only in development. And maybe stanging environments,
Speaker 2: so sometimes it makes sense to turn off introspection into
Speaker 2: the production environment. There is a special setting for that
Speaker 2: in graphlo rob which you can just turn it off
Speaker 2: and it disappears forever to be impossible to ask for
Speaker 2: this data.
Speaker 1: I'm going to change the topic unless there's more to
Speaker 1: the best practices.
Speaker 2: There's one more thing to mention. There are some best
Speaker 2: practices related to code which would be hard to discuss
Speaker 2: without who can't get code, like we shouldn't expose data
Speaker 2: from other entities, all this stuff.
Speaker 4: So I have a small.
Speaker 2: RoboCop extension for that which will help you to check
Speaker 2: your code. Of course these rules have been edd because
Speaker 2: it was great by me, but sometimes it may be helpful.
Speaker 3: Sounds good.
Speaker 1: How do you test your graph QL? You just make
Speaker 1: a bunch of queries? Is there a better way to
Speaker 1: do it?
Speaker 2: So it depends. There are two ways that I'm aware of.
Speaker 2: The first one is making querers, So you can just
Speaker 2: make a test for like graphical controller. So you define
Speaker 2: your quer, then call the controller, and then make the
Speaker 2: request to call your controller, and then you'll check the
Speaker 2: response if it much to the DT do you expect
Speaker 2: or not? But when you write a lot of such tests.
Speaker 2: It sounds repetitive. So there are two ways that you
Speaker 2: can await it. The first one is to write a
Speaker 2: shared context in respect. In this case you have some
Speaker 2: kind of DASL that you will handle things for you.
Speaker 2: Or there is a different approach that I heard of.
Speaker 2: There is a gem called fixed trauma. The idea is
Speaker 2: that you put all the data you want to check
Speaker 2: to yamo files, define a single test and just have
Speaker 2: a lot of folders with these yamo files, like what
Speaker 2: you ask for, what you expect and if you'll just
Speaker 2: compare the result with the dat do you expected to
Speaker 2: get It sounds like to be cool to test types directly,
Speaker 2: but right now it's impossible because of the Graftco Ruby architecture.
Speaker 2: It's impossible to just create type objects from the crete
Speaker 2: and ask it to shallize something for you because it's
Speaker 2: heavily relies on the execution engine. So right now it's
Speaker 2: not possible, but maybe it will change in the future.
Speaker 5: Did what Chuck did or Dave, You guys were complaining
Speaker 5: a little bit about it earlier, Did you guys do
Speaker 5: any testing with graph QO when you did your implementation?
Speaker 4: It is this testing that you speak of test is
Speaker 4: a four letter word, right, all right, all right, Now,
Speaker 4: I did tinker around with it, but I didn't dive
Speaker 4: into it too much, and it was really just simple
Speaker 4: mini tests. Just make a request, expect this back, I
Speaker 4: got it back. I mean, it's really not too too
Speaker 4: different than doing other tests when the rest API.
Speaker 1: Yeah, most of my testing was manual because I was
Speaker 1: more playing with it than actually trying to get something
Speaker 1: out of it. But having spent time on some of
Speaker 1: the front end systems, I mean, that's where graph ql
Speaker 1: is really really nice, especially if you're using something like
Speaker 1: a that just gives you a whole bunch of powerful
Speaker 1: features out of the box. Anything else, any other thoughts
Speaker 1: or advice.
Speaker 2: Nothing on the top of my head. The only thing
Speaker 2: I wanted to mention is that I'm surprised that no
Speaker 2: one asks about the performance, because sometimes people think that
Speaker 2: it's so hard to mark these huge graphicel requests and
Speaker 2: then respond to them, and that graph gill add some
Speaker 2: overhead to your processing. I tried to improve it and
Speaker 2: figure it out that it's not that big problem. I
Speaker 2: have a benchmark that tests the memory consumption by graph
Speaker 2: keel would be compared with jacent APAI, which I mean
Speaker 2: gcon Pei standard that makes the similar thing that graphicell does,
Speaker 2: and there is no significant difference between them. And also
Speaker 2: I tried to process really be queer, like there were
Speaker 2: eight fields and each field had ensted an unested entity
Speaker 2: with eight fields and so on four times. So that
Speaker 2: was a really cuture request and it took like one
Speaker 2: second process, which is a big amount of ten. But
Speaker 2: we usually don't make such requests, and that's why I
Speaker 2: do not recommend to you badging that I was meanted before.
Speaker 2: And also after I published these benchmark things became better
Speaker 2: because right now there is a new execution engine in
Speaker 2: Cyangraphic Orbit, so things are in foster now, so I
Speaker 2: can say that it doesn't really add any or to
Speaker 2: your system.
Speaker 1: Yeah, we didn't bring up performance because rails can't scale.
Speaker 3: So it's cool. People that don't know how to use
Speaker 3: the tool can't make it work. I think that's normal.
Speaker 4: Yeah, so instead they reach for stuff like react.
Speaker 3: Oh oh, I definitely not trying to No, No, it's fine.
Speaker 1: We can all pity the Jango devs. Anyway, any other
Speaker 1: thoughts or things that we want to bring up before
Speaker 1: we go to picks.
Speaker 6: Yeah, why can't we just send sequel over website?
Speaker 3: People do this probably somewhere.
Speaker 4: We're supposed to buy everything in a C data tag.
Speaker 3: Right, Yeah, there we go. Sweet.
Speaker 1: Yeah, all right, let's do some pics, Dave. Why don't
Speaker 1: you start us with picks?
Speaker 4: All right, So I recently got a star Tech under
Speaker 4: desk computer mount to free up some desk pace, and
Speaker 4: this thing is really cool. I mean, granted I now
Speaker 4: hit the computer with my knee a bit, but having
Speaker 4: it off the desk is really nice. So that's my
Speaker 4: first pick, and sur probably my computer weighs like thirty
Speaker 4: five almost forty pounds, and it supports the weight nicely.
Speaker 4: And then the second pick is not to offens. So
Speaker 4: with the age of digital learning and two of my
Speaker 4: three soon to be four kids we're expecting if you didn't.
Speaker 6: Know, they congratulations.
Speaker 3: Thank you. Yeah.
Speaker 4: I think after three kids it's supposed to be condolences,
Speaker 4: but thank you.
Speaker 1: Anyways, I have five. You're going to name the next
Speaker 1: one Pearl.
Speaker 3: Yah.
Speaker 4: No, I've been xnayed on any more develope programmer kid names.
Speaker 4: I already got Ruby, so that's that's a win. But
Speaker 4: with these computers that ended up building for them. I
Speaker 4: just went to my local microcenter and bought a whole
Speaker 4: bunch of parts. One thing I forgot to get was
Speaker 4: case fans. It came with one case fan on the
Speaker 4: back for exhaust, but I didn't have any intakes, and
Speaker 4: so I had some spare RX five eight graphics cards
Speaker 4: and did some load testing and let the kids play
Speaker 4: some games, and that case got super hot. So I
Speaker 4: went out and on Amazon ordered a couple of Noctua
Speaker 4: case fans and those things are amazing. Not only they
Speaker 4: quiet even when they ramp up, but it made a
Speaker 4: huge difference in the cooling of the PC case.
Speaker 6: So No.
Speaker 4: Two Evans is my second pick, as well as just
Speaker 4: like case fans in general, having enough of them.
Speaker 5: Congrats on your kid, by the way, and I'll also
Speaker 5: thumb up not to I think they make pretty reasonably
Speaker 5: good fans.
Speaker 3: They're usually belliant fans.
Speaker 1: Did I was going to say something dumb, but I didn't, John, What.
Speaker 3: Are your picks?
Speaker 5: I feel like I should recommend like some general type
Speaker 5: fans which you can't like buy anymore or something like that.
Speaker 5: But they used to make these really cool fans that
Speaker 5: were like super silent, but they're like impossible to get
Speaker 5: super expensive now. So this week I just like want
Speaker 5: to to give some pretty much a shout out to
Speaker 5: let because I think that a lot of people are.
Speaker 3: Familiar with sticker Mule. Yes, thank you. I just had
Speaker 3: the name like five minutes ago and I just forgot it. Whatever.
Speaker 5: Anyway, best experience ever getting stickers every time. I have
Speaker 5: gotten stickers from multiple places in the past, and then
Speaker 5: a few years ago I switched and started using sticker
Speaker 5: Mule and I just got stickers again recently, and they're
Speaker 5: just so like flipping amazing to work with. And they
Speaker 5: let you freaking cut out your stickers in the shape
Speaker 5: of your sticker, which is exactly what I want.
Speaker 3: So they're awesome. Just saying they're doing icons or something. Yeah,
Speaker 3: they're great.
Speaker 4: I put them out in the sun rather, I do
Speaker 4: the bumper test, So I put a sticker on my
Speaker 4: bumper and see how it fares to the weather. I've
Speaker 4: had a bunch of stickers which just faded over of
Speaker 4: course of two months. Any Sticker Mule sticker I put
Speaker 4: on the back of my car has always lasted years
Speaker 4: and years.
Speaker 5: Yeah, they're pretty awesome and as far as pricing goes,
Speaker 5: like I don't know. I feel like they end up
Speaker 5: somehow meant managing to be cheaper too than like already
Speaker 5: get them from like Moo or something.
Speaker 3: So yeah. Also Moo doesn't do the weird shapes that
Speaker 3: I want. That's it. That's my pick.
Speaker 1: Awesome, Yeah, I like stick from Mule theer awesome, Luke,
Speaker 1: what are your picks?
Speaker 7: I've got one for fans. This is a an EESC.
Speaker 7: It's speed controller for a drone motor. Can get them
Speaker 7: for about twenty thirty dollars or up. And this is
Speaker 7: controlled by the same PWM signal that your computer fans
Speaker 7: run off, and the vultage going in on this particular
Speaker 7: one will.
Speaker 6: Run off a twelve rail.
Speaker 7: If you want to put it in your PC case,
Speaker 7: you can hook up the minus twelve and a twelve
Speaker 7: and run really quite insane one of these. So if
Speaker 7: you want to make a really ridiculous computer fan, you
Speaker 7: can hook one of these up with a cheap drone
Speaker 7: motor and get them for again about twenty bucks and
Speaker 7: put a carbon five propeller on it, and that will
Speaker 7: move the most amazing amount of air your PC has
Speaker 7: ever seen. It's really unsafe, obviously, because it's designed to lift.
Speaker 7: It's designed to lift things, not to provide a gentle airflow.
Speaker 7: But if you want, if you miss truly silent fans,
Speaker 7: that is a great way to get a totally silent fan.
Speaker 7: I've used one in the past. It's really hot here,
Speaker 7: so I've used one for as a like a desk fan.
Speaker 7: Obviously cats is not safe around cats.
Speaker 3: How many of those does it take to lift up
Speaker 3: your computer case?
Speaker 7: Oh? Sure, So this particular model you can get about
Speaker 7: three kilos of frost out of it if you really
Speaker 7: push it and you get everything matched up.
Speaker 3: So if you.
Speaker 7: Okay, if you yeah, as long as you've got a
Speaker 7: big enough peller, you can lift anything, right. It's kind
Speaker 7: of so my pick for the week is not very
Speaker 7: dangerous computer pans. It is my server request stack, my
Speaker 7: much maligned Engine's Passenger Huma stack, which I'm using, and
Speaker 7: that is my pick.
Speaker 6: You might not like it, but I picked it.
Speaker 7: And part of a motivation for this was a post
Speaker 7: by the Passenger blog which talks about combating slow Loris
Speaker 7: deedoss attacks by stacking up enginets and matter compuber and a.
Speaker 7: They explain part of the motivation behind it. So that's
Speaker 7: my picklog post by Fusion from Partying like it's twenty eighteen.
Speaker 1: Awesome. I'm going to jump in here with a couple
Speaker 1: of picks myself. The first pick is, I've been reading
Speaker 1: these books by Brent Weeks. The first book is called
Speaker 1: The Black Prism and it's high fantasy. Really really been
Speaker 1: enjoying these books. I'm on book four right now. I
Speaker 1: can't remember what the name of the book is, so
Speaker 1: don't ask. But anyway, the Black Prism is the first book,
Speaker 1: and I guess the series is called the light Bringer Series.
Speaker 1: And anyway, I've been listening to it on Amazon. It's
Speaker 1: narrated by Simon Vance, who's an awesome narrator. So I'll
Speaker 1: put links in for the book and I'll drop my
Speaker 1: affiliate link for Audible because that's where I'm consuming it
Speaker 1: and really really enjoying it. And yeah, that's going to
Speaker 1: be my pick for today. Dmitri, Do you have some
Speaker 1: picks for us?
Speaker 2: Yeah, I just thought about the email I've got yesterday
Speaker 2: that this year, as usually, will have a October first
Speaker 2: in October, so that will be my big guess.
Speaker 1: Awesome, And if people want to connect with you online,
Speaker 1: do you have a blog or GitHub or Twitter or whatever.
Speaker 2: Yeah, I will send your links to my GitHub and
Speaker 2: Twitter profile. And also I sometimes write articles in the
Speaker 2: Evil Marshalls book, mostly biographical and the based stuff.
Speaker 1: Cool. All right, folks, we'll wrap this one up and
Speaker 1: until next time. That's out.