Optimizing SQL and ORM Practices for High-Performance Applications - JSJ 650

for the back end up. The main thing our company is built Home is build construction resident shams. And yeah that's me.

that can be a tangent for later. But so we started off writing our graph QL back end in type script and you know, went to go pick an orm because that's kind of what you do when you do these things. This is probably twenty nineteen or so. And one of the things that we ran into just right away was just pervasive M plus ones and a graph

QL and back end. So you know, graph CUOL is not like your typical endpoints right where in the typical web endpoint, you know, slash authors or whatever, you know exactly what your endpoint is going to do, so you can do one big query kind of upfront to you know, preload your data as much as you can and then let your logic run, you know, afterwards. But graph ql has such a dynamic you know, there is no single endpoint.

Every quarter is so dynamic that you know, the engineer can't just upfront write the exact you know, preload or query or whatnot that it's going to magically load the data in a perform a way. So we've been using another ORM or two at the time, but we're just really struggling with M plus ones and so that was really joyce first claim to fame is that we had started out doing some co generation from the schema and that sort of thing, which is very standard now in

a lot of ORMs. But yeah, we're just wanted to fundamentally solve M plus ones and so we started out putting Joyce on top of the Facebook data loader project, which uses this little you know, that event loop tic trick if you guys are familiar with that, to you know, if you know the N plus one problem, right, if I've got an author and I'm gonna read some books, and then the books I'm gonna read the book reviews, it's really easy for as you go down your object

graph to like make a query for every single books, reviews, over and over and over and over over right and plus one, I guess. You know, let me know. If you want me to go slower through the N plus one problem.

that sort of thing. But if you think of them as objects, it's really easy, which is kind of the slippery slope of a leaky abstraction, right, because if you think of your entities as objects, which is what entity or ms do, it's really easy for programmers to accidentally write four loops that cause database queries, right, because if you have an author object and you're like, oh, I'm just gonna ask for the books, you know, one of the things that entity based or ms do is is

they do this lazy loading of like, oh, you don't have the books, so go get those for you, which seems really nice. But as soon as you do that in a for loop, now you've you've got an M plus one, and that's been a problem in or MS, just like fundamentally forever. You know, as soon as you start doing and what's what's annoying is when it's it's

more obvious when it's in the small. You know, if you've got an endpoint and you're right in your one endpoint file and you've right there in the code, you've got a for loop, You're like, well, I loaded the authors and then within that I'm loading the books. It's very obvious within this file that I need to you know, hoist my data loading up out of more my fore loop. But what's kind of insiduous about entity based or MS is is when you start running side effects and other

drive business logic. Like you know, entity or ms. They like to put methods inside the author class to do some business logic or have an author life cycle hook or or these sort of things. And as soon as some of those side effects start, you know accidentally or sort of what's the emergent behavior being called in a loop? Now you know, you're back to an N plus one.

And what was maybe interesting about graph QL was just like how quickly that happened, right, So like if you're in a rails back end, you can go, you know, two or three years and you know, fight your you know, you have your every two weeks and plus one that somebody goes and you know, figures out a production where it's happening and tries to magically hoist the data loading up to the top of the endpoint. And and that's just kind of a cost of doing business in a

big rails back end. And but you can kind of get away with it, you know, until you your scale is too big or whatnot. And maybe what's unique, and maybe I think why graph ql has maybe not been as popular as it could have been is just how easy that is to happen. It happens right away in

graph ql. And so that was really what Joyce set up to solve, was we wanted to make a back graph ko background back end that didn't suck, to go right right, and we leaned on this Facebook data loader, which did actually come out of the graph ql community. It's it's you know, we're sitting on shoulders of giants

and those sort of things. But maybe what's unique about Joyce is the data loader pattern had been around for a long time, but engineers were generally expected to integrate it by hand, right, you go into this graph QL resolver and do your data loader logic or then you know there's i know, the graph quol frameworks like the fastifies and we're curious and those were of things that you know, they have the data loader pattern built into it, but you as the engineer had to go make use

of it, and that's his boiler plate and nobody does it, and it's it's kind of annoying. So Joyce claimed the thing was that it's like every operation asterisks, there's one or two that don't, especially like paginated it's very hard to do passionated autobashion. But otherwise, like every operation and

joyed auto batches through data loader. So if you asked for an author and you accidentally out ask for an author and a loop and you asked for fifty, that's you know, one sequel call if you accidentally or not and accidentally, you know, on purpose, load a bunch of books in a for loop, or a bunch of books in a life cycle event, or a bunch of you know,

in a graph QL NaSTA graph col resolver. Basically, every operation enjoiced goes through a data liiver for free and gets auto batched, and yeah, that's what got us started down the path.

