What the hell have you built • Hacker News Board

Re: What the hell have you built

#211

Post by sachahjkl » Thu, Nov 06, 2025, 2:37 PM UTC

Bengalilol wrote: post #89

kiesel wrote: post #51

I love the fact that the author "wrote" this page with massive CSS framework (tailwind) and some sort of Javascript framework, with a bundler and obfuscator - instead of a plain, simple HTML page. Well played! :-)

React + Tailwind + bundler + googlefont + ... Yeah, humans are paradoxical

good point, got rid of google font. for the rest, it's just that the DX is unmatched to get something quick and dirty started up. (I _could_ have done a simple .html though). and I'll concede that react is overkill for this, I just wanted components + typescript to not waste time on silly vanilla js bugs

Re: What the hell have you built

#212

Post by lelanthran » Thu, Nov 06, 2025, 2:51 PM UTC

9dev wrote: post #81

It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server. If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the appli…

> If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the application.

That's fine, 6 of them are test accounts :-)

> It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues

If you have an entire organisation dedicated to 6 users, those users had better be ultra profitable.

> If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the application

Can be done simply by a sole company owner; no need for tools that make sense in an organisation (K8s, etc)

> You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing.

A deployment script that includes test runners is fine for focused product. You can even do it using a green/blue strategy if you can afford the extra $5-$10/m for an extra VPS.

> You want proper secret management, so the database credentials aren't just accessible to everyone.

Sure, but you don't need to deploy a full-on secrets-manager product for this.

> You want a caching layer, so you're not surprised by a rogue SQL query that takes way too long, or a surge of users that exhaust the database connections because you never bothered to add proper pooling.

Meh. The caching layer is not to protect you against rogue SQL queries taking too long; that's not what a cache is for, after all. As for proper pooling, what's wrong with using the pool that came with your tech stack? Do you really need to spend time setting up a different product for pooling?

> dding guardrails to protect your team from itself mandates some complexity, but just hand-waving that away as unnecessary is a bad answer.

I agree with that; the key is knowing when those things are needed, and TBH unless you're doing a B2C product, or have an extremely large B2B client, those things are unnecessary.

Whatever happened to "profile, then optimise"?

Re: What the hell have you built

#213

Post by tempodox » Thu, Nov 06, 2025, 2:52 PM UTC

moritzwarhier wrote: post #25

marfmarkus wrote: post #17

Earlier quoted context omitted.

It's the natural evolution to becoming a fun addict. Unless you actively push yourself to do the uncomfortable work every day, you will always slowly deteriorate and you will run into huge issues in the future that could've been avoided. And that doesn't just apply to software.

I see your point. But accidental complexity is the most uncomfortable work there is to me. Do programmers really find so much fun in creating accidental complexity? Removing it, no matter whether I created it myself, sure, that can be a hard problem. I've certainly been guilty creating accidental complexity as a form of procrastrination I guess. But building a microservices architecture is not one of these cases. FWI…

> Do programmers really find so much fun in creating accidental complexity?

I believe only bad (inexperienced) programmers do.

Re: What the hell have you built

#214

Post by pjmlp » Thu, Nov 06, 2025, 2:55 PM UTC

9dev wrote: post #207

pjmlp wrote: post #187

Earlier quoted context omitted.

Well, load balancers are an option.

They are: But now you've expanded the definition of "a single monolith with postgres" to multiple replicas that need to be updated in sync, you've suddenly got shared state across multiple, fully isolated processes (in the best case) or running on multiple nodes (in the worst case), and a myriad of other subtle gotchas you need to account for, which raises the overall complexity considerably.

Postgres.

Re: What the hell have you built

#215

Post by stereolambda » Thu, Nov 06, 2025, 3:11 PM UTC

redshiftza wrote: post #119

Is this targeted at startup bros with an MVP and a dream ? In almost any other scenario I feel the author is being intentionally obtuse about much of the reality surrounding technology decisions. An engineer operating a linux box running postgres & redis (or working in an environment with this approach) would become increasingly irrelevant & would certainly earn far less than the engineer operating the other. An engi…

While you you're making good points, this shows that engineers and industry intentionally make work more complex than necessary in order to justify higher prices for labor. This is not so uncommon in today's economy, especially white collar and regulated work that most people don't understand, but worth thinking about regardless.

To be fair, it's hard to imagine economy and civilization crashing hard enough to force us to be more efficient. But who knows.

Re: What the hell have you built

#216

Post by anarazel » Thu, Nov 06, 2025, 3:32 PM UTC

1313ed01 wrote: post #202

fouc wrote: post #86

Funny, from the title I was expecting a productivity-adjacent "What have you even built?" article. Except it's really a "What over-engineered monstrosity have you built?" in the theme of "choose boring technology" p.s. MariaDB (MySQL fork) is technically older and more boring than PostgreSQL so they're both equally valid choices. Best choice is ultimately whatever you're most familiar with.

MariaDB from 2009, based on MySQL from 1995. PostgreSQL from 1996, based on Postgres95 from 1995, based on POSTGRES from 1989, based on INGRES from 1974(?). I wonder if any lines of 1970's or at least 1980's code still survive in some corner of the PostgeSQL code base or if everything has been rewritten at least once by now? Must have started out in K&R C, if it was even C?

We don't have the complete version history of postgres, so that's not easy to know. There definitely are still lines from Postgres95 that haven't been changed since the initial import into our repository.

Somewhere there's a CVS repository with some history from before the import into the current repository, but unfortunately there's a few years missing between that repository and the initial import. I've not done the work to analyze whether any lines from that historical repo still survive.

