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

How boring should your team's codebases be

blog.meadsteve.dev

Post reply on HN
Print view View original

221–230 of 235 posts

Re: How boring should your team's codebases be

#221

Post by P5fRxh5kUvp2th »

Winsaucerer wrote: post #100
paulryanrogers wrote: post #93

Earlier quoted context omitted.

Well if it was only 100 lines of plain JS then how would one guard against reflection attacks? I.e. submitting HTML (like script tags) then getting that to render when others view the tainted data.

Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output). The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.

To me this is the hilarious part.

Q: "how do they use the workarounds needed to secure the more complex approaches?"

A: "those security concerns don't exist in the approach, no workaround needed. That's part of the simplicity".

It just represents a fundamental misunderstanding, but it's not their fault, they've never seen anything else. Like someone using a JWT instead of a session cookie.

Re: How boring should your team's codebases be

#222

Post by P5fRxh5kUvp2th »

skeeter2020 wrote: post #118
jiggawatts wrote: post #32

Earlier quoted context omitted.

Fantastically . The new one had "hand rolled cryptography", which should make you twitch uncontrollably if you know anything about security. The new application had, among other failings, hard-coded (unchangeable!) RSA keys used for communication channels. As in, all customers shared the same keys. I can't remember the exact specifics, but I swear at some point there was something like encrypted JSON in XML. Or was i…

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. I can't be the only one here who is both skeptical and a little turned off by someone who says "You can stick any user input into a database query and you'll be fine", with a condesending pat on my head. Your comments continue to be incredibly one-sided and biased. The summary is "My work was p…

Do you understand what SQL Injection is?

Fundamentally it's mixing data and executable code such that the DBMS cannot properly distinguish between the two and can inadvertently treat data as executable code.

Parameterize queries very explicitly tells the DBMS "this is executable code, and this over here is data". Nothing anyone puts in the data will ever be mistake as executable code by the DBMS. THIS IS SAFE.

Re: How boring should your team's codebases be

#223

Post by osigurdson »

P5fRxh5kUvp2th wrote: post #220
jiggawatts wrote: post #204

Earlier quoted context omitted.

I wasn’t clear in my description, unfortunately. This was a multi-tenant centrally hosted application. There were 2000 sites served, each with kiosk PCs and some associated special-purpose hardware. The actual application code ran in just four virtual machines in two data centres. No templates, no Terraform, no microservices, etc… Just vanilla ASP.NET on IIS with SQL Server as the back end. The efficiency stemmed fro…

Both approaches are valid for multi-tenancy, with their own pros and cons.

Of course, it is hard to say without knowing more about it, but it seems that jiggawatts solution is closer to optimal than the second one. The 50GB database could fit on a USB drive after all and we know empirically that a single SQL server database was able to handle the requests since the old system worked.

Also, the fact that a consulting company was able to turn a part time gig for one person into a $100M+ project at the taxpayer's expense is very frustrating.

Re: How boring should your team's codebases be

#224

Post by kaashif »

baby wrote: post #197
gavinray wrote: post #162

Earlier quoted context omitted.

> A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. This. I don't want to work with niche languages anymore, and artisan…

I agree, but would use Rust instead of Java. Imo Java is a horrendous language that’s basically legacy at this point.

To be fair, they didn't say Java, they said JVM. That allows Kotlin, Scala, whatever.

Java is missing so much and has so many design errors (which are acknowledged as errors), I agree that it should be avoided.

I think Rust is a better language, but you can't exactly incrementally convert your Java codebase into Rust very easily. If you stay in the JVM, things like that are much easier.

Re: How boring should your team's codebases be

#225

Post by berkes »

rTX5CMRXIfFG wrote: post #88
berkes wrote: post #69

Earlier quoted context omitted.

...and whether it will continue to do so. Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.

Yes, but whether it will continue to do so, once again, has little if nothing to do with the tech stack. I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions. And, when you’re lookin…

Boring isn't old, nessecarily. Not-boring isn't nessecarily novel either.

Design Patterns are from at least 1994, when GoF wrote them down. Ideas like DDD are some 20 years old. As is e.g. Event Sourcing.

Actually, by your reasoning, Event Sourcing would be the preferred architecture for everything since the oldest written human sources were event sourced (bookkeeping grain).