terrible and every you know, everybody hated it. But yeah, the people do a node in twenty ten, man that you were that was hardcore.

a pretty pleasant environment to work in. And so to get back to what data leader this is basically because you have to await everything anyway, the promise in the event loop is basically what sets a really fast timer for you. So like, pretend we weren't in JavaScript, we were in Java or you know, o G Java or something like this, and you're like, okay, well I'm going to do you know, ten wire calls or twenty of

wire calls. But I don't really know how many I'm going to do, right, because before you start your four loop, you don't know if there's five books or ten books or you know how many books that four loop is going to go through. And so you kind of but but you don't you want to make that first book call and I have it not go right away, right, because like as soon as the io leaves the server, you know there's your inmplus one. So you want to

go through your your probbial four loop. You know, maybe this is a graph QL server run time or whatever, but you know, let's think of it as a four loop. You want to like ask for book one, ask for book two, ask for book three, ask for book four, and have these like not actually happen yet. You want them to just be I'm going to goad and jump to the term promises. You want to to be a promise of a book, and you want to wait until

you've asked for all of the books. And there's the hard thing is you don't know when you're done in most environments, right, So like an og JAVA or something like this, you'd write a four loop and you would get to the end of the fore loop and then you would have to like tell the run time to like, Okay, I'm at the end of the fore loop, ask for all my books. You know, flush my book calls and

you could do that, but nobody does. And so what's really interesting about promises instead is that the very first you know time you asked for a book, it puts a little I want to use the term poison building, but that's not quite right. It puts a little hint at the end of the event loop, which is going to run right away, right right. It's not like a set and Millie's fifty or a set Milli's one hundred.

It just says, like, you know, in just a little bit, the next tick, right, plush, plush, my sequel calls and that's it. Like that, that's the end of the trick, and it's It's really pretty surprising how such a simple little idea can you know, fundamentally transform the performance in ergonomics right of choice, like with joice and things. Using data Vader, you get this really elegant you know, ervergence, autobatching. It just works, it always works. You don't have to do anything to get it.

plus one problem. But it the query builder in general is built that way, but it's more of a chaining type of thing, like you you can keep chaining the query builder and then it waits until next tick to actually resolve the query builder into something. So by the time you await it, you're awaiting whatever is at the end of the chain, not what's at the beginning of

the chain, or or the chain collapses. I'm not really sure what the how the mechanism works, but I do know that it has it has similar magic where there's state management inside of the query builder that's waiting for that next tick in order to resolve the query builder. And this this looks This looks similar, but it's got more of a a naive looking you know, like like it looks naive and then you it look it looks like you have a dot each, So rather than using

the four loop on it, you use it. Well, I'm I see where you're you're building the query. I don't see where you actually use the query. I saw one example, like there was a dot each. Is that what you're providing? So people don't people don't call four each, they call dot each.

I guess that would be one thing I think we kind of use this as a talking point is how active record, I would have heard, has not really solved like in the same way the joyst has solved M plus ones. You know, inactive record is is kind of this whack a mole job of finding where you need to do your load hint, you know, preload hint. And we can get into it maybe a little later, but but Choice does have the concept of preload hints to make all of your weights go away, which which is

maybe a tangent. And so in Joyce you can do preloadhnts because you'll get more ergonomics and you don't have to awight coat, but you don't have to, like you'll still get this emergent auto batching behavior even without. And it's interesting you mentioned objection. I'll have to go. Look, it's been a while since i've you know, for sure

taken a look at the other or ms around. I think a lot of the ORMs that I've seen, you know, do require these hints for the engineer to like know upfront what's going to happen, you know, to know upfront that in my query I need to ask for this, and in my query I need to ask for this because later somebody is going to use it, right, because

later somebody is going to do a for loop. And that's really the beauty of the approach is it's there's you know, any emergent behavior that actually accidentally runs accidentally or on purpose runs in a loop gets the gets the autovension.

do wrap our relations, you know. So this would be author dot books, you know, that's the books relation or author dut publishers, the publisher relation, and some of the og ORMs like type orm at least back when I did it, and I'm ninety percent sure they still do that, and even the java ORMs the hybernates in the world.

What a model of those like? As the array directly right, author dot books is literally a book array, but it's not really because it has to be lazy loaded, right, and so then they do various proxy lazy loading magic to make it look like a book array as soon as you access it. We go ahead and wrap all of our relations and these little rappers that you can either ask to be loaded. So like on that load safe relations, you'll if the publisher's not loaded yet, the

type system knows about it. If this is kind of the tangent that I was alluding to earlier, is that when I used type orm back in the day, because of this, the type system would never know whether something was loaded or not. Right, if you just gave me an author and I wanted to get to the books, sure I could do author books, but but I didn't really know whether that had been loaded or not.

