Live data from Hacker News

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

blog.jim-nielsen.com

161–170 of 247 posts

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

#161

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…

In Java, the sweet spot is JDBCTemplate. Projects based on JDBCTemplate succeed effortlessly while teams muddle through JPA projects. It is not that JPA is inherently bad, it's just that such projects lack strong technical leadership.

I believe jOOQ is Java's database "sweet spot". You still have to think and code in a SQL-ish fashion (its not trying to "hide" any complexity) but everything is typed and it's very easy to convert returned records to objects (or collections of objects).

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

#162

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.

I like Ecto's approach in Elixir. Bring SQL to the language to handle security, and then build opt-in solutions to real problems in app-land like schema structs and changesets. Underneath, everything is simple (e.g. queries are structs, remain composable), and at the driver layer it taks full advantage of the BEAM. It's hard to find similarly mature and complete solutions. In the JS/TS world, I like where Drizzle is…

Ecto is a gold-standard ORM, in no small part because it doesn't eat your database, nor your codebase. It lives right at the intersection, and does it's job well.

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

#163

Earlier quoted context omitted.

I always see this sentiment here but I just havent experienced any of it in 14 years with the Django ORM.

Hitting the database should be avoided in a web application, and use keys as much as possible. All heavy objects should be previously cached in disk.

That sounds like an awesome idea for a new, post-React web framework. Instead of simply packaging up an entire web SPA "application" and sending it to the client on first load, let's package the SPA app AND the entire database and send it all - eliminating the need for any server calls entirely. I like how you think!

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

#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 DR/BCP

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

#165
post #55

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.

A couple of years ago I had an opportunity to fill a fullstack role for the first time in several years. First thing I noticed was that I couldn't roll an SQL statement by hand even though I had a distinct memory of being able to do so in the past. I went with an ORM and eventually regretted it because it caused insurmountable performance issues. And that, to me, is the definition of a senior engineer: someone who re…

Perhaps because databases were fundamental to the first programs I ever built (in the ancient 19xx's), but damn, I cannot believe how many so-called experienced devs - often with big titles and bigger salaries - cannot write SQL. It's honestly quite shocking to me. No offense, but wow.

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

#166

Earlier quoted context omitted.

Hitting the database should be avoided in a web application, and use keys as much as possible. All heavy objects should be previously cached in disk.

That sounds like an awesome idea for a new, post-React web framework. Instead of simply packaging up an entire web SPA "application" and sending it to the client on first load, let's package the SPA app AND the entire database and send it all - eliminating the need for any server calls entirely. I like how you think!

I can unironically imagine legitimate use cases for this idea. I’d wager that many DBs could fit unnoticed into the data footprint of a modern SPA load.

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

#167
post #119

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…

I'd say, pure SQL gives you a higher performance ceiling and a lower performance and security floor. It's one of these features / design decisions that require diligence and discipline to use well. Which usually does not scale well beyond small team sizes. Personally, from the database-ops side, I know how to read quite a few ORMs by now and what queries they result in. I'd rather point out a missing annotation in so…

The best is when you use an orm in standard ways throughout your project and can drop down to raw sql for edge things and performance critical sections… mmmmm. :chefs kiss:

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

#169

Earlier quoted context omitted.

10 year old .NET is running on a Windows server that, I hope, you've done some security updates on. Having worked on most web facing stacks out there that might have been the worst one you could have picked as a "future proof" deployment, unless you're comparing them all as something you release once and then never touch again.

But did running Windows Update ever break the website?

Indeed. And did it require a Jira ticket to rearchitecture the app.

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

#170

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.

The only time I've seen migrations randomly fail was when others were manually-creating views that prevented modifications to tables. Using the migrations yourself for local dev environments is a good mitigation, except for that.
Post reply on HN