Re: What the hell have you built

#217

Post by benterix » Thu, Nov 06, 2025, 4:03 PM UTC

embedding-shape wrote: post #159

benterix wrote: post #154

Earlier quoted context omitted.

With time, I discovered something interesting: for us, techies, using container orchestration is about reliability, zero-downtime deployments, limiting blast radius etc. But for management, it's completely different. It's all about managing complexity on an organizational level. It's so much easier to think in terms "Team 1 is in charge of microservice A". And I know from experience that it works decently enough, at…

> using container orchestration is about reliability, zero-downtime deployments I think that's the first time I've heard any "techie" say we use containers because of reliability or zero-downtime deployments, those feel like they have nothing to do with each other, and we've been building reliable server-side software with zero-downtime deployments long before containers became the "go-to", and if anything it was eas…

It would be interesting to hear your story, mine is that containers in general start an order of magnitude faster than vms (in general! we can easily find edge cases) and hence e.g. horizontal scaling is faster. You say it was easier before containers, I say k8s in spite of its complexity is a huge blessing as teams can upgrade their own parts independently and do things like canary releases easily with automated rollbacks etc. It's so much faster than VMs or bare metal (which I still use a lot and don't plan to abandon anytime soon but I understand their limitations).

Re: What the hell have you built

#218

Post by spoiler » Thu, Nov 06, 2025, 4:57 PM UTC

9dev wrote: post #191

spoiler wrote: post #149

Earlier quoted context omitted.

U agree it adds a bit of complexity, but all code adds complexity. Maybe interacted with CIs too much and it's Stockholm syndrome, but they are there to help tame and offload complexity, not just complexity for complexity'a sake

> they are there to help tame and offload complexity, not just complexity for complexity'a sake Theoretically. Practically, you're hunting for the reason why your GitHub token doesn't allow you to install a private package from another repository in your org during the build, then you learn you need a classic personal access token tied to an individual user account to interact with GitHub's own package registry, you…

Uh, I've used the package repository with GitHub, and I don't remember having to do this! So, I'm not entirely sure what's happening here. I think this might be accidental complexity because there's probably a misconfiguration somewhere...

But on that point I agree, initial set-up can be extremely dauntin due to the amoun of different technologies that interact, and requires a level of familiarity that most people don't want to have with these tools. which is understandable; they're a means to an end and Devs don't really enjoys playing with them (DevOps do tho!). I've had to wear many hats in my career, and was the unofficial dedicated DevOps guy in a few teams, so for better or worse had to grow familiar with them.

Often (not always) there's an easier way out, but spotting it through the bushes of documentation and overgrown configuration can be annoying.

Re: What the hell have you built

#219

Post by vbezhenar » Thu, Nov 06, 2025, 4:59 PM UTC

sevensor wrote: post #201

vbezhenar wrote: post #176

Earlier quoted context omitted.

The problem is, that library usually does not provide good enough boundaries. C library can just shit over your process memory. Java library can cause all the hell over your objects with reflection, can just call System.exit(LOL). Minimal boundary to keep demons at bay is process boundary and you need some way for processes to talk to each other. If you're separating components into processes, it's very natural to pu…

> it's very natural to put them to different machines, so you need your IPC to be network calls But why is this natural? I’m not saying we shouldn’t have network RPC, but it’s not obvious to me that we should have only network RPC when there are cheap local IPC mechanisms.

Because horizontal scaling is the best scaling method. Moving services to different machines is the easiest way to scale. Of course you can keep them in the same machine until you actually need to scale (may be forever), but it makes sense to make some architectural decisions early, which would not prevent scaling in the future, if the need arises.

Premature optimisation is the root of all evil. But premature pessimisation is not a good thing either. You should keep options open, unless you have a good reason not to do so.

If your IPC involves moving gigabytes of transient data between components, may be it's a good thing to use shared memory. But usually that's not required.

Re: What the hell have you built

#220

Post by isodev » Thu, Nov 06, 2025, 5:46 PM UTC

zelphirkalt wrote: post #190

isodev wrote: post #185

Earlier quoted context omitted.

My comment is that this is a choice that should be made for each project depending on what you’re building - does your model require features not supported by SQLite or Postgres etc. > Unless you have a really really simple model and app And this is the wrong conclusion. I have a really really complex model that works just fine with SQlite. So it’s not about how complex the model is, it’s about what you need. In the…

OK, well, you don't always know all requirements ahead of time. When I do find out about them later on, I don't want to have to switch database backend then. For example initially I thought I would avoid those many to many relationships all together ... But turned out to be the most fitting way to do what I needed to do in Django. I guess you could say "use sqlite as long as it lends itself well to what you are doing…

You're right, and it's ok to lean on experience to anticipate certain constraints for a project. My point really is that is just not an absolute default and it should not be included as a "general guideline" or recommendation in documentation, tutorial and blogposts. There is also a substantial difference between SMEs and bigger corporate situations where architecture changes are practically religious.

Changing the database can create friction, but at that moment you can also ask yourself: What is the cost of adding/learning this giant stateful component with maintenance needs (postgres) vs. say adapting our schema to be more compatible with what we have? (e.g. the lightweight and much cheaper sqlite, but the argument works for whatever you already have).

I'd much rather see folks thinking about that. Same for caching and CDNs and whatever Cloudflare is selling this week to hook people on their platform (e.g. DDoS/API gateway protections come in many variants, we're not all 1password and sometimes it's ok to just turn on the firewall from your hosting provider).