Or maybe I'm getting my podcast mixed up. Well, the promise promise is basically a monad unless you talk to the TS affect people, and the TS effect people have strong opinions how promise is not the perfect monad, and they have their own effect that is the more perfect monad. Which is fine, but I I don't know. I think it's a little maybe academic and promising is just fine to me, I guess so for.

answer is equal to forty two, that's a value. If you were to wrap answer in a promise so that you have to do something else like call dot then or in some way unwrap it in order to get the value forty two out of it, that's a monad.

ask it for its value. That that delayed execution is what allows you to do fun things like autobatchet sequel calls.

got to await everything. Right. So if you've got a little you know, let's say ten to twenty line method, and you want to go from you know, the books, to the book reviews to the review comments, and every single one of those is is as you know, you're

gonna have to await promise all your top loop. You're gonna have to wait, promise all your inner loop, and you're gonna have to wait, you know, promise all your third loop, and it, you know, and then flat map the promises together and something something something something, and you can do it. But you know it's I couldn't you know. I guess I'd ask GDP to write it for me the first time round. But but what joyceless you do

with these load safe relations is if you do? You know, So I just made a big deal about how the auto bashing of our sequel behavior is very emergent. You don't have to declare load hints and preload hints to get that performance of those. But if you do, you know, at a load hint, you know one of these like I want the author and I want the publisher and the comments in the books, which I think is you know, aj kind of like the objection query builder is my guess of what that syntax looks like.

We'll add in because joys and the choice run time and the typescript type system knows the data is there, we'll add synchronous methods for you to be able to get at it. Just do this, get to this skit, and it's as if it was a raised in memory or our entities of memory, because it is now and we know that it is now right. Whereas if you hadn't done that load hint, we don't really know. You know, there might be an I'll call there and so you

have to await. But I would say that's probably the second on the list of what you know, what makes things, what makes joyce novel and pleasant, it is maybe this load safe relations to just remove some of the aweight dunks that you would know.

was a little bit further down. I was looking at the after it says yuck, and it says anyway, I think I I think I get, I think I get what's going on. But no, my question still stands, so yuck. Given this compilation, some r ms in the JavaScript space sometimes fudge collections must be a sync da dad and then it and then it has three lines here and so there's one line where it awight dot load for author, and then there's another line for a weight dot load

the books. But that one is not doing books equals right. So this one, the type checker still wouldn't know for certain that dot get exists because this one didn't do a book's equals authored books dot load right. Right, yeah, okay, okay, all right, now now I'm on board because typescript does a lot of magic. It does a lot of magic, and I have sure I have fought with some of that magic. And you were you were teaching me new I thought you were teaching me new magic that I

needed to know. But but no, it's it's it's it's old magic, old magic. Got it.

cleaned up a little bit. I don't know why the camera keeps going out of focus, but uh, the intent was to show that type O REM was probably the m other ORM I've used the most before Ritey joiced it, and it was five years ago, so I have to, you know, add all sorts of disclaimers that maybe they fixed things camerah that you know, you'd have to like magically access a relation in one part of the code base to then like access it in another, and it would just it would just work over there and you

wouldn't have to await it. And I don't know, it was kind of magic magic at the distance, as I recall, But but disclaimers, that was a while ago, and it was what that section was attempting to show, but yeah, can probably be for stuffed a little bit.

doing this way. So you are the genius. You're the genius that discovered the simple way to do it.

how are we modeling the world? You know, I like domain driven design, although there are can they're sign a kind of some complexities in cargo culting ish around some of the domain driven design stuff.

I call the or or I don't. I don't I call it something different, or I don't even have the concept of a bill right it with within the code base, or you know, for any of the other you know

sort of workflow. You know, you know, I'm falling back on like you know, uh, crowd app, you know, credas, enterprise spreadsheets and those sort of things where you're you're making software for business users running a business that you know, all of the business concepts have a matching concept in the code that kind of matches it as much as you can, and you know you don't want to, yeah,

as much as you can. And so that's the the ubiquitous language side of things, and and the domain driven design sort of things is kind of a set of patterns around you know it really kind of I want to say it's at the heart of it. But you know, if there's a bill concept to the user, you probably have a bill entity. And if the user has a you know, bank account concept, you probably have a bank

account concept and that sort of thing. So just you know, modeling the world that you're building your system around in your code base, I guess better explanation hopefully.

there's a there's a payment object. So just the idea of being fairly fairly one to one, not not having too many abstractions over what the the the need is for the customer to get done and the way the software does the design is built.

