Shopify is a Software as a Service (SaaS) e-commerce platform built to meet the needs of the typical storeowner. It offers hosting, shopping cart, payment processing, order management, product catalogs, blogging, and much more. A storeowner can sign up for Shopify, pick out a design, create a product catalog, set up a payment gateway, and make a sale on the same day—all without any programming or technical expertise.
Shopify gives you the ability to completely modify the HTML, CSS, and JavaScript of the storefront theme. Designers are able to add features such as visual effects, responsive designs, bundled products, shipping estimators, and social plugins that can accomplish almost everything that is expected of a modern e-commerce site.
For features such as inventory management, accounting, drop shipping, mailing lists, and, reporting, an application that communicates with Shopify's API and/or handles Shopify's XML notifications (called webhooks) is needed. In this book, we'll focus on building such an app. You should have an understanding of web development using a server-side language such as Ruby, PHP, or ASP.NET. Basic HTML, CSS, and JavaScript skills are also required because we'll be building a simple UI. Finally, familiarity with Shopify's features will be extremely helpful. If you've not used Shopify before, I encourage you to go through this excellent primer on the Shopify blog at http://www.shopify.com/technology/3671962-developing-shopify-apps-part-1-the-setup.
Throughout the course of this book, we will be building a web application that allows the storeowners to run contests by randomly picking a customer who has placed an order in the shop. Our app will be built using Ruby on Rails (http://rubyonrails.org), which is an open source web development framework that is relatively simple to learn. It is the same language that Shopify has been written in. A few popular Ruby libraries (for example, Active Merchant and Liquid) are extractions of the Shopify source code that have been released as open source. Rails is based on the Model-View-Controller (MVC) enterprise architecture pattern, so if you aren't familiar with this paradigm, I encourage you to head over to Wikipedia for a general overview (http://en.wikipedia.org/wiki/Model–view–controller).
This chapter will cover the following topics:
An overview of the Shopify platform
App development options
The Shopify API
The Shopify Webhook system
Tips on how to get started
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
You have a client Shopify store that needs additional functionality
You have already determined that what they need is not included in the Shopify out of the box
You've looked through the App Store and determined that there isn't an app that meets their needs
They aren't interested in reselling the idea to other storeowners, or they don't want competitors to have this functionality
Note
What you are looking to build is a private app. This is an app that is not listed in the official App Store and typically only connects to a single Shopify account.
Scenario 2
You or your client have a great idea for an app
Other storeowners would benefit from the app and may even pay money to use it
You've already checked the App Store and determined that the app doesn't already exist, or that it exists but you think you can improve the idea
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:
Application charge
Product
Order
Webhook
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.
Order webhooks allow apps to respond in a near real-time fashion when an order is placed or updated in the Shopify store. The following two events are the most commonly subscribed topics that deal with the creation and payment of an Order:
orders/create
orders/paid
Product webhooks can be handy for apps that handle inventory, product feeds, or back office integrations. The following three events are of interest when dealing with Products:
products/create
products/update
products/delete
It will be helpful to automatically reflect any updates to a shop's name, URL, and so on in your app. Likewise, it's polite to suspend/cancel a user's account if they uninstall the app from their store. The following two events allow us to do that:
shop/update
app/uninstall
Webhooks are sent asynchronously after the event occurs. This makes them suitable for near real-time actions and allows an application to process information in smaller chunks, which can reduce the load and improve performance.
Tip
I also recommend using the API to retrieve information as a backup in case the webhook system gets bogged down or a notification is missed.
For public applications, the webhook for uninstalling the application should be subscribed to so that you can automatically suspend the client's account when they remove your app from their Shopify store.
If you've decided that you need to build an app, then the next step is to ask yourself the following questions:
What exactly does the app need to do?
Will the app be private or public?
Who will be developing the app?
Who will be designing the UI?
What is the budget and timeline?
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.