BUILDER

Blog

Home

Resources

Blog

Forum

Github

Login

Signup

×

Visual CMS

Drag-and-drop visual editor and headless CMS for any tech stack

Theme Studio for Shopify

Build and optimize your Shopify-hosted storefront, no coding required

Resources

Blog

Get StartedLogin

This page was made in Builder!

‹ Back to the blog

The evolution of headless commerce

Learnings from migrating ShopStyle to Jamstack (2015 to present)

By Steve Sewell

Summary

Ecommerce websites need to be fast. But with so many technology choices out there, how do you know which is right for you? Read below to find our learnings, problems, and solutions.

The Problem

In 2014, we had an interesting predicament at ShopStyle. We had a massive monolithic codebase powering our entire tech stack - the user facing website, APIs, data ingestion, search... the list goes on. The tech was getting dated and difficult to work with, the site was slow and overly coupled, and releases were a hectic combo of praying, cursing, and tended to take forever. We wanted to improve the situation, but did not know exactly what to do next.

Enter Jamstack

When we first discovered AngularJS (then just called Angular) it was love at first sight. Simple, declarative templates with magical state powers. The code example below shows that Angular was new and unique, clearly ahead of everything else at the time.

Migrating the site

After lots of research and testing, we decided to migrate ShopStyle's frontend to Angular.

Some key goals were:

  • Development efficiency. Need to be able to produce new code fast
  • UX. Users need to have a good experience on our site
  • Performance. Pages need to load fast
  • SEO. Critical to our traffic at the time, Google must like our site

Next we did what every excited developer does with shiny new toys, we started building! We got the boilerplate setup, started filling in the content, all was smooth, at first.

Challenges

Then came finding all the challenges of adopting so early, with the rest of the ecosystem not necessarily yet evolved to support this move. *cue the sad violin music now*

APIs

The first challenge was APIs. We need content to load fast, and a standard REST-ful API wasn't going to cut it, as we were making many requests per page for the variety of content needed.

Our solution was to make new "page" APIs that aggregated all content needed for a page in one request, served from an edge cache, and filtered down to just the properties the site needed.

This approach was odd and rigid, but it was good enough and worked for us at the time.

Solution: GraphQL

If we were doing the same thing over again today, we would have an even better and more flexible tool at our disposal: GraphQL. GraphQL is built exactly for this the use case of gathering bits of data from lots of different sources and packaging them up nicely for your project to consume.

Credit: graphql.org

SEO

Our next learning was that while Google at the time begin saying "we crawl JavaScript rendered content", our experiments and data suggested otherwise. While they did seem to crawl some JavaScript content, they clearly were missing most of it. ShopStyle has hundreds of thousands of pages and Google's JavaScript enabled bot was simply not crawling fast enough.

Solution: prerendering

We needed a way to render content server side using Angular, and to be able to do it fast. No off the shelf solution existed at the time, so to solve this we created a framework called Compylr that transpiled browser only Angular templates to Handlebars - which can render on the server, very fast.

In order to support this we did something that was discouraged at the time - we made one large state tree, that could easily be constructed on the client or the server, to pass to the Angular or Handlebars template. Ironically, this has become the best practice as of recently with frameworks like Redux becoming the go-to choice for single global tree state management.

<a ng-repeat="product in products" href="products/{{product.id}}">
  <img src="{{user.image}}" ng-show="foo && bar">

  {{foo}}

  <div ng-include="'path/to/partial'">
  </div>
</a>