We try to, you know, add some first class features on top of just just a table, just a database table and just columns. Right, so we try to be very explicit about well we can get into some of our reactivity sort of things. But you know, even if you start talking about database tables, you know, some of your tables are you know, primitive columns, which is great, and some of them are your foreign key columns which

are your relations and all. All of that's fine. We want to talk about let's do a cross sense of the validation rules. So you know, while this might get a j will tiptoe into your you know, just stats for ORM sort of discussion. Like one of the things that I do, I think entity ORMs so and and the economy between. So I mentioned the term entity based

or amalot, I would say. The other style of working with data is quiry builders, right, So the quary builders of the node world are like the prismas Drizzle are probably the big two these days. Keithley is another, if I'm saying their name right. But on the query builder side of the spectrum, you issue every single call that the ORM does. You do directly, right, you make the

query and it the quary builders just facilitates. You're doing that in a very you know, nicer syntax than writing raw sequel, and you you know, hopefully you'll get some type safety from it because the quarry builder looks at your database schema and does some type checking of your typescript DSL and that sort of thing.

need is two? And the answer to that is, of course, well you're going to need the other ten or fifteen otherwise you wouldn't have them, so you might as well load them and then just cash them.

of book, you know, book review. They can knock those things out any any day, every day. What gets hard is the queries that like, oh I want to join and left join over here and then group by then having and all of those other sort of things is really where ORMs are not so great, but historically have come with quiry builders in them somewhere to at least try and let you do that, which maybe another unique

thing about joys. We don't have that. Like, I think that's a very hard problem to solve, and I haven't decided to tackle it yet just because I mean, the stuff you can do in SQL, I'd rather just write SQL. Like I think there's a yeah, yeah, you know that there's this psychotomy where people think that, well, if you use an ORM, you have to do everything through the ORM, or if you do a quiry builder, you have to do everything through the quiry builder.

But from what I've seen, the r RM came about because Postgress became popular, and suddenly people wanted the the you know, the hoity toity people that were using postgress my rather than my sequel, or the people that just wanted to do the lowly people that were using sql

light rather than my sequel. They wanted to be able to say, my open source project is for you too, and so rather than having their project work really well with my sequel, they started making compromises so that would work just as poorly with Postgress or with sql light as it would work with my sqel. But from my from my framing, that's how O rms came about was instead of let's let's just use the tools of the database, well let's castrate them so we might as well just be using ago.

going to support sequel light. And rather than just supporting GO, which I'm totally fine with them doing the Jason format because that's a way of abstraction that seems right, they're like, oh, and we're gonna have a Typescript specific driver and we're gonna have a Python specific and so now the project's kind of you know it ye, Like, I guess it's not a paid product, so you can't complain. The author's

gonna do whatever the author wants to do. But instead of chasing dollars, the author's chasing stars, which means that now you get more stars by introducing to a new community once you've captured the stars of one community. So making your Postcress Driver better isn't going to get you

but another ten percent of stars. Creating a my sequel driver is going to double your stars, right, and so then the quality of the Postcress Driver, or at least the response time to issues with the Postcress Driver go down. When it's like, but this is why I wanted it. So I hope you never support my sequel, not because my sequel is bad, but just because if you could focus on doing one thing, well yeah, then it'll work.

really have qualms, you know, go back and forth. Like when you're a project small and dedicated, you can do whatever you want to it and and we can do that now.

is with the with the Ruby with active record. Yeah, you use the post gross driver and then active record takes advantage of that to query the database. But if you want other features that postgress provides that are not you you know, specifically provided by active record or specifically provided by that driver, you can pull in other libraries

that add the functionality. And so it really depends on what your goal is in my opinion, right, is your goal just to solve the particular problem that you guys have, right, Because if that's the case, and it does a really good job of it, and then yeah, other people who are using PostgresSQL and are writing back end code, I'm presuming you're using express or something. You're right, Yeah, pull, pull,

in pull in joice right, makes sense. If you're using my SQL then and you really want a joicst like thing, you can fork it or you can find something else.

We can get to yours when you get to but is this like obsession with putting everything that some projects have not every but a lot of projects have with like making everything go through the ORM, right, which, then you know, Charles, you run into like, well, the ORM doesn't do this for post creder, doesn't do that for

you know, my sequel or whatnot. And I don't have that strict of an opinion about it insofar as like I think borms that do ninety percent of your applications boring cred quarries, right, which which is by far the far far majority of queries we do, is super boring crub that is probably exactly the same sequel across five to eight top databases.

where you need it. And I think that happens so when you need it, you really need it, but it happens so frequently in a large application. It's like sub five percent of the time, probably five ten percent of the time that you can still get a ton of benefit from the entity or side of things through all of the super boiler plate stuff. And and also for the that super boiler place stuff I think is also what's most common commonly is supported across the you know,

