Version 2 - What it means to you

Chris Roach profile picture Written by: Chris Roach - Published on: 04 Sep 2017
With version 2 up and running, we want to tell you exactly why it's better than version 1

It’s been a tremendous year at Moltin with more and more developers now using our APIs as the new way to build immersive commerce applications. We passed 12,000 stores on the platform, signed our first enterprise customers and continued to build out an amazing team. And, thanks to that growth, we’ve received excellent and very helpful feedback on how we could improve the APIs.

  • Speed: Consistent response times below a set goal. And a clear path to bring that down further over time.
  • Scalability: Better response times against simultaneous users.
  • Simplicity: Clear standards of data structures for end users.

We’re very excited that V2 delivers on all of these points and we’ve put together this post to help you understand exactly what has changed and to help you migrate.

How we measure

What follows are some simple graphs showing differences between Version 1 and Version 2 response times. These graphs were generated using k6 on current (updated 20th August 2017) builds on both Version 1 and Version 2 services of the API running on a local machine, with containerized storage.

To generate some of these metrics, we’ve taken responses from the following services:

  • Catalog
  • Carts
  • Orders
  • Checkout

Then grouped them to give an average overview of general response times for each version.

Speed

As developers, we’ve struggled for hours in the past getting our commerce software to respond in a timely manner. Our brains are filled with tips and tricks for Redis cache management in Magento, through to FPM configurations for PHP. So, in time-old fashion, our own systems ended up becoming the thing we worked so hard not to be… SLOW.

We set a very lofty goal some time ago of pushing the API speed to sub-150ms consistently. At a point in time, and under the right circumstances, it looked like we were achieving this. But, as more of our heroic users joined the Moltin army, and created more and more stores, and more and more awesome commerce applications, our API speed slowly but surely dropped, despite our best efforts to optimize.

This is something we’ve managed to fix in V2 however! Here is a simplistic overview of the speed for Version 1 vs Version 2:

Conclusions

  • Orders: Version 2 is up to 25x faster than its Version 1 counterpart.
  • Carts: This is one of the quickest services on Version 1, but Version 2 still comes in at around 2x quicker.
  • Catalog: Is one of the largest codebases in Version 1 and Version 2 but Version 2 still comes in 3.5x faster than Version 1.

Having a much faster response time for Catalog means your productscategoriesbrandscollections, and more, are resolved to your end users far faster, making a much better experience.

Now, Catalog response times are a no-brainer. But what many people forget is that the response times of carts and orders are ultimately far more important. The add to cart and checkout process with Moltin is super quick, meaning your users can get through the most important part of the buying experience without feeling held up.

Scalability

Concurrency is a measure of how many users can simultaneously access the API against the response times those users receive. The general rule is, the higher the concurrency, the higher the response times.

Concurrency of our API was probably the single biggest factor in the decision to rebuild various parts of our API.

In quiet times, Version 1 would tick along nicely. But any busy periods for multiple customers resulted in some serious degradation in the response times for our end users. We even had to begin limiting smaller stores quite heavily in order to allow some of our larger customers to retain some semblance of normality.

Here is a simplistic overview of the concurrency problem for Version 1:

We can see the contrast here for Version 2:

Conclusion

Note: This data is aggregated across multiple endpoints to give an average of the API.

  • Sub 500ms: Version 2 can handle between 3 and 6x the concurrency of Version 1.
  • Sub 1000ms: Version 2 can handle nearly 25x times the concurrency of Version 1.
  • When both versions reach 2000ms (which we internally consider degraded performance), Version 2 will have served between 40 and 70x the number of concurrent users that Version 1 will have.

What more is there to say?

Version 2 gives our ends users a faster more consistent experience, with the ability to scale better when they need it.

Simplicity

The last major issue we aimed to improve was Standardization.

Version 1 had some huge changes from Beta to its current incarnation to solve the inconsistent responses given to end users, but ultimately there were still improvements to be made to give a clear pattern for users.

An example is a Version 1 GET /currencies response:

  {
  "status":true,
  "result":
  {
    "code":"USD",
    "title":"United States Dollar",
    "enabled":"1",
    "format":"\\u0024{price}",
    "id":"104513657999720"
  }
}

The same currency response on a GET /cart/{cart_id} object differs:

  { .....
  "currency":
    {
"id":"104513657999720",
"code":"USD",
"format":"\\u0024{price}",
"decimal":".",
"thousand":",",
"rounding":null,
"exchange":0
    }
}

This was often a headache for our users, and could also cause lots of SDK issues.

The goal for Version 2 was to standardize the API responses as much as we possibly could. JSON API Spec was chosen as the base for our standardization.

Summary

Version 2 constitutes a huge improvement over Version 1 of our API for multiple reasons:

  • Speed: faster responses mean developers on Moltin can work far quicker than before and helps those building projects under bandwidth constrained circumstances, i.e. mobile networks.
  • Scale: increased throughput gives developers better scaling under heavy load, and means those end users don’t get held up for the all-important purchase.
  • Simplicity: better standardization means it’s easier to start with a single service and you’ll know what responses will look like generally on all other services.

With these major changes Moltin can ship our newest features to our users quicker, safer, and with better results than ever before and we can’t wait to see the results we get from all our users with our new and improved APIs.

With this solid base, we can confidently continue to improve on speed, stability and scalability into the future.

Build something amazing with Moltin