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

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

31–40 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#31

Post by Denvercoder9 »

sallveburrpi wrote: post #26
giancarlostoro wrote: post #16

Earlier quoted context omitted.

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and…

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

Re: Everything as code: How we manage our company in one monorepo

#32

Post by david422 »

supermdguy wrote: post #24

How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.

I do it naively. Maintain the backend and frontend separately. Roll out each change in a backwards compatible manner.

Re: Everything as code: How we manage our company in one monorepo

#33

Post by Faaak »

sallveburrpi wrote: post #26
giancarlostoro wrote: post #16

Earlier quoted context omitted.

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and…

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

What about separate, atomic, commits? Are they squashed too? Makes reverting a fix harder without impacting the rest, no?

Re: Everything as code: How we manage our company in one monorepo

#34

Post by mjr00 »

sethammons wrote: post #17

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…

100%, this is all true and something you have to tackle eventually. Companies like this one (Kasava) can get away with it because, well, they likely don't have very many customers and it doesn't really matter. But when you're operating at a scale where you have international customers relying on your SaaS product 24/7, suddenly deploys having a few minutes of downtime matters.

This isn't to say monorepo is bad, though, but they're clearly naive about some things;

> No sync issues. No "wait, which repo has the current pricing?" No deploy coordination across three teams. Just one change, everywhere, instantly.

It's literally impossible to deploy "one change" simultaneously, even with the simplest n-tier architecture. As you mention, a DB schema is a great example. You physically cannot change a database schema and application code at the exact same time. You either have to ensure backwards compatibility or accept that there will be an outage while old application code runs against a new database, or vice-versa. And the latter works exactly up until an incident where your automated DB migration fails due to unexpected data in production, breaking the deployed code and causing a panic as on-call engineers try to determine whether to fix the migration or roll back the application code to fix the site.

To be a lot more cynical; this is clearly an AI-generated blog post by a fly-by-night OpenAI-wrapper company and I suspect they have few paying customers, if any, and they probably won't exist in 12 months. And when you have few paying customers, any engineering paradigm works, because it simply does not matter.

Re: Everything as code: How we manage our company in one monorepo

#35

Post by wrs »

This is sort of a whole product, but it’s hardly managing the whole company. Financials? HR? Contracts? Pictures of the last team meeting?

It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.

Re: Everything as code: How we manage our company in one monorepo

#36

Post by [deleted] »

sethammons wrote: post #17

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…

[deleted]

Re: Everything as code: How we manage our company in one monorepo

#37

Post by doublet00th »

I built something like this at my previous startup, Pangea [1]. Overall I think looking back on our journey I'd sign up for it again, but it's not a panacea.

Here were the downsides we ran into

- Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> merge MR -> have CI update feature flag in our envs), and optimizing that took quite a while. It then made branch invariants harder to reason about (everything in the production branch is what is in our live environments, but except for feature flags). So, we moved that out of the monorepo into an actual service.

- CI time and complexity. When we started getting to around 20 services that deployed independently, GitLab started choking on the size of our CI configuration and we'd see a spinner for about 5 minutes before our pipeline even launched. Couple that with special snowflakes like the feature flag system I mentioned above, eventually it got to the point that only a few people knew exactly how rollouts edge cases worked. The juice was not worth the squeeze at that point (the juice being - "the repo is the source of truth for everything")

- Test times. We ran some e2e UI tests with Cypress that required a lot of beefy instances, and for safety we'd run them every single time. Couple that with flakiness, and you'd have a lot of red pipelines when the goal was 100% green all the time.

That being said, we got a ton of good stuff out of it too. I distinctly remember one day that I updated all but 2 of our services to run on ARM without involving service authors and our compute spend went down by 70% for that month because nobody was using the m8g spot instances, which had just been released.

[1]: https://pangea.cloud/

Re: Everything as code: How we manage our company in one monorepo

#38

Post by codegeek »

I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?

Re: Everything as code: How we manage our company in one monorepo

#39

Post by codingdave »

> When you ask Claude to "update the pricing page to reflect the new limits," it can...

wat. You are running the marketing page from the same repo, yet having an LLM make the updates? You have the data file available. Just read the pricing info from your config file and display it?

Re: Everything as code: How we manage our company in one monorepo

#40

Post by NERD_ALERT »

codegeek wrote: post #38

I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?

Hosting a developer environment remotely that you SSH into is very common. That’s how you would approach working with a monorepo that has any serious size to it.
Post reply on HN