Shifting to an API architecture

When we launched Scalia in September 2016, we instantly thought that developing our vision on a web platform was best. First, this format was the most appropriate to present a concrete product to customers, especially for new services like ours which could seem a bit obscur at first. Secondly, we did not really have a choice as our core team had exclusively a web-development background.

We have never regretted this decision. Although our endeavour has been clear from the start (more on this here), like any startup we had to iterate and experiment at a very rapid pace and the web format was the best one for doing so.

It was only after a full year of commercialization that we started to realize the potential of setting up Scalia as an API.

This idea emerged as we were doing more and more training sessions to onboard new users. We weren’t big fan of these sessions. They were extending our sales cycle and quite frankly they were tiring. We needed to find ways to inject our tech in large Enterprise processes. It was time to develop our own API.

Methodology

Our platform being built with Ruby on Rails 5, we had all the tools to build a RESTful Json API. The building itself wasn’t the hardest. the trickiest was to establish a clear roadmap. We had been developing Scalia so fast that we had tons of interconnected features. We had to separate features from one another and think of them in a very abstract way.

We split out the core Scalia process in 5 key features — importing, enriching, standardizing, controlling and synchronizing — leaving many smaller features on the side for now.

We then had to split between reading and writing APIs. All together, we had 9 different APIs to develop and we had to find the smartest way of doing so.

We divided the work load in two different sprints. The first sprint’s goal was to be able to go through the whole process the simplest way possible. For the second sprint, we focused on filling the gaps that had been left behind.

Once our first sprint was completed, we were able to expose a first version of our API directly on our website.

This was a milestone that we were very much looking forward to.

Another aspect of our methodology was getting equipped with the right tools.

• As a development and testing environment, we went with Postman. We benchmarked a couple of other tools but none had the set up simplicity that the Postman desktop app offers. Plus they made an impressive work on their design. ;-)
• As a documentation support, we went on to host it on APIary. We came across this service while looking for an easy to use documentation solution. We weren’t disappointed at all, even though we believe that their request interface could be improved.

What’s next?

We are close to completing Sprint B. We are aiming to complete it by end of Q3 2018. One important aspect of our platform would remain un-APIed: our set up. When a new organization wants to use Scalia, they must first set up their own taxonomy and nowadays this can only be done through our web platform. Luckily for most organizations, the Scalia team helps them doing it at first but an increasing number of customers are requesting this service as an API. This is particularly useful for organization using a PIM as this would avoid double inputs and therefore taxonomy discrepancies between both tools.

Our set up API will be our core Sprint C. We are aiming to launch it in Q1 2019.

What are the benefits ?

From all standpoints our API structure has many advantages.

To begin with, putting together this roadmap forced us to separate Scalia’s features from one another. Our code and our vision are cleaner and clearer than ever. As a result, our customers can balance a use of our independent functions from both our web platform and our API. This makes Scalia incredibly flexible. As a reminder, flexibility is one of our main differentiator compared to traditional data integrators.

Moreover, all of our customers have pre-existing tools of some sort, being a CMS, a PIM or even an ERP. It’s hard for them to get rid of this legacy, especially for large companies which have developed or customized these tools sometimes at a great expense. Scalia’s APIs offer an alternative to directly embed our tech into their existing architecture. At times, integration can be so seamless that the business user doesn’t even realize it. APIs are a must have if we want to keep on digging on the large enterprise segment.

Finally, from an architectural point of view, developing this API opened up the possibility to design Scalia as a microservice architecture. For instance, by using our API internally, we are aiming to completely separate our web app from our back-end by Q2 2019. By doing so, it will be much easier to scale up our performance as we will continue to rapidly grow.

This wasn’t part of our priorities when we started but as Scalia matures, making our software a clean-code environment is becoming a priority. We think this underpins intelligent tech and business development.

Conclusion

Don’t get us wrong, we are not API freaks (yet). When we want to experiment a new feature, we still go through the web format. But API has taken a bigger part in our developments these past few months. As we will continue to grow and to get structured, we are betting that it will probably take the lead within 6 months time, as the benefits for our customers and directly for ourselves are obvious.