most popular databases. So we are a post ray right now, but only But I don't think it'll be a big shift from our vision to Polina my sequel or something like that. Get when do we get to it?

what it seems like. But then once they were there, it started to kind of like functional programming was also you know, hitting one of its uh one of its phases, and so it's like, oh, look, I could do the chaining, I could do I do all the functional program Functional programming is more amenable to relational algebras opposed to the Java style programming that it was you know, existed at the time that this stuff seemed to be really taking off from from you know, my point in history, which

I'm you know, I missed a bunch of fit because I came in kind of not I thought I was in the early days. Maybe I was more towards the middle of it than I thought. But anyway, so, so you've got that, and then but so then the whole thing is, well, you know, now it's typed, and now it works in your language, and now and so and so SQL became the bad guy. It's like, well, the o RM isn't just so that you can support multiple databases.

It's actually because it is the morally superior choice. Good people use rms because they're good people, and and so then so so it's like, well, if you buy into the idea of an ORM, then you're a good person. And if you're a good person, you're not gonna raw dog the sequel, are you, because then you lose your portability, and then you lose your functional programming, and then you lose all the things that are so enlightened. So how how do you have this the economy where you gonna say,

use joys to RM? But actually, yeah, rob Dog the sequel when you need to.

love types, right, I really love static typing. I love code, you know, generating you know, the database schema and pulling those you know, like the act of what active record does, like that, you know, is really what joys trades to do. You granted at coaching times, so the typescript compiler can see it. But like there's a limit to where like

let's just write some sequel. And I think especially because it just doesn't happen that often, right, Like, and that's what makes me feel not so bad about it, Right Like if I had a one hundred thousand line code based in fifty thousand of it, or like entities and the other fifty thousand were you know, raw dog sequel, and it was very hard to see when you you would use each and you you know, there were little camps of like on this one you you know, which

one do you use and that sort of thing. But at least on the projects that we've got going on so far, like like, it's really pretty obvious that you early seems like it that that you know, you do use the r M for as much as you can, but then those last few and in terms of what it actually looks like, we don't have a little bit of glue. So right now, Joyce sits on top of Connects, which is just another it's one of these query builders. It's like the key sleep and that's what Joyce itself

sends the queries through. And so we use the same connection pools as Connects, if I'm saying that right. And so if you.

you know, ORMs were really great for cross database compatibility. Actually, I don't know if that's the case. I know that that is a purported benefit of the ORMs, but just like, how often have you really seen a project my great databases? Like it's just like, well, that's the thing, Like it's not gonna I think that.

social credit. And I believe that what it was is they wanted to get other people in their community to wash that download tick or source sports go up.

as you you know, want it to. And granted you have to pay for it, but it's an amazing product and I have no desire to run on anything other than that. But oh, but that's not why I use the r M. Why use the r M is business variant enforcement, right, So validation rules such that you know what, I my my just credulity with the Corey builder approach is like, you know, let's say I'm in my author endpoint, I'm in my save author endpoint, and I'm going to

do an insert an update. Let's say I'm going to update the author Okay, so somebody raw dogs an update to the author table. What business rules did they check? Well, you know, before they switched that first name, before they updated the you know, book title, or before they increased the book rating, and like how many derive values, validation rules and drive values are trying to watch whatever they

just updated, right? So uh, you know, let's say that the author has a star count right and or or you know these sort of you know, Active record has some countercashers that we haven't quite flung that yet, but just in general, the idea of you know, after you update this row in the database, something else needs to know about it. And that's why I use RMS. I would just be super scared of like raw dog and a s an update to an author and forgetting what else did I have to do? You know, what other

validation rules did I have to run? What other dragau should have to update? And those are the two things. You know, we were kind of into the third phase of what joyce is amazing yet you know M plus one and you know avoidance was the first one. Second one is those you know, populate hints to move a

get rid of a weight gunk. And the third one is this like not only validation rules and life cycle hooks, like active record has the you know, we have active record style before flushes and before updates, we do cross entity reactivity, which is kind of a fancy marketing praise from it. So I guess I am kind of putting on my my marketing hat here. But so you know, on the front end, reactivity is a big catchphrase right of when you update the component over here, you know,

the reactivity is updating all of the component. You update state, you know, you update state once and then it gets broadcasted out.

long or is it too short? Is it an email rejects? Is it not no? Or whatever? And those are fine, you know, that's that's what a ZOD can do for you. But you know, when you start talking business and varianceisconds back to like some of the bigotous language and being driven design when you go talk to your you know, your business users and they're like, well, I have this this rule. I use the term invariant, this business rule that I want to just always be true. You know,

