Are ORMs Worth Using?

orms or object relational mappers have been dominating the data layer for years and for very good reason these days every language has access to tons of different orms tons of different ways to interface with the database and there have never been more options on how you want to go about it in typescript we have some of the battle tested tried and true methods we've got Prisma which many people solve included considered to be the goat and then we've got some of the new cool options like drizzle and stuff like that then in the go World we've got gorm we've got ants and tons of other things coming up and tons of other things in between so there's really a million ways you can do this in a ton of different ways you can handle orms I'm not going to be comparing orms here if that's something you're interested in please let me know I will probably make a video on that soon but for today I just want to talk about really raw SQL versus having an orm and the big differences between the two and why you might want to use one or the other this is going to be part of the long ongoing series I've been doing a building out an app with spell kit for the front end and going for the back end I think these two are an awesome pair so you want to see more content on that make sure you hit subscribe because turn on the notifications and if you want to see what we've done so far you can go back and watch these we will hopefully be working on a slightly more consistent upload schedule but I can't make any promises well well the consistency yeah okay so with all that out of the way let's get into what an orm is and why you might want to use it for this video we're going to be using ENT as our example of an RM this is also the orm that we're going to be using in the series going forward and we're going to be using that in the next video to implement the crud roots for our back end for those who aren't aware what is an orm generally speaking what an orm is it's a way for us to interface with our database typically the interfacing layer between you and your database is SQL now you can obviously if you're using a different database technology like mongodb it might be a little different but I personally have been moving much more towards SQL for vast the vast majority of things lately as I've been getting better at it and I've been enjoying it more I've been pushing more into the SQL world so typically speaking an orm is going to be a way for us to interface with our SQL database but it's going to give us access to things that we wouldn't normally get like type safety is going to allow us to access it instead of writing select statements or insert statements we can then call generated functions from our orm and it'll also typically give us a way to manage the schema of our database it gives us this type-safe way of building out a schema then migrating our database and doing all that stuff you've already used Prisma before I think that's the most common one you get that schema.prisma file and in there you can manage everything about your databases structure you can set up your tables set up your relations and then Prisma itself will actually help you migrate and manage your database schema most orms will give you access to all of that and is no different you can see in here they will give you access to migrations all that stuff this is not an orm tutorial but rather we're just going to be talking about the general concepts so that's what an orn does so let's look at what the code for that might even look like so for this example I've created a really basic sqlite database we'll talk about sqlite in another video but it's basically just a file stored on my computer that works like a normal SQL database it's super useful and super helpful for development and even small scale production so what we're going to be doing in here is I've created this database which has two tables in it it's got a to-do's table and a category table nothing too special on it the biggest thing of note to see in here is that the to-do's table has a foreign key on it towards the categories so the categories can have many to do so we have a one-to-many relationship and what orms will allow us to do is they give us a really convenient and easy way to both Express this and handle this so with all this data let's look at the code going over into this goent example which I wrote out ENT is the phrase is the orm that we're using like I said so what we can do in here when we generate our project this end directory will generate all this different stuff a very common thing you're going to get with orms especially the more traditional ones like Prisma so you need a lot of code gen because what they have to do is they'll take your schema and then they have to generate all these functions on it to actually allow you to run your crud operations on it so for example this one right here the schema directory is the one that I actually mess with So within here within the category it creates this ENT schema I Define what my fields are I Define what my edges are which is just their fancy way of saying relations effectively so this edge.2 to Do's means that the category is going to have to Do's it's a one to many and then what this will do for me is it will generate all of the different methods in here so I didn't create this category create.go function this was generated by ENT and under the hood Prisma does something very similar that's why you're going to get this giant bundle of generated typescript and all this stuff and I think that they even have like a rust binary in there fact check me in the comments if that's wrong but I believe I'm just going by Road I think that's what it is so it generates all this code for you and then with this code you can actually interface with your database so let's look at what we've got here within the category we've got types in here we've defined a name created at updated at we've also defined a relation to our to-do's and within our to-do's we've defined a title description created at updated nothing too crazy here but this is a single source of Truth for our database schema and I can run all of my migrations from here so with all this generated now the way I interface with my database gets really easy and simple we'll go into our DB test file here so I'm actually using test cases to illustrate this because I think it actually ended up making a lot of sense here so I have a couple different functions first and foremost I have the test create database so what this will do right here is it'll see that it'll create the database and ensure that it's migrated up to date with my schema so down here we're going to create a brand new to do we can set the fields do all this stuff and the important thing that we get here is we get type safety so right here you can see this new to do we created this has this is a to-do so the benefit of this is we get type safety out of our database this is a super super valuable thing and makes it a lot easier to work with a database because typically what you would have to do if you just did raw SQL you would just have to come up with the types yourself and then mix them on and cast them on to what you get out of the database yourself and to illustrate that I have over here within the basic test right here this is a little example of what raw SQL would look like so right here we get this select ID and title from to-do's and then down here we execute that query against our sqlite database and then we go through and we can scan out of that and pull all this out so this is much not nearly as simple and easy as the other one is and it also is much more it's much more error prone and it's much more difficult to scale up because here we only have two Fields so it's kind of okay we just have ID and title but what would happen if we had 50 different fields or we had I mean that might be a little Overkill but you know in the real world it's very common to have 10 15 fields in a database table or 10 to 15 columns and a table so we would have to either select all of these or we would have to yeah either write out selecting all these or select star from the table whatever we want to do and then we have to query that and then we have to read all that out here and run scan there are ways around this of course and people smarter than me have come up with better ways of doing this but you know the general concept is if you're just writing raw SQL you're gonna have to do a lot of this by hand versus with an orm it'll handle most of this for you here when I'm going through and I'm fetching the to-do's and stuff out of the database all I have to do is just do client.category.query and then I just get my categories and the categories are an array of categories as you would expect them maybe I don't have to worry about scanning I don't have to worry about a next pointer or not a pointer but a next function call and all this different stuff it just makes your life a lot easier and a lot quicker so that's the general reason why people will use an orn because it will speed up your development and it will reduce a lot of the errors you're going to make people will tell you that types aren't important because just make sure that you write it right and then it won't be a problem but in the real world especially when you scale up and when you have different devs working on a project it gets really hard to keep track in your head of what's actually happening within a database and what actually all the fields are it's a very it would be a very understandable and simple mistake to look at this database table and think okay maybe this description has a capital D in it instead of a lowercase D or we think it's desc instead of just full description a lot of these things can happen very easily and when we have to hand write all this out it gets a lot slower when we have to go check against the schema of a database every time we want to write a query and while the counter argument to that is of course you can get a lot more control when you actually run the queries yourself and write the SQL yourself and this is the one that you're going to hear a lot of times when people tell you hey you should just never use an orm you should always write raw SQL what they're going to tell you is you don't know what an orm is going to be doing under the hood especially when it comes to joins in relation so here we have a basic relation of a one-to-many of our categories to to Do's so when we make a query from our orm that includes the relational data we're not writing the join ourselves so we don't know exactly how it's executing that query now more than likely if it's a large orm that's been well tested it's almost certainly going to be a very good implementation is probably going to be very performant and correct I'm not going to sit here and pretend that Prisma is going to have a less efficient join than I'm gonna have because more than likely they will have a better join than me but when you get super complicated and you get into super weird places it does end up becoming more of a pain and also a big thing to think about that I have sort of noticed doing some more data-driven stuff in projects that I work on like Insider viz is um having to go through and like write out the schema and manage the schema between different projects can get to be kind of annoying and there is something really nice about going through and just opening up a terminal and or opening up a shell and just doing raw SQL against your database and I think personally for me one of the biggest arguments against using an orm at least when you're learning is that you don't learn enough about SQL and this is something that I suffered from and I really have had to course correct on over the past few months is as I was learning and getting better at this I was always using orms I was crutching on Prisma really really hard I got are I am very very good with Prisma and I'm super comfortable navigating between tables and relations and joins and all this stuff on Prisma but I can't do that stuff super well with just raw SQL if you asked me to write a join I couldn't do it off the top of my head I mean I know it's something like you know select X Y from table join like left join I don't know I don't know all of it off the top of my head if you had looked it up I could figure it out but you know you probably want to be able to understand that stuff and be able to understand SQL and understand your database at a fundamental level will make you a much better developer so I think that's one of the biggest problems you run into with orms is an over Reliance on them so I think there's this sort of balance of you want to get better at SQL but if you're actually writing an app especially something that other people are going to work on and it's going to grow you want to be using an orm it's such a foot gun to be dealing with this everywhere and this is so error prone you could screw this up so easily and imagine this spreads out to 10 different entries I mean look at this example right here this is from the fiber auth server that we wrote for this exact project and I'm using raw postgres right here and just look at this query right here I'm selecting ID first name last name email password Etc from here and then I'm scanning them into this so I'm scanning the ID then the first and then the last name that is so incredibly error prone that could get screwed up so fast so easy it would be so easy for me to accidentally do last name then first name or accidentally do email and then first name and last name or put the wrong thing in or the wrong data type you can get so bad so fast and I know that there are ways to make this better and obviously people smarter than me will do it in a more clever way but you know when you get down to the root level of it this is the root level this is what the raw SQL package will give you and go so you're gonna have to deal with this in some way this scan phone function is inevitable it's being called somewhere it's just a question of who's calling it so all of these things are these are all things that you have to take into account but I hope the thing that you get out of this is that orms will make your life a lot easier they will make your development a lot faster and they will make your development generally speaking a lot better because you're going to make a lot less of these sort of silly mistakes of writing your SQL statement wrong but don't forget the SQL the sequel matters and you should understand the sequel and you should understand your database it'll make you a better Dev it'll make you more efficient and I hope you got something out of this I'll hopefully have the next part of the series out very soon if you enjoyed it make sure you like subscribe watch the next video that it pops up here and have a great day

Channel: Ben Davis (Davis Media)

Views: 14,086

Keywords: SQL, SQLite, Postgres, MySQL, TypeScript, GoLang, ORM, Programming, Web Development, Server

Id: 8GYfGPs4Lk4

Length: 12min 30sec (750 seconds)

Published: Tue Jun 20 2023