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

71–78 of 78 posts

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

#71

Post by valand »

croo wrote: post #60
valand wrote: post #55

Keep states where they are needed. Make most things immutable. Prefer composition to extension. Treat Types as contracts. Sandbox "unsafe" codes (codes that interacts with network, file storage, etc). Eliminate side effects. Eliminate premature abstractions. Prefer explicit over implicit. Keep components functional. Prioritize semantic correctness and readability. Use events to for inter-component communication when…

I nodded along expect the last one. What do you mean by thinking protocol over data?

I meant: When creating an endpoint, a component, a feature, or a data structure, I treat them like protocol. Protocols enable other components to do more things while being robust and efficient. It must be, to certain degree, extensible and forward compatible. With that mindset, you're likely going to avoid more trouble in the future, while indirectly enforcing open-closed principle in every level.

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

#72

Post by mattmanser »

Someone1234 wrote: post #57
mattmanser wrote: post #48

Earlier quoted context omitted.

The file hash of the output file, that's what I meant by hash. Your way has big downsides and is pretty old-fashioned. It's still used by libraries that only have one javascript file, but not by websites that have to have multiple bundles and multiple CSS files. Here's webpack's advice about doing exactly what I'm advocating, it definitely works and is the industry standard: https://webpack.js.org/guides/caching/ Fir…

You're talking about something entirely differently than what I am talking about. We aren't bundling at all. We're minifying and relying on H2 for high performance concurrent delivery. Bundling is the only old-fashioned thing here. Semantic versioning is timeless. You're talking about a mechanism that is purely designed to cache-bust. I am talking about a mechanism for humans to deploy, understand, and utilize librar…

And you should still be minifying your CSS and JS, even if it's just to get out the comments, and it's still better to use file hashes than piss around with versioning.

Doesn't matter how much you dance around it, this wasn't a good architectural decision, nor is it standard industry practice.

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

#73

Post by ndreipoppa »

For an event driven app(poker game) built with React, redux and redux-saga, we deleted almost the entire project(100k lines of code) because our logic was tightly coupled with the sagas and reducers. Now we moved our logic inside the state selectors(we use reselect), the reducers are dumb, while sagas are only used to listen/dispatch async actions.

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

#74

Post by Someone1234 »

mattmanser wrote: post #72
Someone1234 wrote: post #57

Earlier quoted context omitted.

You're talking about something entirely differently than what I am talking about. We aren't bundling at all. We're minifying and relying on H2 for high performance concurrent delivery. Bundling is the only old-fashioned thing here. Semantic versioning is timeless. You're talking about a mechanism that is purely designed to cache-bust. I am talking about a mechanism for humans to deploy, understand, and utilize librar…

And you should still be minifying your CSS and JS, even if it's just to get out the comments, and it's still better to use file hashes than piss around with versioning. Doesn't matter how much you dance around it, this wasn't a good architectural decision, nor is it standard industry practice.

> And you should still be minifying your CSS and JS

We do, as the post you replied to said.

> Doesn't matter how much you dance around it, this wasn't a good architectural decision, nor is it standard industry practice.

Just because you happen to believe something doesn't make it "standard industry practice." Repeating the same unsupported claims with extra conviction doesn't make for an argument (persuasive or otherwise). Semantic versioning and versioning libraries/"grouped by version" is very much standard, in fact the industry's most popular CDN (by far) does exactly that:

https://cdnjs.com/libraries/jquery/

https://cdnjs.com/libraries/angular.js

Your "solution" solves only one issue well: cache busting. Versioned directories solve that issue but also solve other issues (deployment/human understanding/grouping associated resources together).

I'm not sure you yourself even know why you believe this. You just seem to have read WebPack's docs, decided that's how it should work, and view it as a one size fits all solution to completely unrelated problems (i.e. it isn't an architectural/organizational answer, it is a technological one for cache busting, thus irrelevant to the topic).

If you have anything of substance to add, by all means, but so far your post are strong in conviction and weak in justification (technical or organizational). You keep arguing from authority, but forgot to say who the authority is meant to be.

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

#76

Post by rramadass »

ncmncm wrote: post #70
rramadass wrote: post #68

Earlier quoted context omitted.

This is great! These are some concrete and non-trivial architectural techniques for "Systems Programming" :-) I have had opportunity to work on/with some of these techniques on Fast Network Protocol/Security Appliances and so have some familiarity with them. However some of your hints(breadcrumbs?) are not known to me and hence i have something to research and study. Thank you. PS: Can you add some more details on th…

Another hint. Speaking of breadcrumbs, if the ring buffer has fixed-size entries, a reader can come in later and start reading old entries first, say halfway back. This is helpful if you want to start a new reader and then kill an old one, and not skip any entries. It helps if the ring has power-of-two size, and the head pointer/index is 64 bits and increases monotonically. Then the high bits are easily masked off on…

Thanks for the hints. For one product that i had worked on, we had something like the above for runtime logging/debugging. A shared memory area (i.e. address range in Linux process space where shared libraries are loaded) at a fixed address was reserved via linker scripts with each process having its ring buffer at its own fixed offset. A separate reader process interacted with the CLI to provide comprehensive access to this data. It was all robust and worked quite well.

Unfortunately, these sorts of practical techniques are not known to many programmers and it would be nice if somebody (eg. you :-) were to list it on a website/book with some sample code for everybody's benefit.

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

#77

Post by srijanshetty »

pbar wrote: post #37
srijanshetty wrote: post #34

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

I completely agree, but we're constrained to two developers and won't hire anytime soon. So, monorep seems to be working great for us.
Post reply on HN