Software Engineer Intern Nathan Sesti writes about how Mayan is building a universal solution for Ecommerce's many markets.
It is no secret that when it comes to Ecommerce, Amazon dominates the space, making up 40.4% of total Ecommerce sales. However, the relevance of other marketplaces is not to be ignored. If a tool is to truly be a one-stop-shop and a universal solution for all an Ecommerce seller's needs (hint: this is where we're headed), then that tool absolutely must support as many marketplaces as possible.
So why then are there so many tools and yet none with complete support? The truth is that each marketplace comes with its own set of concepts, its own API (Application Programming Interface), and its own data, none of which is in a standard shape. Building the software to manage a new marketplace means learning all of these intricacies, understanding how they might match up with the other marketplaces, and implementing new UI and logic. Because of this, Amazon Sellers are stuck juggling an agglomeration of tools.
To solve this, we took the time to plan a foundation on which we could more quickly accommodate new markets. By adopting the JSON Schema standard and using it to auto-generate code, we've pushed what's possible with our tech stack and paved the way to expand our support to Walmart, Shopify, and beyond.
One of the most common applications of JSON Schema is OpenAPI, a standard for describing the mechanics of any REST API. Amazon offers such a specification, which we were first able to use to generate an SDK for the Amazon Advertising API and Selling Partner API (SP-API). This was a huge time save because we never have to spend time validating that we give the correct inputs to an API call; doing otherwise isn't possible thanks to strong typing with Typescript.
After we had generated an SDK, the new bottleneck became writing UI code. The parameters for an API call ultimately come from the end user, so for our Shipment Creation Automation, we had to build some kind of form to gather this data. Coding an HTML form by hand would have been time-consuming, error-prone, and inflexible, so instead we invested the time in building a robust form-generation engine. Simply passing in the JSON Schema that comes from the OpenAPI specification yields a form in the correct shape, complete with error validation, customizable rendering of fields, and even cooler: automated pre-population of any field, backed by our noSQL database, so users never have to fill in the same data twice.
If UI code could be generated, why not more? In order to attain end-to-end code generation we decided to build JSON Schema for our own data types. First, this entailed an OpenAPI Spec for our internal API, from which we could automate request validation on the backend and asynchronous state management using Redux to call our API from the client side.
All of this means that we can be confident in the shape of our data. Strong typing, validation, and a lack of hardcoding let us quickly acquire new data types without becoming mired in the details of their shape. All we care is that they are a subset of JSON.
To complete the end-to-end generation pipeline, we also converted our SQL schemas into JSON. In cases where we reference a table, for example a ‘users’ table, this lets us avoid relying on implicit knowledge of the shape of rows. In all cases, we aim to remove the need for the developer to concern themselves with data formats.
By leaning heavily on JSON Schema we do more than save time: with it as our source of truth, we can avoid the errors that would be so commonly made in repetitively rewriting code for the same purpose. We get to borrow the work done by the marketplaces we interact with, giving us flexibility upon API changes and the power to support new marketplaces. With our goal of offering a fully centralized tool suite, there was no choice but to build a cutting-edge tech stack.
Interested in exploring career opportunities at a fast-paced startup like Mayan? Reach out to us and learn more.