The Rake - High-quality clothing store

Business Overview

The Rake is a pioneering luxury ecommerce platform offering an expertly curated selection of tailoring, shirts, accessories, footwear, luggage, and watches, as well as exclusive collaborations with the most brilliant artisans and brands in the world. Initially, The Rake was a fashion magazine that successfully expanded into ecommerce thanks to cooperation with Hatimeria. From the start, our goal was to deliver a fast and reliable platform combining the best features of the online stores and CMS systems.

Initially, The Rake was a fashion magazine that successfully expanded into ecommerce thanks to cooperation with Hatimeria. From the start, our goal was to deliver a fast and reliable platform combining the best features of the online stores and CMS systems.

How it all started?

When we took over the project, The Rake has already had a Shopify-based online store and a blog on Wordpress for almost a year. The blog was set up on the main domain whereas the subdomain was directing to the Shopify platform.

Observation

At first glance, both solutions had a similar design, but once you started browsing it, the differences were bold. Keeping their look similar meant all the work on the design was always doubled as Shopify and Wordpress couldn't share a template. As a result, besides similar design, there was no connection between these two platforms.

Blog's articles rarely mentioned products from the online store catalog, and if they did, it required a lot of editor's manual work to find and paste the correct URLs or to add product's pictures. Any changes to the stock level or URLs also had to be reflected in the articles.

As a result, even though the blog was gaining a lot of attention (over a thousand people on the website daily), the conversion rate was unsatisfactory.

Idea

As a result, even though the blog was gaining a lot of attention (over a thousand people on the website daily), the conversion rate was unsatisfactory.

Searching for the right tech approach

Both Magento and Wordpress have built-in rendering engines, but they aren't compatible with each other. We had three options to choose from:

1
Build two separate themes, each for every platform, and make sure they look alike.
2
Use one platform as a front-end and build a connector to the other one.
3
Create a separate front-end application that would connect to and retrieve data from both platforms.

Technical overview

We decided to keep this solution and build an ecommerce website to extend the blog's functionalities. We agreed that the best option would be to use Magento 2 which was released earlier that year.

Option 1

It was clear to us that the first option, while the easiest, would be challenging to maintain in the long term. Our work would be doubled as every change to the front-end part would require changes to both themes.

What's more, the HTML structures in Magento and Wordpress are different, so it'd be almost impossible to maintain the same look in both themes.

There was another disadvantage of such an approach. All the data would have to be retrieved twice - for the blog and the online shop

Option 2

The second solution doesn't have the problem described above, but it also wasn't ideal for us. As Magento is an advanced application, it would be the best option for the store's front-end. It would connect to Wordpress only to fetch editorial content, so one theme would be enough.

However, to prepare data for it, we would need to make an HTTP request in the background during rendering, build a synchronizer that would push data from Wordpress to Magento or create a way for Magento to use Wordpress tables directly.

Only the third option seemed viable, but even in this case, adding any new feature to Wordpress would require changes in Magento’s front-end.

Option 3

The third approach was the most challenging one from a technological perspective, but it was the best option for maintenance and future development.

It required more work from the front-end team as the whole application had to be built from scratch. However, separating the front-end and back-end parts provided us with many advantages.

The one that was crucial from our perspective meant that any changes made to the internal structure or logic of one application didn’t have to be mirrored in the other one anymore. The front-end application would use REST APIs of both platforms, as they don't change between upgrades; thus, we could rely on them.