I want this to always be true. And it's probably not going to look at just what the first name is. Is the first name too long or too short?

just on with one on one entity. But then it's also very common for like the rules to want to like look across entities like well, if my author is has some sort of status, right, if my author is employed, And then my other validation rule in the books, like the books can be you know, sold or something like this, right, and so these sort of cross and variant validation rules.

That's why I use ORMs, and and I hope you know, I can't speak for others, but that's that's what I would assume is an attraction to the ORM is not just like abstraction from the SQL database I'm using.

because business logic is the most likely to change. And so anytime that storage and messaging are together with business logic or you know, either one of those or together with business logic, then it it just it's always a nightmare when X needs to change, well now you have to go change Y and Z as well. You know. So I'm I'm very I'm very much a business logic goes in the business logic place. Yeah, And that's so fundamentally my stack, my ideal stack is routing is global.

Business logic is per component. Storage is more or less global slash hierarchical. But like the business logic uses the storage, it's not in the storage. And then messaging likewise, messaging might be global with like some hierarchical component to it.

But yeah, the business logic uses the messaging. So what I'll do, which you don't see this in a lot of code bases because people like to abstract it away, because I want to function that's like save that's going to do the business logic, do the storage logic, and do the message logic altogether. What I'll do is I'll literally like call the get function, take the data, call the business function on the data, and then take the result,

and then call the messaging function. But then then whenever it's time to refactor, whenever business logic changes, it's like I got to go and just change that one thing. I don't have to go change my storage module or my messaging module or or whatever.

have well the terms the same POJOs. You know, plain old although this was Java now, you you know plain at old JavaScript object or plain old Java object you know, passed between your layers, and you had to have a storage layer, and that was the only place they could put like data into your your your POJOs. I guess what you know? I think this is what I learned from active record and the pattern in general, but then

also Ruby. The implementation is that if your storage matches, this gets to kind of the domain model, the concept in your bigder's language. If your storage schema matches what your you know, potos supposed to be anyway, the storage layer just goes away. Right, There is no storage layer anymore.

pristine oh kojo later. Right, that was all you know, your ivory tower of which you really wanted it to be. And to me, that's that's where the whole you know, or MS or the Vietnam of computer science came from. Is that the Yeah, this notion that that you have, oh right, the object relational mismatch you know, that'll get you know, thrown around, is in like somehow objects are just fun only different from relations. I don't. I don't think that they are like you know, I think if

you they don't have to be anyway. I I think they were back in the day when you've had super terrible, terrible oracle database schemas that you wanted to map onto your different set of you know, objects, you know, that was an impedance. But that was not because of the technologies. That was just you know, because your schemas were so terrible. But you know, if you have the freedom to make your your you know, database schema what it really should be. You know, if you have an author, you have an

author's table. If you have a book, you have a bookstable, and you know the columns match which you wants them to be, and you can change them with migrations extremely

quickly in a C I CD pipeline. I think that impedance goes away and you start thinking of your your relational database as a graph database, really just a graph database at skills really well, because for whatever reason, graph databases haven't really taken off and can you know whatever, but you know, you think of your relational database as a graph database. And now your storage leader. Coming back to where you put your business edge, there is no

storage layer. The RM just doesn't. And so now what the entity has become is not a storage layer. They are business logic player, right, so when you're you know, you say, well, I'll have my business off somewhere else. This is one of my criticisms of the quiry builders is that you have to do just what you did. So, like Joyce and our entities, we provide a framework for business logic and we've we've attempted to vet it and attempted to organize it and attempted to, you know, design

a really pleasant way to organize your business logic. I'm gonna say, like separate from your storage layer. But there is no storage layer. That's kind of the point.

I think I think that's what you're saying, Steven. And what I find is that this probably works ninety five percent of the time, and then the other five percent of the time you have to go play the game of Okay, I've got something that's a little more complicated than just business logic in this one narrow vein of users for example, Right, And so what I wind up doing is I wind up creating some other entity that manages that business logic and that workflow and all the

things that are involved in that. You can call it a component, you can call it a service, you can call it whatever you want. But yeah, you wind up solving that in a different way. And I think sometimes people get into the arena of saying I don't like rms because they don't solve things in this five percent

or three percent of the time exactly. And the reality is is it's like, look, it does all this stuff for me the other ninety five to ninety seven percent of the time, and so I'm gonna use it because it gets all of this garbage out of the way and it makes all of the storage stuff invisible to me, and it gives me a place to put the stuff that I care about and then yeah, I'm gonna have to go and I'm gonna have to special cases other crop.

