Shopify Application Development: Build highly effective Shopify apps using the powerful Ruby on Rails framework

Shopify offers a comprehensive e-commerce solution designed to meet the needs of a typical storeowner who wants to sell products online. The theme gallery, extensive wiki, and active forum provide an excellent end-to-end experience even for the most inexperienced computer user. For customers who need more personalized support, there is the Shopify Experts directory, which is a great place to find a designer, programmer, or setup expert.

Two features, the robust API (http://docs.shopify.com/api) and the App Store (http://apps.shopify.com), put Shopify ahead of the curve compared to its competitors. Rather than trying to include every imaginable feature for every possible line of business, Shopify focuses on the common needs of every storeowner and leaves the rest to the theme customization and apps.

A third feature called webhooks (http://docs.shopify.com/api/webhook) allows apps to receive near real-time notifications of events that take place in a shop. These events range from order creation, product updates, customer signup, to account cancellation. The notifications come in both XML and JSON formats and typical mirror the schema of the API which makes integration a breeze.

When it comes to building an app for Shopify, there are two options: private and public. Private applications are designed to access one Shopify store, and can be changed as per the needs of the storeowner by the developer. Public applications are designed to access multiple Shopify stores, and provide functionality that will be used by different types of businesses. They can act as a revenue stream for the developer by charging storeowners a monthly fee.

Both private and public apps perform operations by using the Shopify API and/or by processing Shopify Webhooks. At a high level, a public application can be thought of as a private application that was expanded to work with multiple stores.

To determine which one you need to build, take a look at the following scenarios:

Scenario 1

Scenario 2

Shopify offers an extensive API that allows developers to perform almost any task that can be done via the web admin (and a few that don't like working with Metafields). The full documentation is available at http://api.shopify.com.

The API is RESTful and supports HTTP, JSON, and XML requests. There are several free software libraries available for most of the popular web development languages to help people get started. The libraries are actively supported either by Shopify or the open source community.

In this book, we will only be scratching the surface of the API by focusing on the areas of order retrieval, product management, and application charges. The API allows you to do much more—from modifying the store's themes, setting up shipping charges, to retrieving information about abandoned carts in order to follow up with the shopper.

We'll be working with the following API verticals:

Shopify allows applications to subscribe to a series of notifications called webhooks (http://docs.shopify.com/api/webhook) around common events such as order placement, product updates, and customer signup. Real-world events are mapped to topics that can be subscribed to via the API or by manual setup in the Shopify admin panel. The webhook notification mirrors the format of the API, which makes the implementation code reusable. When an event occurs, Shopify automatically sends the notification to all subscribers.

If you've decided that you need to build an app, then the next step is to ask yourself the following questions:

Once you've answered these questions, you should have a rough idea of the big pieces involved in creating the app. The set of features required to build a software is often referred to as the scope.

Determining an application's scope even at a high level is a skill that requires practice. This typically starts as a document that lists the overall purpose, feature list, integration points with Shopify (if known), dependencies on external services or software libraries, proprietary business logic, architectural decisions (language, platform, server requirements, and so on), budget, timeframe, and anything else that will impact the application life cycle.

Creating in-depth specs is beyond the scope of this book, though in general more information at this phase is better (it's easier to trim features and defer them at a later phase as development progresses rather than trying to cram in new ones that were forgotten in the beginning).

At the very least, a list of must-have features is necessary. Even if you are doing the development yourself and the feature set is small, it's a good skill to learn and will often reveal aspects and features that weren't originally planned. This is the technique we'll be using throughout this book. We are going to list out the high-level features that we want to build and turn each one into a sprint. A sprint is an agile methodology term that denotes a discrete amount of work. Usually, a sprint lasts for two weeks or less. In our case, each sprint will last only a few hours because our feature set is simple.

For a larger app, the simplest way to start is to list out all the features, prioritize them, and then set a cutoff based on time and budget. Even if it never progresses beyond a simple list, you'll have something to measure progress against while the app is being developed. Without this list, all the features (complete and pending) will only be in your head.

An analogy for this would be going to the grocery store without a list. Chances are, most of the things you need will end up in the cart, but undoubtedly, you'll either forget a few things (feature deficiency), spend excess time roaming the aisles trying to remember what you need by seeing something you forgot on the shelf (inefficient development/refactoring), or add things that aren't on the list (scope creep). The worst situation to be in is to have all the ingredients to make lunch tomorrow but be unable to make dinner tonight because you forgot something important!

In this chapter, we looked at some of the features available in Shopify as well as the difference between private and public applications. Then we briefly discussed the Shopify API and webhook system before finishing up with some thoughts on software development and how to get started planning your own app for fun and profit.

During the course of this book, we will be developing a simple app that will allow storeowners to run contests. The app will pick a winner from the list of customers who have made a purchase at the store within a certain timeframe or for a certain product.

The next chapter will cover setting up your local development environment, installing Ruby on Rails, creating a basic app, and deploying it to Heroku (http://www.heroku.com) for cloud hosting. This application will be iteratively expanded in each chapter as we progress towards our goal of publishing it in the Shopify App Store.