Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to make websites that will require lots of your time and energy

blog.jim-nielsen.com

Post reply on HN
Print view View original

181–190 of 247 posts

Re: How to make websites that will require lots of your time and energy

#181

Post by djdjnm »

kaptainscarlet wrote: post #148
skinkestek wrote: post #115

Earlier quoted context omitted.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

People who avoid ORMs endup writing their own worse ORM*. ORMs are perfect if you know how and when to uses them. They encapsulate a lot of the mind numbing work that comes with raw sql such as writing inserts for a 50 column database.

I did that once on a hobby project, accidentally. When I realized the corner I had painted myself into I abandoned it.

Re: How to make websites that will require lots of your time and energy

#182

Post by itake »

kaptainscarlet wrote: post #148
skinkestek wrote: post #115

Earlier quoted context omitted.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

People who avoid ORMs endup writing their own worse ORM*. ORMs are perfect if you know how and when to uses them. They encapsulate a lot of the mind numbing work that comes with raw sql such as writing inserts for a 50 column database.

100%. I once tried to optimize a SQL query, moving away from the ORM, so I can have more control of the query structure and performance.

I poorly implemented SOLID design principles, creating a complete mess of a SQL Factory, which made it impossible to reason about the query unless I had a debugger running and called the API directly.

Re: How to make websites that will require lots of your time and energy

#183

Post by lotyrin »

burnt-resistor wrote: post #164

Backend version: - Install a rolling release distro by hand - Install stuff without using packages or configuration management by hand without documenting them - Install stuff on bare metal without using containers or a hypervisor. Bonus points for unlabeled spaghetti patch cable rat's nest. - Don't automate deployment or upgrades - Don't have backups of anything - Don't have a plan for patching, DDoS mitigation, or…

Buy wildcard certificates from a vendor, install them everywhere you find you need them manually, don't write down where you put them or when they're going to expire. Cross your fingers the private key doesn't get leaked.

Collect every metric possible and set up arbitrary blanket alerting thresholds and black-box anomaly detection and tune nothing ever. Now you can hire a whole team dedicated just to suffering from alert fatigue.

Standardize on a single LTS OS release across all your infrastructure and wait until the absolute last possible second to start trying to switch to the new current LTS release, biting off about a decade of OS changes to everything everywhere all at once.

Re: How to make websites that will require lots of your time and energy

#184

Post by sherburt3 »

skinkestek wrote: post #115
superasn wrote: post #38

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

At least when I see raw sql I know me and the author are on a level playing field. I would rather deal with a directory full of sql statement that get run than some mysterious build tool that generates sql on the fly and thinks its smarter than me.

For example, I'm working on a project right now where I have to do a database migration. The project uses c# entity framework, I made a migration to create a table, realized I forgot a column, deleted the table and tried to start from scratch. For whatever reason, entity framework refuses to let go of the memory of the original table and will create migrations to restore the original table. I hate this so much.

Re: How to make websites that will require lots of your time and energy

#185

Post by d0gsg0w00f »

victorbjorklund wrote: post #60
bravesoul2 wrote: post #15

Earlier quoted context omitted.

I think the issue is API breakage. Does your 5 year old NextJS project still work after npm update? Probably not! What about your simple Go server or FastAPI server. Probably yes.

So don't run npm updates because sure then you have the security risks that you have some old code and that is five years old and hasn't been worked on for five years and you also have you missing out on new functions and optimizations. However if you have a five-year-old project that you handwritten everything by yourself you probably have a lot of security issues there too assuming that you are using complicated fu…

Are you saying that because you have to touch it all the time, you're sure it's up to date?

I suppose that's one way to look at it.

Re: How to make websites that will require lots of your time and energy

#186

Post by adampwells »

kaptainscarlet wrote: post #148
skinkestek wrote: post #115

Earlier quoted context omitted.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

People who avoid ORMs endup writing their own worse ORM*. ORMs are perfect if you know how and when to uses them. They encapsulate a lot of the mind numbing work that comes with raw sql such as writing inserts for a 50 column database.

I find that Claude writes boilerplate SQL very well, and is effectively an 'ORM' for me - I just get plain SQL for CRUD.

Complex queries I write myself anyway, so Claude fills the 'ORM' gap for me, leaving an easily understood project.

Re: How to make websites that will require lots of your time and energy

#187

Post by joks »

judge123 wrote: post #5

The problem isn't the tool or the dependency—it's the developer's temptation to over-engineer. We grab a framework because we lack the discipline to keep something simple. Is self-control in coding just a lost art now?

Sometimes it's just more fun to over-engineer things.

Re: How to make websites that will require lots of your time and energy

#188

Post by jjice »

superasn wrote: post #38

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

Prisma has shown me that anything is possible with an ORM. I think they may have changed this now, but at least within the last year, distincts were done IN MEMORY.

They had a reason, an I'm sure it had some merit, but we found this out while tracking down an OOM. On the bright side, my co worker and I got a good joke to bring up on occasion out of it.

Re: How to make websites that will require lots of your time and energy

#189

Post by lmm »

nsksl wrote: post #132
skinkestek wrote: post #115

Earlier quoted context omitted.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

> - Some homegrown “SQL helper” that saves you from writing SELECT *, but now makes it a puzzle to reconstruct a basic query in a database >- Bonus points if the half-baked data access layer is buried under layers of “magic” and is next to impossible to find. It’s really funny because you’re describing an ORM perfectly.

A bad ORM. Every application that accesses an SQL database contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of an ORM.

Re: How to make websites that will require lots of your time and energy

#190

Post by lmm »

superasn wrote: post #38

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

Weeks of handwriting SQL queries can save you hours of profiling and adding query hints.

If you want a maintainable system enforce that everything goes through the ORM. Migrations autogenerated from the ORM classes - have a check that the ORM representation and the deployed schema are in sync as part of your build. Block direct SQL access methods in your linter. Do that and maintainability is a breeze.

Post reply on HN