Headless is the new buzzword that you must have come across in E-Commerece. Headless solutions have been getting quite popular because of the increase in the number of digital platforms that are used to communicate with users. Right from tiny smart bands to large plasma screens, content can be consumed in so many ways. And, each medium has its own set of unique features and challenges. Hence, a headless content source means it’s easy to decouple the content layer from the view layer.
But what exactly does Headless solution mean? According to Wikipedia, “Headless software is software capable of working on a device without a graphical user interface. Such softwares receive inputs and provide output”. So, the crux of it is that the solution that we are talking about will have only one responsibility – to fetch the data requested from the storage (mostly database) and return that. It doesn’t care much about the presentation layer.
We took a similar approach for one of our clients who had a very unique E-Commerce requirement. Unlike typical E-Commerce requirements, this one didn’t deal with standard SKUs. This website deals with selling photographs of Marathon runners taken during the event. This means, the relation is one Marathon event has many participants and one participant can have many images. Some of them can be common as well. So, as you can see in this kind of a situation, a traditional E-Commerce solution would be quite difficult to use when it comes to managing products.
How we built that custom solution can be a small little case study in itself. However, right now I am going to talk about a headless solution that we built using Laravel which addressed two very important problems – enable the client to go to market quicker by reducing the time by more than 50% and saving a lot of money on storage cost.
The problems
After running the marathon, the runners would be interested in purchasing the images and sharing them on social media to let their friends and family know about their accomplishment.
Now, for this to happen quickly, the client needs to not only dump all the images from more than 20+ photographers, sort them and tag them based on BIB numbers of participants, create a CSV but also upload the images to the cloud storage (in our case S3) after resizing them. This was taking a lot of time and manpower and we were tasked to find a solution to this problem.
We figured out that the solution is at multiple folds and we can improve the time to market by doing the following things:
Resize images and scan for BIB number using Google image recognition
The images coming from the photographers were from DSLRs and the first obvious option was to optimise them for the size that we required.
So, we used Laravel jobs which will use Laravel Intervention library to optimise images and make them ready to upload to S3. The client would create a folder on a local machine in his/her office, dump all the images in that and then run an artisan command giving the folder name.
After that, the magic will start. The command will start optimising the images, resizing them to different sizes (3 in total) which were required on the website based on the design.
Once the images are resized, the command will also send images to Google Image Recognition API and try to get the BIB number data. And, use this to also create a CSV where the BIB numbers were used along with a percentage.
The client will then use this CSV to further do the tagging. There would be some images where there would be no tagging because the API would have shown less confidence and in some it would have failed. However, we were able to save more than 60% of their work in terms of tagging users and also now it required less manpower.
Using Lap time as a way to search images
One more important thing which we did was reading the time on the images and based on that calculate the lap time and tag them to the CSV. Many people who ran the marathon didn’t remember their BIB numbers. However, they did remember their lap time (obviously because it was much more personal compared to the BIB). So, we would allow users to search images based on their Lap time. Once you put in the lap time, it will try to match all participants whose lap time was around that time with some buffer. And this way the participants could easily find their images without knowing their BIB number.
Saving cost of S3
Storage cost on S3 in general is quite cheap. But when you are talking about 20 photographers uploading so many images for each event, the size can be huge. On the top of that, as per the client’s stats, about 15 to 20% participants would actually make a purchase of the images. Storing all the images would increase the storage cost while most of them won’t ever be used. However, to store all the images because we don’t know which is required would bloat up the storage cost.
To solve this problem, we came up with a solution of running a headless Laravel app. When an order is placed, based on the image names, the Laravel headless instance running on the office premise would start uploading the images to S3. Once the jobs for an order are done, a webhook will be sent to the main site informing about the fulfilment of the order. This way, we would only upload the images which are being purchased yet be able to upload any images from any participant with a very small lag time. So just imagine instead of uploading all images from 20 photographers, we are uploading only around 15 to 20% of the images for which an order was placed and hence around 80% cost saving on S3 billing.
Personally, I feel this is the best part of our job. We have the power to build solutions which can make a difference. A simple application running on a local machine (our headless solution) connected to the internet can do so much and save so much time and money. In this custom e-commerce platform, the headless app running as an independent service made it possible for the client to reduce the go-to market time, staff strength and reduction in the cost of storage.
