Case study: Check out Rarebird’s brand-new Hydrogen store →

The birth of a Cangaroo

Alessio Rocco

25 Mar 2016Development, Solidus, Ruby On Rails, Open Source

Alessio Rocco

4 mins read

Before getting deeper into some technical Cangaroo guide I wanted to give some more insights about how Cangaroo was born. This is the story that tells how the death of a SaaS gave us the opportunity to create a brand new open-source project.

One of our clients has many Spree stores, almost ten and all of these stores share the following features:

  • send order information data to a third-party application;
  • receive stock updates from that application;
  • receive shipments updates from that application;
  • send an email to the customer service when an order is considerd risky.

In the first place you can think that the easier way to accomplish this is updating each store code to "speak" directly with that application in order to send and receive data. This introduces a lot of code duplication and is really error prone.

Another solution could be to create a gem that is included in all stores. At the beginning it looked like a good solution but what happens if you had to add another feature? For example what if you have to send an email for each new customer? At this point you had to:

  • update the gem to include this feature;
  • update the new ref of the gem into the Gemfile of each store;
  • run tests (often duplicated) on each store;
  • deploy each store.

Now, it can seems like reasonable approach but think at each time you find a bug and you have to replicate all the steps above. It's time consuming and we love to use our time to build new features instead of repeating actions mechanically.

Another problem comes when any third-party application endpoint has some problem, like a downtime. In order to don't loose data you need to add a queue system to retry the request. Of course each store needs its own queue system with all performance related stuff that increases infrastructure costs.

With the primary aim to solve this scenario the Spreecommerce created a Saas named Wombat, whose claim said:

"Wombat is your store’s integration platform; connect any store to any service. Wombat gets you up and running in minutes, no custom code required.".

With Wombat an user can configure what to do on a particular event, with a UI interface, for example you can setup something like

When a new Order comes in from the store A, send an email to the customer and
tweet an happy face.


When a new Order comes in from any store, send an email to the customer

Wombat talks with external services API using integrations that live in the middle between Wombat and third-party services. Each external service has its own integration, for example there are integrations for Mailchimp, SalesForce, etc.

Everything was working fine until the day the Spreecommerce was aquired, Wombat died and the source code was released only to customers.

At this point we had to decide how to go ahead, and the alternatives were:

  1. to take Wombat source code and to host it on our servers;
  2. to reintroduce features back into the stores with all the issues described above;
  3. to create an alternative system that replaces Wombat behavior.

Accordling to one of our cool clients, we decided to go with the latter and, since we strongly believe in open-source we also decided to publicly release it. Cangaroo was born.

Cangaroo is named after the Kangaroo animal, which I've seen together with a real wombat during one of my trips across Australia. Unfortunately Kangaroo gem name was already taken so we changed it a bit.

Wombat and Kangaroo A picture with a Wombat and a Kangaroo taken by me in Australia.

Cangaroo is a Rails Engine that you can mount on a new or exsisting Rails application. One cool thing about this project is that it uses the same API specification of Wombat so we don't have to change anything into our client stores repo continuing to use the code that was acting as an adapter for Wombat (via the spree_wombat extension).

The main differences from Wombat are:

  • Cangaroo is designed for developers, not for endusers. As a developer I prefer to use my editor to configure behaviors instead of clicking around a web page; this is why it's developer friendly, it doesn't have a UI like Wombat, everythings is done via code.
  • Cangaroo doesn’t store data like Wombat did, it just receives data and decides what to do based on how it's configured.
  • Lately Wombat added the possibility to also schedule recurring requests to external services in order to receive data without having an event that triggers that call. For now Cangaroo doesn't have this feature but it's something we are planning to add as soon as possible.

This is the whole story about Cangaroo and why we decided to create it. To learn more you can take a look at README and stay in touch with our blog. We are planning to post soon a tutorial that explains how to setup Cangaroo, integrate it into a spree/solidus store using the spree_wombat extension and one of the existing Wombat integrations.

Related posts