tool for that job. Sure, but that is in your like zero point one percent. I think like it's very rare that you need to do meta manipulations on a table in an application that you're like multi vendoring your application in that kind of way. But like for all the stuff that it but all the stuff that an orm is gonna do, typically C is going to do for you. It's just that you just write the sequel, and you write the sequel as specific as you want.

And what it does is it uses the Postgress query builder, like it links to the C code, and so it runs the C code and then it gets back basically the like it knows what the C code object is going to be, and then it translates that to JSON and then translates that to GO or in the case of Go, it might do direct because they didn't have the Jason adapter. The Jason adapter came before they created the adapter that goes to the other languages like Python

and Typescript. Originally it was just straight from Postgress to GO. But anyway, so it hasn't it. It reads from the Postgress specific type system into a broad type system, into the languages type system, and so you get all of the typing, you get all of the objects. It's very easy to yeah, any anyway, so so that that's where that's where SQL SEE in particular, I think is is

the best in class. Although it's it's probably not something many people have a mental model for because as far as I know, it's the only one of its kind. It's it's another one of those obvious ideas where once you see it, it's like, oh, why haven't we been doing this for the last twenty thirty years? But yeah, you know again, but nobody did it.

And then what they do is they just you know, they parse that seqel type check it, and then generate a little binding around it that says like oh, if you you know, they cogen out a wrapper, that's a method, you know, a method that will really just load that

little SEQL file and then call it. So it really is a pretty neat way to get, like you out of like writing raw dog sequel inside of strings in the database or sorry, in your in your typescript file, or you're going five into like what is actually a

SQL file. I actually think that's pretty great. My disclaimer would be like for those three to four to five percent of cases where I want to be raw dogging sqel, and the other ninety five percent, which is like the super boring update author's credit statement that not only is the very boilerplate to write the the you know, update authors SQL which which you know I don't want to write but maybe you could say, is not fine, but all of the invariants that I need to go make

sure still pass right, like sure I updated the author, what other business rules.

orient to get data out of your database. The other forty is a way to structure your business logic. Instead of everybody having to kind of make up their own and hope they do it right and in those sort of things. Grant it is a very opinionated way to structure because it uses entities, and it uses life cycle hooks, and it uses some reactivity is it? But it isn't pin neated.

then here's where you plug in your storage adapter. But I think that people are more familiar with the idea that the ORM is going to be the framework that dictates business logic rules with the data association.

You know, I want to make the disclaimer for the audience that the the r mu US is a big bet on your code base, right, and so we take very seriously that if you structure your code base around Joyce, that that you're taking a bet. And we really do respect and appreciate that. But yeah, but would love to have anybody kick the tires and point us out. You know, AJ, you've found a few things in the docks that could

probably be for stuff. Would love to have you know, any issues around those things to help you on boarding process or things that we're missing. Would really appreciate it.

I hope that that goes forward. I'd love to see one day where you know, maybe collectively we can just all drop typescript because the typescript checker is so good at JavaScript types that you don't even need to annotate anymore. It just gets it. That would be Amazing's that's like

zig level. The other thing is there's a module called my sequel dump TS my SQL hyphen dump pipal t iphen ts and this will allow you, of course to dump tables out of your my SQL database and then get the typescript of them, and then you can run the typescript to jes doc to get the jas dock of them, and then you can start to you can start to make your code better in the sense of being able to have type checking, you know, misspellings checked,

et cetera, and add to them. Yeah, I don't think that you would need if you're going this route, I don't. I think joycet is solving this problem for you. If you're adopting JOYST I don't think you'd need these. But this would be in the case where you have an existing project and you're trying to get certain parts of that project in a in a better way so that

you can feel safer and sleep better at night about it. Then, of course sq se SQLC like I said, it's kind of like a reverse sequel query builder because you just write the sequel and then it gives you the queries. And it's not a binding. Just to be clear, it is, well, I mean it is a binding from the perspective that it uses the sequel driver. But it's it's not it's not calling that that well, it builds, it builds out it it builds it out. It's not it's not copying well,

it is copying from the file. It's not using the file you created anyway you can see what it is. But sq C I think is the smartest approach because it seems like it covers not the ninety five percent but the ninety nine point five percent in terms of as long as you don't need to do meditable manipulations, it's got your back and it's and since you have to learn SQL anyway, query builders don't alleviate your need to learn SQL. If they did, then I'd say, yeah,

let's get on the query builder. But the truth of the matter is, at the end of the day, chat GPT is going to be bomb awesome at generating CQ for you, and it's going to be mediocre at best at generating queries in your query builder of choice. Well, I don't know. I haven't tried it with that specific use case in the most recent version, but my previous experience with it was it does awesome its SQL, and it's really mediocre when it comes to the SQL abstractions.

