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

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 78 posts

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

#21

Post by gitgud »

rumanator wrote: post #16
gitgud wrote: post #5

Stateless components, or as I like to call them dumb components . We found it much easier to reason about logic in the code base with having many small dumb components, which didn't have any state or complex functionality. These would be controlled by a few smart parent components to coordinate them. The result was a lot cleaner. We implemented this on a Web client, but I think the concept would work well in any code…

> Stateless components, or as I like to call them dumb components. You mean like pure functions? https://en.m.wikipedia.org/wiki/Pure_function

Yes similar, I'm talking about reactive UI components though (used in React, Vue, Angular etc.). They're a class that might have many functions. In this case all the component's functions would be pure functions though.

Perhaps a better term could be pure components maybe?

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

#22

Post by gitgud »

Someone1234 wrote: post #3

Immutable JavaScript/CSS/Blobs/etc. We have a very typical [web] codebase, server-side code (e.g. business rules, database access, etc), server-side Html generation, and JavaScript/CSS/Images/Fonts/etc stored elsewhere. Two repositories (content and code). So the obvious question is: How do you manage deployment? Two repositories means two deployments, which means potential timing problems/issues/rollback difficultie…

That's a great solution, and I think that's what a lot of webpack build systems do.

In Angular, if a src file changes, then the corresponding build file hash changes. They call it cache-busting as it breaks the cache.

What kind of web stack are you running?

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

#23

Post by gitgud »

tnolet wrote: post #12

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

Microservices... Instead of 1 server you have N servers to maintain and scale....

"premature optimization is the root of all evil" - Donald Knuth

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

#24

Post by ncmncm »

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.

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

#25

Post by Someone1234 »

zawerf wrote: post #6
Someone1234 wrote: post #3

Immutable JavaScript/CSS/Blobs/etc. We have a very typical [web] codebase, server-side code (e.g. business rules, database access, etc), server-side Html generation, and JavaScript/CSS/Images/Fonts/etc stored elsewhere. Two repositories (content and code). So the obvious question is: How do you manage deployment? Two repositories means two deployments, which means potential timing problems/issues/rollback difficultie…

I have recently been struggling with versioning(and learning devops in general) myself so I would love to hear more on this topic. For example if you rollback a deployment (or if you just have browsers who haven't refreshed yet), how do you make sure browser clients are talking to the right api backend version? How do you force them to upgrade or rollback? Will they even be routed to the same api server on multiple c…

> how do you make sure browser clients are talking to the right api backend version?

We version the URL itself.

> How do you force them to upgrade or rollback?

We don't use it often but we can embed an "obsolete" tag into the HTTP/AJAX response header which a global AJAX hook (jQuery) will read and bring up a prompt/force a page reload. We use it infrequently but it was added for just such an occasion.

It is a bad user experience but it is a useful tool.

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

#26

Post by cbanek »

Simplify, simplify, simplify. Don't make tomorrow's problem today's complexity.

Get rid of any configuration options that no one uses. These things get passed around in flags sometimes to deep levels and can make logic complicated. Don't add a configuration option until you are sitting at someone's desk and see they need it and why. Only add the bare minimum. Same for APIs, buttons, and features.

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

#27

Post by Someone1234 »

gitgud wrote: post #22
Someone1234 wrote: post #3

Immutable JavaScript/CSS/Blobs/etc. We have a very typical [web] codebase, server-side code (e.g. business rules, database access, etc), server-side Html generation, and JavaScript/CSS/Images/Fonts/etc stored elsewhere. Two repositories (content and code). So the obvious question is: How do you manage deployment? Two repositories means two deployments, which means potential timing problems/issues/rollback difficultie…

That's a great solution, and I think that's what a lot of webpack build systems do. In Angular, if a src file changes, then the corresponding build file hash changes. They call it cache-busting as it breaks the cache. What kind of web stack are you running?

We have Java and .Net Core (trying as a replacement) internet facing and Node.js for internal APIs. All on Linux. Some of this is due to organizational reasons, not technical.

As for the "content" side, it is pretty stereotypical: Sass, TypeScript, AngularJS 1.xx (not a typo!), and too many npm dependencies. But there's too much NIH[0] between teams, which is why our structure is so important in other ways.

[0] https://en.wikipedia.org/wiki/Not_invented_here

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

#28

Post by Someone1234 »

mattmanser wrote: post #7
Someone1234 wrote: post #3

Immutable JavaScript/CSS/Blobs/etc. We have a very typical [web] codebase, server-side code (e.g. business rules, database access, etc), server-side Html generation, and JavaScript/CSS/Images/Fonts/etc stored elsewhere. Two repositories (content and code). So the obvious question is: How do you manage deployment? Two repositories means two deployments, which means potential timing problems/issues/rollback difficultie…

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 raw hashes.

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

#29

Post by cbanek »

caseymarquis wrote: post #13
tnolet wrote: post #9

One of the things in the Clean Code book really helps. Methods and functions should be around 5 lines. Doesn’t always work but is great to aim for.

Is there an article on this? I feel like I must be missing some context, as 5 lines seems short enough to be counter productive.

I think 5 lines is pretty short but good. At the very longest, I like a function to fit on one screen of text so I don't have to scroll to see the entire function.
Post reply on HN