[danforddotdev]

I'm curious what their data access layer looks like underneath that monolith. Is the Rails piece mostly now just a frontend for dozens of other services, properly owned and maintained by other teams? I don't mean to trivialize something that's obviously huge and complex as "just a frontend", but IME one of the biggest things that breaks down in a Rails monolith as it scales is heavy, direct usage of ActiveRecord. Either there's lots of DB migrations happening since there's so many different developers working on different features, which makes development with a shared DB tricky, or the scale makes DB performance problems hard to diagnose since they cut across many teams or tables in complicated ways.

[jakemoffatt2]

Can't speak to how GitHub does it, but in every Rails org I've been at, eventually we create secondary services that own a specific domain, and the primary app becomes a gateway that clients use to talk to those services. It's rare to spin up a new service in a new language/framework. A typical pattern is to migrate the service within the monolith into a Rails engine, and then move that to a new app where the app mounts only that engine, or one can find a way to make the monolith deployable with only certain engines mounted, like with an env var.

A Rails engine is basically a self contained Rails app, including routes, which you can mount inside of a host Rails app at any route if your choosing. They're usually used to build reusable libraries, but this use case also works very well.

[withinboredom]

I've heard this several times over the last few months. Like what makes several devs working in the same area of the code "hard"? In my experience whomever is lucky enough to commit first gets the easiest of it, everyone else just rebases and resolves their conflicts. Maybe if you don't rebase and merge instead? I've seen some screwed up stuff happen from bad merges... like entire lines of code vanish.

But generally, I've worked with hundreds of devs in the same code base without issue. So, why do people ask this?

[danforddotdev]

Well, I gave a specific example in Rails, using DB migrations against a shared DB. It’s not an unsolvable problem, and of course each dev can have their own DB, but if this is poorly managed it’s easy to become unwieldy. Outside of that, if many devs are constantly making dependency changes such that every time you “git pull” you have to rebuild environments, etc. Maybe devs are adding features but not prepopulating dev environments with sensible test data so your dev environment gets horked. Etc etc. Its not usually about merging the code itself.