Re-imagining our JavaScript SDK – moltin – Medium

Re-imagining our JavaScript SDK

☞ 

#Reactjs #javascript

  • So, to make that easier for all our users, we released our first incarnation of the JavaScript SDK back in 2013.
  • Key problems we wanted to address immediately were: – Removal of CoffeeScriptFully testedAutomatic authenticationWith the overall objectives of: – Releasing a solid piece of work to build onMaintaining correct semver off a base versionFollow standard patterns to increase the overall support baseThe automated authentication was one of the bugbears of…
  • 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.
  • 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.

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…

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….

Re-imagining our JavaScript SDK – moltin – Medium