Engineering

All about boosting customer happiness with science and code

❮ Blog Home
monolith of code

Scaling Wootric’s Ruby on Rails Monolith

October 20, 2020 By Raymond Sohn
Co-written by Alfonso Cora and Dan Pitrowski.

 

The Problem: Code Reuse

Code reuse is a recurring problem for every organization, and Wootric is no different. Our Rails’ applications share code in a variety of interesting (albeit sub-optimal) ways, ranging from ad-hoc API endpoints to just copy-pasting code on an as-needed basis.

  1. Language translations were shared through an ad-hoc API endpoint. This isn’t great because it’s an HTTP request for flat text files. It adds enough latency to our system that it’s noticeable. We created a tangled graph where apps relied on each other via the network for the translations which were static files. This caused latency issues for the apps that relied on that app.
  2. Rails models were duplicated (copy-pasted) on an as-needed basis. This is problematic because depending on the repository you may not have consistent validations, associations, and methods to access the database.

This worked out fine for a while, but as we started to add more apps it started to really take a toll on the reliability and consistency of our service. Over the years, various solutions have been proposed from using git submodules to micro-services but each of those would require us to implement our own layer of security, versioning and integration with our Ruby apps.

It wasn’t until we started investigating the use of a private gem and git that we realized these 2 combined were a winning solution. It ticked all the boxes for security and versioning that we required and it integrated neatly into our Ruby ecosystem.

 

The Solution: A Private Gem

When we finally started, the project happened slowly in two big pushes. The first was by myself to create a proof of concept. The second push was by Alfonso Cora to put it to the test. By sharing important information like account models and static files, we saw improvements across the board:

  • Fewer HTTP requests between apps to get data like language translations.
  • We can finally reuse code across many apps, like Rails models.
  • Easier for the team to understand and make changes.
  • HTTP calls between networks went down to 0 because now they have access to the files directly.

To bring it all together, we created a private gem to be used across all our apps. We realized this ticked all the boxes.

  1. Privacy - sensitive code could be kept secure in a private repository.
  2. Security through authentication - it could be authenticated using GitHub’s OAuth. Learn about GitHub’s OAuth we used in the link below. https://github.blog/2012-09-21-easier-builds-and-deployments-using-git-over-https-and-oauth
  3. Versioning - it could be pinned to a specific git tag, hash, and or branch, which is also nice because in development we can pin a PR to a branch of our gem.

 

Trade-Offs

I would be remiss if I didn’t talk about some of the trade-offs. The biggest trade-off is that all this machinery requires more engineering brainpower to understand how all of this works.

Essentially, we are trading engineering time to make our code base smaller and more consistent. Now, a change to shared code requires more effort from the team to learn and maintain.

But over time this becomes less of an issue. We’ve been using a private gem to share code for several months now and it’s been working out great. Most everyone on the team has contributed to it and it now feels very natural to use it.

 

Conclusion

Invariably any growing organization needs to evolve from what works today to scalable solutions for the future. Only when the need arose did Wootric pivot to using a shared library with a private gem.

Does your company need to make the same transition? Of course it depends.

For us at Wootric it came at exactly the right time, and it allowed us to reliably support more and more Enterprise clients. Consider the pros and cons, and make the decision for yourself.

Filed Under: Engineering