{{#forEach 'foo' in bar}}
  <a ng-repeat="foo in bar" href="products/{{product.id}}" ng-href="products/&#123;&#123;product.id&#125;&#125;">
    <img src="{{user.image}}" ng-show="foo" {{hbsShow "foo && bar"}} ng-attr-src="&#123;&#123;user.image&#125;&#125;">

    <span ng-bind="foo">{{foo}}</span>

    <div ng-include="'path/to/partial'">
      {{> path/to/partial}}
    </div>
  </a>
{{/forEach}}

Today, theres even more options. In particular, we recommend Gatsby

Content Management

After solving those challenges, we built and launched the site. Great!

But then we didn't think to expect what came next. The business requests! Marketing would request new custom pages, copy updates, A/B tests, and personalization. Product would request new feature flags and more tests, and content needed translating to many locales. Oof!

To solve for this, we built a rough internal headless CMS. It used data models to allow some level of control of parts of the site. It wasn't amazing, but it was good enough.

Solution: see below

Performance

This was the one that really bit us, as it was a major paint-point as we scaled our web app. AngularJS wasn't really built to handle the complicated interfaces that a large-scale web app would need.

Client-side interactions started to feel slow, especially on mobile devices.

Solution: modern frameworks, in ShopStyle's case - Angular 2

Fortunately, we weren't the only ones to notice this problem, and the Angular team was already working hard to solve these problems.

The new Jamstack era

Credit: Netlify

The appeal of the "new stack" - which has many names, such as "Jamstack" "Headless" "Progressive Web Apps" and more - started gaining global attention and progress.

More frameworks were coming out and taking on the challenges of making this new technology blazing fast, and finally overtaking the prior world of PHP+jQuery

React, Vue, Next.js, Gatsby, Svelte, Angular, etc began paving the way on the frontend. GraphQL adoptions grew rapidly on the backend, and on the infrastructure side content delivery and compute at the edge really started taking off

Combining these techniques we were able to make ShopStyle blazing fast. We were even called out on stage at Google Next and on Twitter by the core Angular team for our speed:

But what about content management?

After what felt like a herculean effort to modernize our tech stack and optimize the s*** out of it, there was still a major remaining problem: content management

Our data-model based internal CMS was no longer cutting it. We even tried other up and coming headless CMSs to find the same problem over and over. There was still a never ending dependency on developers, and the requests didn't stop coming in:

"We need a new layout on our homepage for black Friday!" "We need to add a signup form on this new landing page!" "We need to show a different hero based on a visitor's shopping history!" "We need A/B tests on our new campaign!"

Ugh. We didn't have the staff, or the time, and we really did not want to be the ones blocking for these one-off albeit important business updates. On top fo that, we didn't want content to live in our code either.

What we needed was a site builder like Wix/Squarespace/etc but that could work within our custom tech stack so that we could use our code components, leverage our existing tracking, SEO logic, performance optimizations, etc. And we needed to be able to manage all of this content outside of our code.

Enter Builder: Visual, Headless CMS

So I left ShopStyle in 2018 to make the first version of Builder. A headless, API driven, visually editable CMS.

After seeing the benefits of this approach, combined with features that really unlock non-engineers to create, measure, optimize, repeat, without needing developers involved, but completely customizable by developers, it became obvious it was a no brainer.

We got ShopStyle as our first enterprise customer, then started packing more on, such as Everlane, Vistaprint, Afterpay, Atoms, Alo Yoga, and many more.

Maintaining performance and control, and delivering powerful features like drag and drop editing, landing page building, a/b testing and segmentation, was a game changer for these businesses migrating to the new stack.

Conclusion

The new world solves many problems of the old, and new tools are cropping up every day to move our technology ecosystem forward to be faster, more scalable, and more optimized in every way.

The key problems and solutions we found were

To summarize: if you are panning to go Jamstack, or improve your existing site, we highly recommend using Gatsby, GraphQL and Builder. And for those who want to get started really quickly, try out our new Gatsby + Builder starter.

Read more on the blog
High performance no-code
Builder raises $3.25M to power no-code for e-commerce

BUILDER

Product

Visual CMS

Theme Studio for Shopify

Sign up

Login

Featured Integrations

React

Angular

Next.js

Gatsby

Get In Touch

Chat With Us

Twitter

Linkedin

Careers

© 2020 Builder.io, Inc.

Security

Privacy Policy

Terms of Service