• Log in
  • Sign up
  • Contact Us

Get in touch  

Blog • Developer

Fixing the Moltin JavaScript SDK

Last updated: 24 Jun 2019
One of the primary reasons we started building Moltin was to bring the huge potential of secure commerce to the frontend, to the JavaScript developer! Over the last couple of years, we’ve seen the number of developers running stores on Moltin using front-end technology like JavaScript only, blossom.

Being able to build JS experiences without dealing with heavy server-side logic and hosting, etc. opens up the platform to so many more smart people wanting to do stuff, and really changes what people think commerce can be.

So, to make that easier for all our users, we released our first incarnation of the JavaScript SDK back in 2013.

The SDK helped extrapolate the myriad of API endpoints into a neat logical set of interactor methods that could be used simply and quickly in a frontend application.

As time progressed, we received more calls to serve different sections of the JavaScript community. NodeJs, TVJS, and so on…

Our JS SDK went from being a few files to growing into several different sets of files compiled down into different usable modules.

They worked really well, we grew massively with that version of the SDK and expanded our JavaScript user base dramatically.

But over time we began to see issues. The way the SDK was built did not lend itself to supporting the growing JavaScript community. Specific types of use for the SDK needed to be compiled into separate distributions. This was a small annoyance to deal with, but it also made it harder to push out features for the SDK as you could result in duplicating methods but with different logic in order to support two sets of systems.

We also wanted to bring more help and functionality to the NodeJS community, but our various releases for NodeJS ended up being a consistently buggy and difficult experience. Something we didn’t want for our users and never seemed to be able to get working solidly under the original interpretation.

So, we were reaching a point where we were running up against a wall. The SDK was too brittle to continue bending and warping to fit our users’ needs, and the time it was taking for users to get the features and benefits from any changes was far too long to be useful.

We took the decision to basically scrap the old SDK and start afresh. Key problems we wanted to address immediately were:

  • Removal of CoffeeScript
  • Fully tested
  • Automatic authentication

With the overall objectives of:

  • Releasing a solid piece of work to build on
  • Maintaining correct semver off a base version
  • Follow standard patterns to increase the overall support base

The automated authentication was one of the bugbears of the first SDK, but the new version will simply queue up a call from the front-end whilst it retrieves a new access token and sends the call on with the new credentials, without the developer having to worry about storing and evaluating dead credentials.

Our test coverage has expanded from 0 to between 60 and 70 tests. That’s 0% to about 85% test coverage.

We’ve completely dropped CoffeeScript for standard ECMAScript 6. CoffeeScript was a love or hate for most JavaScript developers, and some of our community struggled to be part of the development cycle for what is a piece of open-source software, built to help and engage the developers on our platform.

In a few iterations we had a fully tested core, managed to fix our first objectives and now we’re rolling out updates and features regularly all carefully versioned. By following a standard pattern we’re able to release the JS SDK as a single piece of work that can enable functionality across huge swathes of JavaScript technology out of the box, including NodeJS, TVJS, and standard Javascript.

By re-envisioning the SDK we’re putting in place a solid foundation on which we can start building better functionality and longer-term goals with our community of developers and our team within Moltin.

We have some amazing features coming out soon, and having that solid foundation will mean we can deliver that functionality quicker and smarter than before.

As always, the Moltin goal is to change how developers build commerce completely, and the JavaScript community and its developers are a huge part of that mission. We see them as leading a dramatic change in the web at the moment, and we want them to also feel the dramatic change we’re bringing to commerce.

To get started with your JS storefront, firstly, sign up and find out more, take a look at the JS quickstart guide or view our SDK on the GitHub repo.

From Our Blog

11 Sep 2019

An Introduction to eCommerce APIs

In this post we’ll cover what an eCommerce API is, why you should use one and how you should evaluate an eCommerce API.

Read More
Adam Sturrock
in Developer | eCommerce
21 Aug 2019

Systems quotas to protect your store

Today we are introducing fair usage quotas within our architecture. The use of quotas is common practice for web facing services and their introduction by Moltin is to ensure an optimal and fair...

Read More
Jonathan Prest
in Announcements | Developer
20 Jun 2019

Analytics for your Moltin store

Today we’re going to take a look at how to use best-in-class data warehousing and analytics solutions on top of Moltin, specifically in relation to orders and order items.

Read More
Matt Foyle
9 min. read in Developer