Puppies & Ecommerce as an Engine

Steph Skardal

All photos Copyright Steph Skardal

Outline

● Traditional MonolithicEcommerce

● Ecommerceas an Engine

● Rails Goodness● Example Code● Piggybak● Cute puppies

I'm cute!

TME: Traditional Monolithic Ecommerce:

Assumptions made:● shopping cart & checkout● products, product attributes● product navigation● product features: cross-sell, upsell, reviews● admin: various features● access control: admin, users

Problems with TME:● Heavy on assumptions can make it difficult

to customize● Add-on features are not always maintained● Heavily dependent on direction of platform

Feeling Trapped?

TME Positives:● Can get a site up and running quickly● For a simple site with minimal customization,

assumptions made by TME may be acceptable

It's notall bad.

How do we make things easier?● Ecommerce as an Engine

But what doesthat mean?

What are Rails Engines?● Rails 3 introduced a major rewrite in

Engines, allowing mountability of mini-applications.

● A Rails engine contains models, views, controllers, modules, and routes that plug-in to the main application

Rails application

Engine #1

Engine #2

Engine #3

Why is Rails a good fit?● And Rails also now has some powerful

Admin tools (RailsAdmin, ActiveAdmin) comparable to Django's core.

● Generally, Rails is a good framework to be doing efficient development on (as are other MVC frameworks). "Mountability" may be a trickier thing to accomplish in Perl, but may be possible in catalyst.

Ecommerce as an Engine● Assumptions of shopping cart and checkout● Items are added to the cart, which contain a

quantity, description, subtotal● Standard order and line item data model

No Product Model

There is no product model. This is important. Why is there no product model?● mountability: turn existing models into products● TMEs tend to overengineer and bloat

assumptions built around the product model● In custom sites, products tend to be piled on

with custom attributes that don't apply to all products, adding cruft

Variants Table

● variants table: with polymorphism

● Variant.find(1).item = Book.find(1)● Variant.find(2).item = CompactDisc.find(1)

id item_id item_type qty ...1 1 Book 102 1 CompactDisc 4

The "Guts"

class Book < ActiveRecord::Base acts_as_variantend

acts_as_variant does two things:● has_one :variant, :as => "item", :class_name

=> "::Piggybak::Variant"● accepts_nested_attributes_for :variant, :

allow_destroy => true

The "Guts"

class CompactDisc < ActiveRecord::Base acts_as_variantend

The "Guts"

Cart Form and Cart● included as Rails partial view (include)

● passes variant id and quantity to cart

Line Item Structure● Order has many line_items:

● Line item copies description and price at the time order is created to preserve product information at the time of purchase

● Cart and order logic exercises inventory management if specified per variant

id qty variant_id description price total

1 1 1 Book Title 3.00 3.00

2 2 2 CD Title 3.00 6.00

Photo Break

Stop! Tell me it's Almost Over!!

Checkout

● Checkout doesn't care what item types are in the cart

● Shipping, Tax, and Payments have common APIs for calculating to cover cost of line items

Authorize.NETclass AuthorizeNet KEYS = ["login", "password"] KLASS = ::ActiveMerchant::Billing::AuthorizeNetGatewayend

ActiveMerchant: A popular open-source gem released by Shopify.com that includes Payment gateway support for 40+ popular payment gateways.

Integration: Payment method directly integrates with ActiveMerchant, but specifies required payment gateway key value pairs that are stored in a table that maps to payment method.

USPS Shippingclass Usps Shipping KEYS = ["login", "password", "service_name"] def self.request_rates(method, order) #returns rate end def self.available?(method, order) #returns boolean end def self.rate(method, order) #returns rate for order endend

USPS Shipping

What does this all mean?

● No assumptions made on:○ product attributes, features○ taxonomy○ access control

● Works for:○ highly customized sites in need of flexibility○ sites with multiple product types, where the

data model of the product types varies● Doesn't work for:

○ any sites that can evaluate the assumptions of TME to be more valuable than custom development

Piggybak● This "Ecommerce as an Engine" philosophy

is the foundation of Piggybak

Shake off

those assumptions!

Phunk says:

phunk: I might hit this high level idea a little harder: "rails engines are pluggable modules of functionality, and Piggybak is an engine, so that allows someone to plug this in and easily add the ecommerce part"

Rails application

Engine #1

Piggybak

Engine #3

The Future

● More Piggybak work:○ testing○ implementation for more clients○ line items rearchitecture (?)

■ treat everything as a line item■ challenge with this is the admin interface

○ support for ActiveAdmin (?)○ keep up with Rails "trends"

● Continue growing the Piggybak baby with testing, client implementation, minimal features.

Questions?

/me eyesglaze over