Should I craft my own gem?

Alexandre Overtus
2 min readNov 26, 2020

As of today, thousands of gems exist through rubygems.

When facing a recurrent problem you can crawl over existing projects or be tempted to start your own solution.

Try to answer those questions before starting to write your gem:

Does it exist any maintained projects which could solve my use case?
You could looks at stars on the github repository, commits pulse graph…

What would be the integration time VERSUS the development and maintenance time if you decide to write your own implementation?

Here are thoughts you or your team should keep in mind while thinking of writing an in-house gem.

Open Source

Pros

  • Maintenance (1)
  • Integration Time(2)

Cons

  • Include every related dependencies
  • Monkey patches for customization (3)

In house

Pros

  • Limit to what is required by the project
  • Include your own business logic (4)

Cons

  • Maintenance (1)
  • Development time
  • Include your own business logic (4)
  1. Maintenance

Growing your code base, it’s another part of your code you will have to maintain and which will potentially contribute to your technical debt if you don’t.

Building your own library will require your team to keep it up to date.
Think about bugs, new ruby version, new dependency version …

Take the example of the gem devise, if the gem is popular there is a higher chance that your team as well as new team member will know about it but also that the gem is maintained by the community and evolve through versions without any cost aside of fixing breaking changes.

Building or contributing to open source software is a good way for your team to expose its skills and attract new devs.

Using dependabot you’ll ensure your project is using the latest gems version

2. Integration Time

Trust what exist, if something similar has already been built, it may be because what you are looking for require a small twist and could use something which has already been used, proved and improved by other teams.

3. Customization/Monkey patch

The fact that you are using a public library, may require you to monkey patch it in order to match your business logic which could make your code harder to maintain as for sharing the knowledge about the specific customization.

4. Business logic

Writing an internal gem is a good way to share common behaviour and business logic across multiple apps while preventing code duplication.

On the other hand, a gem is usually designed to build an abstract layer which solve a generic use case.

Specification should be handle through configuration, passing params to methods… You can’t say what future awaits, you want to prevent refactoring code which has been focused too much on a specific use case.

--

--