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

Monorepo Support

render.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Monorepo Support

#21

Post by detaro »

tiltrus wrote: post #20
samwillis wrote: post #8

Earlier quoted context omitted.

I disagree, any post about Heroku or any of the startups aiming to replace it (Fly or Railway for example) always mention it. From the perspective of someone looking to move to one of them from Heroku: - Render is closest to what Heroku do, however being on their own hardware they can undercut Heroku who, by running on top of AWS, are both limited but apparently also don’t want to compete on price. - Fly is both aimi…

Render.com has been a lot more stable for me than Fly.io. After 3-4 months of running into issues running on Fly.io, I went with Render.com and have had no issues so far. I think Fly.io employees are a lot more active on HN which is why you see them mentioned more often. They also write great blog posts which get a lot of attention here. I also agree with the sibling comment. I came to Fly.io being sold on servers ru…

Curious what kind of issues you've seen with fly.io? (Most reports about them I've seen seem to be based on people trying it out relatively briefly, where they might miss things that crop up over a longer time)

Re: Monorepo Support

#22

Post by echelon »

hk1337 wrote: post #19
echelon wrote: post #17

Earlier quoted context omitted.

Exactly! Frontend, backend, or desktop monorepo structure for Java, Rust, Typescript, etc: /src /lib /mysql-common /redis-common /... /services /app-1 /app-2 /... You can use other directories to group assets, database migrations, documentation - whatever. The core build, test, CI, etc. tools can live in the root. The ability to share common code and not have to worry about packaging internal libraries, versioning th…

And if an app/package did grow to the point it needed its own repository, all the packages depending on it just need to update their dependency configuration to the new source.

The most typical case of this happening I've seen is an ancient unsupported legacy app. You still need to deploy it, but you only build it every few months or so. You rarely touch the thing, and its dependencies are pinned to old versions. The lack of support tends to drag down the rest of the monorepo, so it'll sometimes get "kicked out" as a bad citizen.

Really only reserved for the worst cases.

Re: Monorepo Support

#23

Post by bckr »

camgunz wrote: post #15
corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

Because in larger monorepos, by definition most of the stuff in there is irrelevant to most people. So you're waiting for checkouts to finish because of a bunch of irrelevant stuff. You're waiting for tests to finish because of a bunch of irrelevant stuff. You're waiting for requirements to update because of a bunch of irrelevant stuff. You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant…

What's NIH?

Re: Monorepo Support

#24

Post by simlevesque »

bckr wrote: post #23
camgunz wrote: post #15

Earlier quoted context omitted.

Because in larger monorepos, by definition most of the stuff in there is irrelevant to most people. So you're waiting for checkouts to finish because of a bunch of irrelevant stuff. You're waiting for tests to finish because of a bunch of irrelevant stuff. You're waiting for requirements to update because of a bunch of irrelevant stuff. You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant…

What's NIH?

Not invented here.

Re: Monorepo Support

#25

Post by unity1001 »

camgunz wrote: post #15
corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

Because in larger monorepos, by definition most of the stuff in there is irrelevant to most people. So you're waiting for checkouts to finish because of a bunch of irrelevant stuff. You're waiting for tests to finish because of a bunch of irrelevant stuff. You're waiting for requirements to update because of a bunch of irrelevant stuff. You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant…

> code duplication

That makes it very easy to roll out changes to any given service without breaking others and helps a lot with the backwards compatibility of services. Makes everything more resilient.

Shared code is always an internal dependency. You think 'We are sharing code and this is efficient'. But you end up having to take into account many different parts of the application when rolling out one change for you can easily break something totally out of sight while trying to change another.

I were mostly against duplication of code. But the more I develop and maintain larger systems, the better I see the value of separating codebases, even if this includes code duplication.

Re: Monorepo Support

#26

Post by gregmac »

corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

> You can still deploy to separate targets, a code repository is not 1:1 with a deploy target, that is a fake constraint that never even existed.

I've found repository:deployment is a very useful way of organizing code. I work on a mix of cloud and on-prem apps, and maybe I'm biased from my personal preferences and experience but I see most of the deployment/release problems, confusing merge conflicts and build pain comes from products/repositories where this isn't the case.

I'm not quite sure what you mean by "targets" though, so I'll explain what I mean when I say "deployment", in the context of the mix of stuff I work on: the entire repository is released (and/or deployed) in a monolithic way.