So sql C is something that seems to pair really well with LMS in terms of being able to get the statistically likely correct sequel, which sl really lends itself incredibly well to statistical analysis, like that's a match made

in heaven then Sloanik. Sloanik is kind of a different approach in terms of you are putting your queries inside of templates, inside of your JavaScript code, but it is it's kind of a middle ground between SQLC and a query builder in that it's doing the query building dynamically, but you are getting the type check on it. But SQL see I think, I think sql C is the real gold, but sloanik is something that's certainly an interesting option.

And then you've got template blocks that are SQL tagged and so you can get highlighting and stuff like that. And then so that's the SEQL stuff that out of the way. Two other quick things, swift UI seems like amazing and the Android jetpack composed is either it's either the clone of swift ui or swift u I is

the clone of that. And you know Apple likes to perfect things when it clones them and then pretend like it's the first because it's so good that you know, they knock it out of the park when they do it. But there's two talks swift UI essentials and introduction is swift u I. And if I close my eyes, what I hear is react React, React react, But when I open my eyes, what I see looks more like view and like, oh this actually, this actually looks like it

would work. Because there's there's the there's the promise of react, and then there's the reality that we're all kind of familiar swift Ui seems to be both the promise and the reality of react. I'm really interested to get more into it. And then last thing, I am going to make a political pick. I Oh, Trump just makes me so ah, can we not have good choices? But then but then every time, every time I think we're the dregs where the bottom of the barrel? Can this get

any worse? Then it's like he does an interview that's with people that are a different audience, because when he speaks to the general public, I'm just like, oh, please no. But then sometimes when he speaks to a specific audience, it's like, all of a sudden, he's a genius that understands how the world works. And so he gave this interview or did this presentation in Q and A with Frontline, and like everything that he said was actually intelligent, And

then I had to challenge all my beliefs again. And those are my picks.

few months. So he prescribed me. This system is called the Freestyle Libre three and I'm not sure if you can even see it on the camera, but I've got one. Yeah, you can kind of see it right there on my arm, so you know, yeah, it connects to my phone. And so I'm much better at checking my blood sugger because i'll you know, periodically look.

that that kind of come out of it. But anyway, it's really cool. I've had a little bit of trouble

with them staying on. So last night I woke up in the middle of the night because I got an alert on my phone that said that my blood sugar was dangerously low, and so you know, I went downstairs and ate something to try and get it to go up, and then when I came back upstairs, it said that the sensor was no longer working and it was dangerously low because it had actually come out of my arm and then had gotten poked back into my arm but not all the way, and so the tissue it was

testing was not right. It was given it a bad reading, so I have had some weird issues with it.

we also do accountability calls on Monday. There's a book club and we're getting into the AI book from Obi Fernandez right now. We also do a personal development book. We're doing Awaken the Giant Within by Tony Robbins. And you can come to as much or as little of this as you want, but anyway, so it's just a way of doing community based learning and then you know, giving you videos that walk through stuff. So go to

JavaScript Geniuses dot com. I will have that up this afternoon and then you can go in join the vun Steven what are your picks.

We you know, we like it and really props to him. He's trying to go the you know, make a business out of it, right, like not chasing after VC money, but trying to do some support and upgrades and that sort of thing, which is really amazing, you know.

a graph ql server. But it fundamentally, like so Joyce has to when we went through all of Joyce like using promises to like fix up all of you know, all of the n plus ones that would have happened. Grapast is a really that that just like fundamentally happens

with how most graph qol servers are implemented. Like when you know the Apollo in the graph qol community or in the no community, we have Apollo server and we're curious and oh, you know, there's probably two or three or four others, but they all work this really inefficient way. If you go from an author to a book to a book review, it just like it hammers, like each layer down in the graph is just call call call

call call. It's just like fundamentally is as you get down in the graph, treating every single graph note as its own call. And this grast thing just like really flips it on its head. And even as you go down the graph, it's it's making one call for for

all of the nodes that you're processing. So I think it has a really great opportunity to undo a lot of the performance sort of like hideousness that most graph q al things either have to just you know, back INDs, either have to just deal with or patch around, which is what we did and Joyce and yeah, it's still super small projects and I need to spend more time with it, but that is my pick. I think it's pretty neat.

Just be the good. Just be good at the stuff that is the simple that people need the most, and not try to cater towards the stuff where people really should Just go do the sequel. That philosophy makes me believe that this is going to have and hopefully an eternal advantage over a lot of the other ones where they try to give you these like halfway kind of things. So that that's the main point. But it looks, it looks good, and like I said, ILike it looks obvious.

It looks like, well, doesn't take a genius to figure this out. It did, but it's you know, when you look at it, sure it looks it looks obvious.