Mug & Snug provides a platform that connects collectors, interior designers, businesses and home owners to one-of-a-kind homeware and kitchenware from the otherwise unreachable artists from around the world. We asked Phillip Gourley, CEO, his feedback about how he's been using Strapi to launch this e-commerce platform.
We're a Nuxt.js-based Single Page Application (SPA) staticly generated and pushed over a CDN for highest speed and availability globally. This is unusual for e-commerce but allows us to support a very large number of products without needing to pre-render and staticly generate thousands of pages at build/deploy time as we faced this issue early on in development.
We use Netlify's CDN and their pre-renderer which handles the fallbacks for SEO and refreshes, as we typically have no server or index files.
For the back-end we don't have anything fancy because we plan to scale this with the traffic but we have MongoDB Atlas for easy scaling and global availability later in growth and a simple EC2 server with PM2. We originally launched this over Docker and ECS but the tech and cost to run were unnecessary as we weren't planning to scale past one server for while so we dropped down to something simpler for the time being.
We looked into a number of payment providers and were able to explore integration with Stripe and Braintree. We were able to utilise Strapi lifecycles to keep product catalogues in sync with third party providers. Allowing product changes to sync to payment gateways easily.
Bootstrapping a platform and startup comes with a myriad of challenges, cost and instability. Despite our strong technical background, building an unconventional social e-commerce platform made these considerations for a small team are as prevalent as ever.
While we had experience with a number of headless CMS services, most were cloud based and none provided us with the opportunity to introduce our own in-house business logic close to our data. This flexibility and the simple model lifecycle was the deciding factor.
We chose Strapi as it allowed us to drastically reduce the technical focus on the familiar framework of a complex application and restore our focus on the value-add of our product. Strapi gives us a platform that can scale to meet low or high demand at a cost we control without getting locked into a SaaS product.
Customization wise, we obviously needed to build a lot of business logic into the controllers for handling orders, accounts, etc. We have a couple of unique endpoints for pulling back specific information like popular artists or products in dedicated endpoints for performance reasons they were better than the standard queries because we had to populate the different relationships.
We added and then removed GraphQL because the performance of the REST endpoints ended up faster and we leaned on a few different plugins for handling image assets with S3 so they could be compressed, batch resized and converted to webp over our CDN but no aggressive need for us to get involved with the actual internals of Strapi other than to help temporarily resolve a few bugs that were being actively worked on by your team.
We were able to develop a social commerce MVP within one month that otherwise may have taken six. This acceleration gave us earlier business insights, important opportunities to pivot and the refreshing ability to focus on the value-adds of our business.
Make sure you understand the responsibility of Strapi and the responsibilities you may still have. Strapi gives a great baseline but your decisions or poor structure can still have impacts to performance and security. Obviously Strapi can't solve the issues of slow database queries if you are over complicating your models. Strapi isn't a silver bullet that solves query speed times and security issues, you will still need to be considerate with the development.
Understand this from the get-go!
Strapi gives us a platform that can scale to meet low or high demand at a cost we control without getting locked into a SaaS product. This flexibility and the simple model lifecycle was the deciding factor.