Sticker Mule is the easiest way to buy custom stickers. We offer free online proofs, free worldwide shipping & fast turnaround. Since launching in 2010, we’ve helped more than 30,000 customers including Google, Facebook, Twitter, Tripadvisor & Shopify order custom stickers that kick ass. More recently, we launched our new brand Button Frog. It’s everything our customers love about Sticker Mule, but for custom buttons. Here’s what our engineering team is working on.
Tech Stack
We primarily use Ruby on the server-side and of course Javascript on the frontend, although Javascript is becoming increasingly tempting server-side too as we’re finding lots of cases where implementing some of our core logic in an isomorphic way could really help us DRY stuff up.
Our main application is built on top of Spree which is a Ruby on Rails ecommerce framework, over time we’ve layered a couple of javascript frameworks on top as we’ve built numerous customer facing and internal single page applications. Recently we’ve settled on React with a Flux inspired immutable data tier, that’s really been working out for us so far.
MySQL is still our primary datastore, we’re trialing AWS’s new Aurora service which is a MySQL compatible DB that’s touted as a faster and more highly available alternative, so that looks like where we’ll be heading in the short term.
We recently started building out the next iteration of our infrastructure using CoreOS & Docker on AWS. Using a blue-green deployment system is proving to make deployments (and the occasional rollback) a breeze. We’re not quite at the continuous deployment stage, but it's certainly within reach.
Engineering Focus
Our codebase is over five years old now, and we’ve gone the monolith-first route to say the least. We committed a considerable amount of engineering time to rethink and restructure our application to make it more performant and maintainable.
Certain aspects of our system have cleanly delineated boundaries so they are prime candidates for extraction to standalone systems. Our initial research showed that sometimes the communications overhead isn’t worth the cost, so in certain cases we’re simply extracting chunks of functionality to individual Ruby libraries. We found we still get a lot of the benefits without a lot of the complexity when compared to a full blown “service”.
Plotting a migration path from a single monolith to a more modular, service oriented structure is an interesting challenge that our team is embracing. The first step we’re taking down this route is re-implementing our checkout process, which is currently a traditional multi-step server (Rails) rendered flow that’s augmented with a little Javascript. Our new checkout is a single page app using React, and as part of this project we’re formalizing a lot of our core features like pricing, shipping, payment etc. in isomorphic Javascript libraries that we will later reuse in a new NodeJS based order management backend.
The checkout is a critical piece of our customers experience so any changes have to be really well planned and tested, with this in mind we plan on rolling out our new checkout in tandem with our existing one. This will enable us to A/B test it with a small number of users to ensure it doesn’t negatively impact conversion rates.
