GitLab sticking with Ruby on Rails

🕣︎ - 2022-06-09

In Why We’re Sticking with Ruby on Rails at GitLab the CEO of GitLab writes:

Wouldn’t it be better to have a proper plugin interface? Or better yet, a services interface modeled on microservices? In a word: no.

Which is short and to the point. The article continues:

Not only do these approaches impose deployment and integration hurdles that go far beyond “I made a small change to the source code,” they often enforce architectural constraints too rigidly. Anticipating all the future extension points is a fool’s errand, one that we luckily did not embark on and do not have to.

Very good point - make it easy to contribute rather than building complicated integration of plugins or splitting everything out in microservices.

With our boring modular monolith, users and other third-party developers can and do contribute enhancements to the core product

I wasn't convinced that GitLab would be a great choice when we installed at it work in 2016, but it has only grown better (and our instance is widely used, among other reasons because we took advantage of GitLab being free software/open source and added single-sign-on support and automatic account creation into it, so our colleagues didn't have to sign up) - I think reasoning like outlined above has very likely been a big contributor to that.

Boring is good.

Add comment

To avoid spam many websites make you fill out a CAPTCHA, or log in via an account at a corporation such as Twitter, Facebook, Google or even Microsoft GitHub.

I have chosen to use a more old school method of spam prevention.

To post a comment here, you need to:

¹ Such as Thunderbird, Pan, slrn, tin or Gnus (part of Emacs).

Or, you can fill in this form: