4 ms·

There is totally a router, ServeMux, which while basic is enough for 90% of basic tasks if you structure your requests REST-y. As for ORM, you should basically

by donatj 9y ago

There is totally a router, ServeMux, which while basic is enough for 90% of basic tasks if you structure your requests REST-y. As for ORM, you should basically never use an ORM, ever. They’re a crutch. Learn SQL, write some basic mappers and your SQL will be so much quicker and more optimized than an ORM can generate. An ORM is literally throwing money out the window. https://golang.org/pkg/net/http/#ServeMux.Handle https://golang.org/pkg/net/http/#ServeMux.Handle

heroprotagonist 9y ago
I've seen teams of Go developers shoot themselves in the foot so many times with their hand-crafted SQL. Yes, they should know SQL and be better. And if they think about it, and focus on it, they are. But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done. I think the goal behind a good ORM is not to replace making SQL queries entirely. It's to stop stupid mistakes that result from an uneven distribution of expertise. And if they find some area where performance is particularly sensitive and the ORM is not optimal, they can drop down to raw SQL again. If your team members all have expertise and your test coverage and code review processes are very thorough, it's probably not necessary. An ORM is not a magic bullet for every team. In the same vein, the dogmatic advice to "always handcraft your SQL" is also not a magic bullet.
- marcus_holmes 9y ago
  yeah, but... same for any code. A team of coders who don't know javascript will create buggy, insecure Node apps. There's nothing about SQL as a coding language that creates this. It's more that modern coders are used to not having to learn SQL and trusting the ORM to do the thing for them. So when they encounter actual SQL (usually because they need to break the object <-> table mapping) it's all scary and weird. Back in the day, of course, we had DBA's (DataBase Administrators) to make sure that application devs who didn't know enough SQL to not make a mess of things, didn't actually make a mess of things. And yes, we hated the DBA's because they were always telling us our SQL sucked. Great training though. So, yeah, your point is valid, but there's a better solution to that problem: hire a DBA
- timrichard 9y ago
  Just to mention a third way - I've been happy with a QueryBuilder on recent projects. The DB access parts of the code look similar to the rest of the codebase, rather than a chunk of text embedded that looks like ransom note (kidding - I know caps aren't mandatory). Enough fine control to closely influence the generated query. No real performance penalty. There's also a good mocking library available for tests.
deleted 9y ago
[deleted]
manigandham 9y ago
> An ORM is literally throwing money out the window. What? Definitely the opposite. First of all, ORMs are just tools, as the name implies they are object-relational-mappers. That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. Modern ORM frameworks are incredibly more productive with better security and reliability than hand-crafted SQL and mapping code. Unless you're working at serious scale, doing custom reporting, or other complex scenarios, they handle 99% of CRUD database operations perfectly well. Wasting time reimplementing an existing tool is quite literally throwing money out the window.
- marcus_holmes 9y ago
  > That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. No. Absolutely not. This is the fundamental mess that ORMS create. Objects DO NOT map cleanly to tables. Eventually your code discovers this, and suddenly it's a world of pain because the ORM can't handle it.
  - manigandham 9y ago
    And yet this is reality: again 99% of applications manipulate objects in code, persist the data in relational databases, and map rows to objects just fine. Some mapping is necessary anyway, and from my experience modern ORM frameworks actually handle complex objects and relations much better than fragile hand-written code. As mentioned, if you're in the 1% scenario where this approach doesn't work then you already know you should be using something else. Not knowing when to use what is a far bigger issue than any problem an ORM can cause.
    - marcus_holmes 9y ago
      I think it's more 99% of databases are warped horribly to pretend that objects map to tables. If you throw away the concept that anything in your database has to map to anything in your code base, then you design better databases. Different databases, more to the point.

by donatj 9y ago

heroprotagonist 9y ago

I've seen teams of Go developers shoot themselves in the foot so many times with their hand-crafted SQL. Yes, they should know SQL and be better. And if they think about it, and focus on it, they are. But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done. I think the goal behind a good ORM is not to replace making SQL queries entirely. It's to stop stupid mistakes that result from an uneven distribution of expertise. And if they find some area where performance is particularly sensitive and the ORM is not optimal, they can drop down to raw SQL again. If your team members all have expertise and your test coverage and code review processes are very thorough, it's probably not necessary. An ORM is not a magic bullet for every team. In the same vein, the dogmatic advice to "always handcraft your SQL" is also not a magic bullet.

marcus_holmes 9y ago
yeah, but... same for any code. A team of coders who don't know javascript will create buggy, insecure Node apps. There's nothing about SQL as a coding language that creates this. It's more that modern coders are used to not having to learn SQL and trusting the ORM to do the thing for them. So when they encounter actual SQL (usually because they need to break the object <-> table mapping) it's all scary and weird. Back in the day, of course, we had DBA's (DataBase Administrators) to make sure that application devs who didn't know enough SQL to not make a mess of things, didn't actually make a mess of things. And yes, we hated the DBA's because they were always telling us our SQL sucked. Great training though. So, yeah, your point is valid, but there's a better solution to that problem: hire a DBA
timrichard 9y ago
Just to mention a third way - I've been happy with a QueryBuilder on recent projects. The DB access parts of the code look similar to the rest of the codebase, rather than a chunk of text embedded that looks like ransom note (kidding - I know caps aren't mandatory). Enough fine control to closely influence the generated query. No real performance penalty. There's also a good mocking library available for tests.

deleted 9y ago

[deleted]

manigandham 9y ago

> An ORM is literally throwing money out the window. What? Definitely the opposite. First of all, ORMs are just tools, as the name implies they are object-relational-mappers. That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. Modern ORM frameworks are incredibly more productive with better security and reliability than hand-crafted SQL and mapping code. Unless you're working at serious scale, doing custom reporting, or other complex scenarios, they handle 99% of CRUD database operations perfectly well. Wasting time reimplementing an existing tool is quite literally throwing money out the window.

marcus_holmes 9y ago
> That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. No. Absolutely not. This is the fundamental mess that ORMS create. Objects DO NOT map cleanly to tables. Eventually your code discovers this, and suddenly it's a world of pain because the ORM can't handle it.
- manigandham 9y ago
  And yet this is reality: again 99% of applications manipulate objects in code, persist the data in relational databases, and map rows to objects just fine. Some mapping is necessary anyway, and from my experience modern ORM frameworks actually handle complex objects and relations much better than fragile hand-written code. As mentioned, if you're in the 1% scenario where this approach doesn't work then you already know you should be using something else. Not knowing when to use what is a far bigger issue than any problem an ORM can cause.
  - marcus_holmes 9y ago
    I think it's more 99% of databases are warped horribly to pretend that objects map to tables. If you throw away the concept that anything in your database has to map to anything in your code base, then you design better databases. Different databases, more to the point.