Monorepo Support • Hacker News Board

Re: Monorepo Support

#11

Post by gedy » Sat, Sep 17, 2022, 3:56 PM UTC

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 necessarily be better with microsystems either.

But it's super frustrating to hear teams blobbing everything together with no layering or separation and defending it as "but we're a monorepo"

Re: Monorepo Support

#12

Post by jayd16 » Sat, Sep 17, 2022, 3:58 PM UTC

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…

Monorepo comes with its own set of challenges. Git doesn't scale all that well but is the most popular and supported VCS.

Assuming you get as far as actually having code in one repo, the advantages of monorepo do not come for free. You either use a consolidated build system or you're still linking code using packages. A mono-build is no small task especially if your org is of any sort of complexity.

You'll almost certainly never get away from packages entirely unless you want to pull in the source code of all your dependencies. Not only are you merging it in but you're integrating it into your mono-build system. Doesn't sound feasible or enjoyable to me.

Some people consider mono-repo a fools errand. At most places you can take the pragmatic approach of consolidating repos where it makes sense while keeping the decoupling advantages of packages where it makes sense. They both have trade offs.

Re: Monorepo Support

#13

Post by jayp » Sat, Sep 17, 2022, 4:10 PM UTC

samwillis wrote: post #8

paulgb wrote: post #5

Render is one of those companies you don't see a lot on HN, but you talk to developers who use it and they have a lot of love for it. Stuff just works like you'd expect it to. We've been a happy user of monorepo support since it was in beta and it's worked great for us.

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…

If you are going to use a centralize database coupled with edge compute, you may end up with far worse end-to-end latencies if your computedb does multiple roundtrips per request (which is fairly common in practice). In most cases, you need compute and db to be colocated.

I am skeptical of edge compute being generalizable. I do forsee a bright future for it for embarrassingly parallel problem space, where data sharding can be done cleanly based on an end user.

Re: Monorepo Support

#14

Post by porridgepie » Sat, Sep 17, 2022, 4:16 PM UTC

Tried it for a couple of years, and as many already said, its more that its different than that its a lot better or worse than the altrrnative.

Re: Monorepo Support

#15

Post by camgunz » Sat, Sep 17, 2022, 4:35 PM UTC

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 stuff.

Sure, tooling and configuration can mitigate a lot of that stuff, but most tools don't countenance codebases that are so large that most of the stuff in them is irrelevant to everyone. The natural thing to do is to split it up.

I'm personally against microservices; I think they go way too far the other way and tend to encourage some of the worst software development practices (NIH, code duplication, super weird architecture and viral explosion of dependency injection everywhere), but "we have one repo for everything" is also pretty weird. I mean, the most famous monorepos (Linux, OpenBSD, Google) literally invented tools to deal with them. That should say something.

Re: Monorepo Support

#16

Post by hk1337 » Sat, Sep 17, 2022, 4:48 PM UTC

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 found that treating each directory as its own separate application or package is helpful. If you need to share resources between multiple apps/packages, use your dependency manager, most of them seem to have some sort of way to use local packages.

Re: Monorepo Support

#17

Post by echelon » Sat, Sep 17, 2022, 4:52 PM UTC

hk1337 wrote: post #16

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 found that treating each directory as its own separate application or package is helpful. If you need to share resources between multiple apps/packages, use your dependency manager, most of them seem to have some sort of way to use local packages.

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 them, and rolling out updates n-many times is a game changer.

Re: Monorepo Support

#18

Post by malkia » Sat, Sep 17, 2022, 4:57 PM UTC

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…

Monorepo + micro-services 4tw.

Re: Monorepo Support

#19

Post by hk1337 » Sat, Sep 17, 2022, 4:57 PM UTC

echelon wrote: post #17

hk1337 wrote: post #16

Earlier quoted context omitted.

I found that treating each directory as its own separate application or package is helpful. If you need to share resources between multiple apps/packages, use your dependency manager, most of them seem to have some sort of way to use local packages.

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.

Re: Monorepo Support

#20

Post by tiltrus » Sat, Sep 17, 2022, 4:59 PM UTC

samwillis wrote: post #8

paulgb wrote: post #5

Render is one of those companies you don't see a lot on HN, but you talk to developers who use it and they have a lot of love for it. Stuff just works like you'd expect it to. We've been a happy user of monorepo support since it was in beta and it's worked great for us.

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 running close to the users. But I didn't see much of a peformance improvement with my web apps as they all have to communicate with Firebase. There's probably situations where this technology makes sense, but I haven't found a use case yet.