As always, what is best fitting "depends". Battle tested is one, but never the only one, parameter to decide with.

Re: How boring should your team's codebases be

#226

Post by eurasiantiger »

P5fRxh5kUvp2th wrote: post #221
Winsaucerer wrote: post #100

Earlier quoted context omitted.

Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output). The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.

To me this is the hilarious part. Q: "how do they use the workarounds needed to secure the more complex approaches?" A: "those security concerns don't exist in the approach, no workaround needed. That's part of the simplicity". It just represents a fundamental misunderstanding, but it's not their fault, they've never seen anything else. Like someone using a JWT instead of a session cookie.

>Like someone using a JWT instead of a session cookie

Those aren’t mutually exclusive, you know.

Re: How boring should your team's codebases be

#227

Post by eurasiantiger »

P5fRxh5kUvp2th wrote: post #222
skeeter2020 wrote: post #118

Earlier quoted context omitted.

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. I can't be the only one here who is both skeptical and a little turned off by someone who says "You can stick any user input into a database query and you'll be fine", with a condesending pat on my head. Your comments continue to be incredibly one-sided and biased. The summary is "My work was p…

Do you understand what SQL Injection is? Fundamentally it's mixing data and executable code such that the DBMS cannot properly distinguish between the two and can inadvertently treat data as executable code. Parameterize queries very explicitly tells the DBMS "this is executable code, and this over here is data". Nothing anyone puts in the data will ever be mistake as executable code by the DBMS. THIS IS SAFE.

It is only safe for the SQL server. An injection attack could still be targeting a cache (to poison it with e.g. a malicious script), the browser (to steal data via XSS/CSRF) or the user (show an error message telling them to contact malicious number).

Re: How boring should your team's codebases be

#228

Post by P5fRxh5kUvp2th »

osigurdson wrote: post #223
P5fRxh5kUvp2th wrote: post #220

Earlier quoted context omitted.

Both approaches are valid for multi-tenancy, with their own pros and cons.

Of course, it is hard to say without knowing more about it, but it seems that jiggawatts solution is closer to optimal than the second one. The 50GB database could fit on a USB drive after all and we know empirically that a single SQL server database was able to handle the requests since the old system worked. Also, the fact that a consulting company was able to turn a part time gig for one person into a $100M+ proje…

typical technical forum, thinking they know the best solution based upon a 1 paragraph description.

Re: How boring should your team's codebases be

#229

Post by P5fRxh5kUvp2th »

eurasiantiger wrote: post #227
P5fRxh5kUvp2th wrote: post #222

Earlier quoted context omitted.

Do you understand what SQL Injection is? Fundamentally it's mixing data and executable code such that the DBMS cannot properly distinguish between the two and can inadvertently treat data as executable code. Parameterize queries very explicitly tells the DBMS "this is executable code, and this over here is data". Nothing anyone puts in the data will ever be mistake as executable code by the DBMS. THIS IS SAFE.

It is only safe for the SQL server. An injection attack could still be targeting a cache (to poison it with e.g. a malicious script), the browser (to steal data via XSS/CSRF) or the user (show an error message telling them to contact malicious number).

What the person said

> "You can stick any user input into a database query and you'll be fine"

Besides which, pretend SQL Server is a glorified cache, the result is the same.

Re: How boring should your team's codebases be

#230

Post by hedora »

osigurdson wrote: post #196
hedora wrote: post #171

Earlier quoted context omitted.

Option one: Write a cloud formation / terraform template that involves O(1) machines and deploy 2000 identical copies. Option two: Write a template that deploys O(N = 2000) interdependent services across roughly 3-10x as many machines, and deploy one copy. From what I can tell, you are arguing for option 2. It is strictly worse than option one. In addition to being more complex, it has a few nines less reliability, a…

I'd argue for Option 3, which is to try to understand the workloads placed on the original system and then design the new system based on this. I think having 2K independent database servers would not normally be optimal for 2M users, but it is possible.

If the old system is exceeding uptime SLAs, meeting all business needs, and coming in under the budget for such an investigation (it sounds like the total operations budget was less than 10% of one engineer's time), then why bother?
Post reply on HN