This can be a microservice, an executable or installer (on-prem), a package (consumed by other repositories), or even a big monolithic service (eg, multiple web apps + proxy servers + terraform templates).

My reasoning behind this is that a deployment has to be standalone.

For example a microservice should be able to be deployed independently at any time without breaking anything that consumes it -- meaning you always have to ensure backwards compatibility. If you can't (or don't) do that -- which means you have to do coordinated deploys and deploy several things at the same instant -- you actually don't have microservices; you really have a monolithic architecture with all the complications/overhead of managing a microservice.

I think when you combine multiple microservices into one repository, it's too easy to break this backwards compatibility contract because from the source code point of view, those mixed versions never exist. My experience is that lots of developers seem to struggle with this conceptually and argue about it being unnecessary when it's raised during a PR.

If you don't want to support backwards compatibility between your "microservices" that's totally fine too: but IMHO you aren't doing microservices, and you shouldn't even design the ability to deploy them independently. When you do coordinated deploys and one fails, the rollback process is awful and you can have extended downtime. Instead it makes sense to have a monolithic deployment process (eg: single terraform file) that deploys them all together, and the easiest way to manage this is to have them in a single repository.

There's another challenge with on-prem software. Having a branch or tag for "Foo v1.1" that also contains the source for "Bar" that is at an unfinished state somewhere between v3.4 and v3.5, and likewise a "Bar v3.5" that contains the source for "Foo v-not-quite-1.2" is just nonsensical. Depending on the branching strategy and types of changes happening it also leads to the team that works on "Foo" fixing merge conflicts they don't understand from changes in "Bar", which are really easy to get wrong. So once again: If they're released independently, they should have their own repositories.

Re: Monorepo Support

#27

Post by robust-cactus »

corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

I agree with this take. The companies I've worked at that have had multi-repos basically just obfuscated related pieces of code - ultimately leading to lots of bugs.

The fact that I can grep across services is a godsend.

I think we should all actively be fighting against Conway's law: "your code resembles your org structure". Multi-repos are usually a thin facade that basically end up supporting this and makes it harder to dev in and make the architecture typically worse.

https://en.m.wikipedia.org/wiki/Conway%27s_law

Re: Monorepo Support

#28

Post by vlunkr »

gedy wrote: post #11
corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

> I don't get the case against monorepos, and why it's so polarizing. Because bad monorepos ala monolithic apps tend toward no separation of concerns, and with a large enough team everyone is stepping on each other's toes in conflicts, tests, etc. Some tech like Rails makes this even harder to enforce boundaries. I get that a good team can manage a monorepo that's not one big ball of code, and a bad one wouldn't nece…

Seems like you’re conflating monolith and monorepo.

Re: Monorepo Support

#29

Post by frenchman99 »

camgunz wrote: post #15
corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

Because in larger monorepos, by definition most of the stuff in there is irrelevant to most people. So you're waiting for checkouts to finish because of a bunch of irrelevant stuff. You're waiting for tests to finish because of a bunch of irrelevant stuff. You're waiting for requirements to update because of a bunch of irrelevant stuff. You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant…

> You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant stuff.

You could setup your CI to only recompile what's changed, so you wouldn't be waiting for anything else than what you've changed. This usually requires a bit of work upfront, but once you've done it for 1 part of the codebase it is easy and low-maintenance to replicate to the entire codebase. With Gitlab CI (and others), you can import bits of yaml configuration here and there to avoid code duplication for such use cases.

> I'm personally against microservices

In some cases, you need microservices or at least being able to run only a single part of the monolith through configuration. For instance if you want to host parts of the codebase in a separate virtual machine for security or scalability.

I don't think the choice is a matter of opinion but a matter of technical/business requirements.

Re: Monorepo Support

#30

Post by azemetre »

camgunz wrote: post #15
corytheboyd wrote: post #6

I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…

Because in larger monorepos, by definition most of the stuff in there is irrelevant to most people. So you're waiting for checkouts to finish because of a bunch of irrelevant stuff. You're waiting for tests to finish because of a bunch of irrelevant stuff. You're waiting for requirements to update because of a bunch of irrelevant stuff. You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant…

There’s also project repos where all the code pertaining to a project is under one repo. I think this setup is the best of both worlds.

If you’re a team that has a client, several micro services, DB, etc it’s way better to have that under a single repo than spread to multiple. Monorepos don’t have to be gigantic monstrosities, they can encapsulated products.

Post reply on HN