4 ms·

You can check out their codebase here: https://github.com/gitlabhq/gitlabhq https://github.com/gitlabhq/gitlabhq Just looking at their gemfile is rather tellin

You can check out their codebase here: https://github.com/gitlabhq/gitlabhq https://github.com/gitlabhq/gitlabhq Just looking at their gemfile is rather telling: a couple hundred gems. I've always felt that if you're going above 100, you should carefully consider how much your codebase is trying to achieve. They're probably at the point where they really want to think about splitting off of their monolith codebase and into microservices.

spronkey 10y ago
Yeah, given how their ops situation is, I don't think that would be a good idea.
yxhuvud 10y ago
It is fairly large, but I still find it more organized than some examples I've seen. Also, I don't see another very common issue with big gemfiles in that they don't seem to have multiple solutions of one thing in there (ie multiple REST clients, DB mockers, etc).
marcosdumay 10y ago
> I've always felt that if you're going above 100, you should carefully consider how much your codebase is trying to achieve. This is a mindset issue. Some communities reject NIH so strongly that you get the opposite problem that everything depends on hundreds of different developers. Gitlab can start some library forks with more stuff integrated, or change communities. Microservices is something that can't help, as all the dependencies will stay just where they are (Gitlab is already uncoupled to some extent). But, anyway, most of those are stable¹, and I doubt many of Gitlab problems come from dependencies. 1 - They are unbelievably stable for somebody coming from the Python world. When I first installed Gitlab, I couldn't believe on how easy it was to get a compatible set of versions.
- debaserab2 10y ago
  I see the opposite of NIH especially in the RoR/Ruby world and I don't think it's always a good thing. Developers reach for a library for one piece of functionality in a discrete area of the codebase when they could have achieved the same functionality with a few lines of code. That's not automatically NIH, that's being pragmatic about the dependencies you're bringing in and are going to need to support moving forward.
luckystartup 10y ago
Maybe it's because I'm familiar with almost all of the gems, but I don't see anything wrong with their Gemfile. It's a pretty complex project, and they really do have a ton of integrations and features that need those gems. There's probably a few small libraries that they could have rewritten in a few files (never a few lines), but what's the point? The version is locked, and code can always be forked if they need to make changes (or contribute fixes).
- debaserab2 10y ago
  > (never a few lines) You'd be surprised what you can do by carefully considering what the desired outcome actually needs to be. Maybe there is justification for all the gems in gitlab's Gemfile, I didn't go through it with a fine tooth comb - but this reaffirms my experience that complex projects outgrow monolith codebases. Having an infrastructure outage take down your entire business is kind of a symptom of that.

spronkey 10y ago

Yeah, given how their ops situation is, I don't think that would be a good idea.

yxhuvud 10y ago

It is fairly large, but I still find it more organized than some examples I've seen. Also, I don't see another very common issue with big gemfiles in that they don't seem to have multiple solutions of one thing in there (ie multiple REST clients, DB mockers, etc).

marcosdumay 10y ago

> I've always felt that if you're going above 100, you should carefully consider how much your codebase is trying to achieve. This is a mindset issue. Some communities reject NIH so strongly that you get the opposite problem that everything depends on hundreds of different developers. Gitlab can start some library forks with more stuff integrated, or change communities. Microservices is something that can't help, as all the dependencies will stay just where they are (Gitlab is already uncoupled to some extent). But, anyway, most of those are stable¹, and I doubt many of Gitlab problems come from dependencies. 1 - They are unbelievably stable for somebody coming from the Python world. When I first installed Gitlab, I couldn't believe on how easy it was to get a compatible set of versions.

debaserab2 10y ago
I see the opposite of NIH especially in the RoR/Ruby world and I don't think it's always a good thing. Developers reach for a library for one piece of functionality in a discrete area of the codebase when they could have achieved the same functionality with a few lines of code. That's not automatically NIH, that's being pragmatic about the dependencies you're bringing in and are going to need to support moving forward.

luckystartup 10y ago

Maybe it's because I'm familiar with almost all of the gems, but I don't see anything wrong with their Gemfile. It's a pretty complex project, and they really do have a ton of integrations and features that need those gems. There's probably a few small libraries that they could have rewritten in a few files (never a few lines), but what's the point? The version is locked, and code can always be forked if they need to make changes (or contribute fixes).

debaserab2 10y ago
> (never a few lines) You'd be surprised what you can do by carefully considering what the desired outcome actually needs to be. Maybe there is justification for all the gems in gitlab's Gemfile, I didn't go through it with a fine tooth comb - but this reaffirms my experience that complex projects outgrow monolith codebases. Having an infrastructure outage take down your entire business is kind of a symptom of that.