Live data from Hacker News

Ask HN: What are some architectural decisions that improved your codebase?

news.ycombinator.com

31–40 of 78 posts

Re: Ask HN: What are some architectural decisions that improved your codebase?

#31
post #12

Don’t use Kubernetes or Microservices. Solves most problems. Not even being sarcastic.

In your opinion what's wrong with Kubernetes or microservices?

Not the OP, but I'd say use only Kubernetes if you have the time to dedicate for the team to learn that technology and it's mental model.

Re: Ask HN: What are some architectural decisions that improved your codebase?

#35
post #24

Eliminate threads, queues, locks, buffer allocate & free, copying, system calls, synchronous logging, file ops, dynamic memory allocation. Replace with huge-page mapped ring buffers, independent processes, kernel-bypass set-and-forget, buffer lap checks, file-mapped self-describing binary-formatted stats, direct-mode disk block writes, caller-provided memory.

You can't just tease us like that! I demand some details on everyone of the techniques in ;-)

>Replace with huge-page mapped ring buffers, independent processes, kernel-bypass set-and-forget, buffer lap checks, file-mapped self-describing binary-formatted stats, direct-mode disk block writes, caller-provided memory

Please elaborate.

Re: Ask HN: What are some architectural decisions that improved your codebase?

#36
The biggest principles for emerging good code for me are:

Inversion of control (pass in your dependencies), keep your architecture orthogonal (make it composeable and really think if you need to inherit things rather than delegate them), code-generation of a transport api via gRPC and only focus on the business logic implementation.

Re: Ask HN: What are some architectural decisions that improved your codebase?

#37

One controversial opinion: monorep which is ideal for small teams iterating really fast. The other one was figuring out 12 factor app by serendipity as we were focussing on keeping our operations simple.

Make sure to take great care of the monorepo, and break it up _before_ it becomes impossible but necessary

Re: Ask HN: What are some architectural decisions that improved your codebase?

#38

Earlier quoted context omitted.

In your opinion what's wrong with Kubernetes or microservices?

Not the OP, but I'd say use only Kubernetes if you have the time to dedicate for the team to learn that technology and it's mental model.

From a developer point of view, one should not have a mental model in play for Kubernetes, the standard 12 factor pattern should be it. If not, the infrastructure and the app are strongly coupled

Re: Ask HN: What are some architectural decisions that improved your codebase?

#39
post #32

Eliminate “broken windows” https://en.m.wikipedia.org/wiki/Broken_windows_theory

What, were people swearing in the comments and putting Easter Eggs in the releases?

I'm assuming they mean a clean and orderly codebase invites developers to commit clean code. Its hard become motivated to make well-formed units when there are dumpster fires everywhere you look.

Re: Ask HN: What are some architectural decisions that improved your codebase?

#40

Earlier quoted context omitted.

A much easier way than this is to append a hash of the file instead of 'versioning' it. Some people add it as a query string, some add it into the filename. Been doing this for years with infinite (well, practically) cache settings. These days it's built into most js compression tools afaik.

That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides). Plus semantic versioning can help cross-team communication, there's no human understanding of r…

You don't necessary need to use a hash based on randomness. Either using the git commit as the version/hash or a hash based on the content of the file itself works.

So as long as your entrypoint and it's references are versioning, everything follows from that. So if I load version A of index.html, it also points to version A of the scripts/styles. If you load version B, you get version B of the scripts/styles, since everything is versioned the same way.

Post reply on HN