Loading Form...
Jun 4, 2020 | 5 minute read
written by Lee Trottr
Are you looking to leverage the JAMStack in your digital commerce initiatives? We’re here to help! We at Elastic Path have been embracing and supporting the JAMStack architecture for years and I’m going to explain today how we’ve done that.
As a Sale Solutions Consultant, I am always looking at our competitors and seeing the new initiatives that they are taking on. I recently came upon a webinar from CommerceTools that talked about using JAMStack, an architectural pattern we have been using for years, and felt compelled to share. The JAMStack is architectural pattern that has been around in some form as long as I’ve been a Solutions Consultant here at Elastic Path and in the last couple of years it’s really matured as a standard, in part by the great work being done by Netlify in getting the message out there.
So to level set, what is the JAMStack? First, it's not a product or framework you install and use. It's an architectural pattern and design, which can in my option be applied pretty much anywhere. The best definition is to use the one from the O'Riley book Modern Web Development On The JAMStack, Pg 8, provided compliments of Netlify.
These components became the JAM in JAMstack.
I said before, we’ve been using similar patterns to the JAMStack for all my time at Elastic Path. To illustrate this, about 5 years ago, we had a connection to Adobe Experience Manager (AEM) through an API known as the Commerce Integration Framework (CIF), which then connected to Elastic Path Commerce. This design at the time worked really well for an AEM developer to simply connect to the CIF within AEM and present commerce information, such as pricing.
During a discussion with a prospect who had already implemented AEM for an initial MVP commerce site, they had discovered that because the price needs to be loaded every time, it meant that the AEM Publisher server had to always render and serve the entire page due to the nature of the design. The AEM Dispatcher servers, which cache the page after rendering could never be used since the entire page was considered dynamic.
How they solved it I thought was elegant in it's simplicity. They inserted a static JavaScript snippet into the page where the price could go, which the AEM Publishing server then rendered the JavaScript directly within the page markup. That JavaScript would then be served through the page and executed on the client side within the browser. It would then go and execute a call to the API they had created to get the price. Now the same JavaScript, embedded in the webpage, could be sent to every client.
This now allowed the AEM Dispatcher servers to cache the page, improving performance substantially at a small cost of performing a second call with the JavaScript snippet to get that person's specific price. This pattern looks familiar doesn’t it?
We liked that pattern so much at Elastic Path, when presenting we began to refer to it as our "Generic CMS Implementation." We made this decision as we realized many times customers didn't get know what CMS they were going to use or if they were even going to use a CMS. But that was the beauty of this pattern, it would work almost anywhere. It was simple; we just needed to cache the static parts of the page load on high-speed edge servers and load the dynamic parts client side. It might not be the pure JAMStack as it defined today, using edge caching servers distributed around the world, but the concepts are very similar.
Fast forward to the formal JAMStack of today bringing this together in a much cleaner more robust way, the JAMStack focuses around using modern static site, generators such as Gatsby (or React, Vue, Angular) to create the site then deploy it to an edge caching CDN for fast delivery. If for instance you are able to host 90% of your site there and it's static, it makes sense that it will load faster as long as the remaining static and dynamic content/assets loaded by the JavaScript application executed on the client side can be served quickly enough.
Now here is the really cool thing, you're wondering, "this sounds great, faster site loads are always a good thing, but how can I use it? I've already got an eCommerce site." Well, if you are using a headless eCommerce system such as the Elastic Path Commerce Cloud (EPCC), you're halfway there. Do you have a CMS that has a headless or decoupled ability such as Contenful or Drupal/Acquia? A headless search like Algolia? Have all of that? Then you’ve already got all the platform components there. You could start hacking up a demo site with Gatsby on your own workstation in no time.
Here is the best part, Elastic Path as a headless microservice based eCommerce SaaS platform is ready for this now. We’ve be part of the JAMStack since we did our initial commit of our Gatsby store in January of 2019 and many of our customers have already taken advantage of it. You can check it out here, running Algolia for the search all sitting on the Netlify CDN and auto deployed from our Git repo when a merge to master is done. A front end dream.
Click here for access to our store frameworks
Click here for access to our github for the Gatsby Powered demo store
Want to know more about the JAMStack? Check out the Netlify book and also the JAMStack website. Ready to learn how you can use the JAMStack with Elastic Path and our Gatby store to being your digital commerce vision to reality faster and cheaper? Take a look at our open source Gatsby store and connect with our internal experts.
- Special thanks to Shaun Maharaj for his input.