Dear senior developers on HN,
What are some examples of design choices that helped you reduce the effort needed to change your code according to change in requirements?
What are some of the architectural choices you made that made your codebase easier to work with?
Ask HN: What are some architectural decisions that improved your codebase?
1–10 of 78 posts
Re: Ask HN: What are some architectural decisions that improved your codebase?
#2Very basic ones:
- Strong test suite
- Delete duplication as much as possible by using any techniques such as method extraction and keeping classes and methods small.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#3Immutable 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 difficulties.
The solution we use is painfully simple: We define the JavaScript/CSS/etc as immutable (cannot edit, cannot delete) and version it. If you want to bug fix example.js then it becomes example.js 1.0.1, 1.0.2, etc. You then need to re-point to the new version. The old versions will still exist and old/outdated references will continue to function.
This also allows our cache policy to be aggressive. We don't have to worry about browsers or intermediate proxies caching our resources for "too" long. We've never found editing files in-place, regardless of cache policy, to be reliable anyway. Some browsers seemingly ignore it (Chrome!).
We always deploy the "content" repository ahead of the "code" repository. But if we needed to rollback "code," it wouldn't matter because the old versions of "content" was never deleted or altered.
There's never a situation where we'd rollback "content" because you add, you don't edit or delete. If you added a bad version/bug, just up the version number and add the fix (or reference the older version until a fix is in "content," the old version will still be there).
Re: Ask HN: What are some architectural decisions that improved your codebase?
#4I have been making my test suite emit structured data for the API tests which is used to document the API. This eliminated the margin for error in manually keeping the API documentation up to date. This improved the test coverage a lot as complete coverage is required for the documentation to be complete. It looks great too -
https://github.com/userdashboard/organizations/blob/master/a... derived from https://github.com/userdashboard/organizations/blob/master/t...
Another thing that helped was moving all my UI page tests to Puppeteer which is a NodeJS API for browsing with Chrome and tentatively Firefox web browsers. This let me automatically generate screenshots for my entire UI to publish as documentation, while simultaneously testing the responsive design under different devices which surfaced many issues.
https://userdashboard.github.io/administrators/stripe-subscr... generated by https://github.com/userdashboard/userdashboard.github.io/blo...
Re: Ask HN: What are some architectural decisions that improved your codebase?
#5Stateless 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 codebase.... dumb classes are easier to understand
Re: Ask HN: What are some architectural decisions that improved your codebase?
#6Immutable 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 calls?
This is especially bad with long-lived single page apps.
(I already use immutable static files auto generated/hashed by create react app. I rely on cloudflare to cache them forever rather than never deleting from the build though)
Re: Ask HN: What are some architectural decisions that improved your codebase?
#7Immutable 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.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#8I have been making my test suite emit structured data for the API tests which is used to document the API. This eliminated the margin for error in manually keeping the API documentation up to date. This improved the test coverage a lot as complete coverage is required for the documentation to be complete. It looks great too - https://github.com/userdashboard/organizations/blob/master/a... derived from https://github.…
Interesting idea. I wonder if this could be incorporated into some sort of test runner for testing API components. Emit a structured summary of responses that the tests generate
Re: Ask HN: What are some architectural decisions that improved your codebase?
#9One 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.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#10Immutable 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.
This is the official way to do that I think -
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...