Projects at AmeriCommerce
Before 2013, if merchants or third parties wanted a deeper level of integration with Spark Online Store, they had to use the platform’s SOAP API. There were a number of problems with the SOAP API: it was slow, clunky, and hard to use outside of the .NET ecosystem.
I was responsible for designing and developing a new, modern API from the ground up. It supports many of the features common to modern RESTful APIs: security scopes, field selection, on-demand collections, paged results, and OAuth authentication. In addition, to give our partners and merchants flexibility, I built out a robust query syntax framework. This allows any field returned over the API to also be used for filtering based on some criteria; i.e.
/api/v1/products?price=gt:30 returns all products with price greater than $30.
The API has seen some additional enhancements over time. A third-party wanting to integrate with many merchants can sign up as an integration partner and publish their application to a central repository, which allows that application to be installed on any Online Store account. Webhook subscriptions are available that allow the client application to specify a URL that will receive a request when a designated event is triggered.
The API was built using ASP.NET Web API, C#, and Microsoft SQL Server.
The server side components of the API were built on ASP.NET, C#, and Microsoft SQL Server.
The remote carting system allowed sites or static pages not hosted on the AmeriCommerce platform to interact with the shopping cart on a storefront. Not only did I greatly expand upon the functionality of this existing system, but I also heavily refactored it from a single, complicated ASPX page into a set of handlers that could be tested in isolation and had a clearly identifiable purpose.
I had the opportunity to work on several third-party integrations during my time with AmeriCommerce:
- Facebook Social Store - allows a storefront to be embedded on a Facebook page
- Facebook Social Login - allows the customers of a storefront to log in with their Facebook account
- PayPal Express Checkout - originally an alternative for the "click a button to go to PayPal" flow, this is now commonplace on sites that accept PayPal payments
- Google Checkout (discontinued) - Google’s attempt at a PayPal competitor
- Google Trusted Stores (discontinued) - an ecommerce certification introduced by Google to indicate that the merchant was a fast and reliable shipper with good quality and service
Admin Console Refresh (2011)
A large and complicated project and very much a team effort. My role started early on in the project, building out prototypes from designs given to me and laying much of the infrastructure that would later be built on top of. Some of the notable pieces I built as part of this project are listed below:
- The overlay system, a key component of the entire admin console that allows "detail" screens to be displayed over their parent page, allowing the parent page to be easily returned to
- The store picker, a piece of the admin console that allowed merchants with multiple stores to switch between them on editor screens
- A streamlined way to report notifications (success, warning, error, etc) to users
- A customizable admin dashboard, with widgets that could be customized or dragged to reposition
- A tracker for background processes that displayed a progress bar and updated at regular intervals
Themes v2 Admin Experience
When we set out to provide a new theme experience for our merchants, we knew it would need a more robust user experience in the admin console as well. I built out the majority of the v2 theme admin experience, including draggable widgets as well as embedded HTML and CSS editors.
The scheduled export system allowed merchants to set up a job that would automatically export data on a recurring interval, and optionally upload it to a destination FTP server. My work not only involved implementing this system, but refactoring the existing export code and making it more modular and centralized so it could easily be used by the scheduling system. This work was done with ASP.NET, C#, and Microsoft SQL Server.
Analytical data about incoming traffic was being set by a few hardcoded conditions in early request processing, and that was pretty much the extent of it. My task for this project was to build a customizable rule engine that could evaluate incoming web traffic based on a set of conditions and then take one or more actions based on the result. This system was later adapted to work on more types of data, including customers and orders, and respond to a wider variety of events.
Automated Testing & Continuous Integration
The build and deploy process for code was manual, and I knew we could do better. I introduced a unit test library for our project and wrote some of the first tests that would actually get run on every build. I also set up JetBrains TeamCity as our CI server and wrote our first CI scripts in Ruby using Rake. This enabled us to do automatic code builds when code was committed, and the deployment artifacts were placed on a staging server. While the actual deploy to production was still a manual process, this cut the time those deploys took drastically, and we knew almost immediately when an error occured instead of waiting for someone to run the build.
I was responsible for building out a system that merchants could use to customize their data. This system originally allowed for additional fields to be added to customer, order, and product data. These fields would appear in all of the relevant editors across the admin console, and in imports and exports. Built using ASP.NET, C#, and Microsoft SQL Server.