An examination of ecommerce in Ruby on Rails as an engine as compared to traditional ecommerce frameworks.

1. Puppies & Ecommerce as
an Engine
Steph Skardal
All photos Copyright Steph Skardal

2. Outline
● Traditional
Monolithic
Ecommerce
● Ecommerce
as an Engine
● Rails Goodness
● Example Code
● Piggybak
● Cute puppies
I'm cute!

3. 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

4. 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?

5. 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 not
all bad.

6. How do we make things easier?
● Ecommerce as an Engine
But what does
that mean?

7. What are Rails Engines?
● Rails 3 introduced a major rewrite in
Engines, allowing mountability of mini-
applications.
Engine #1
Rails application Engine #2
Engine #3
● A Rails engine contains models, views,
controllers, modules, and routes that plug-in
to the main application

8. 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.

9. 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

10. 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

11. Variants Table
● variants table: with polymorphism
id item_id item_type qty ...
1 1 Book 10
2 1 CompactDisc 4
● Variant.find(1).item = Book.find(1)
● Variant.find(2).item = CompactDisc.find(1)

12. The "Guts"
class Book < ActiveRecord::Base
acts_as_variant
end
acts_as_variant does two things:
● has_one :variant, :as => "item", :class_name
=> "::Piggybak::Variant"
● accepts_nested_attributes_for :variant, :
allow_destroy => true

13. The "Guts"
class CompactDisc < ActiveRecord::Base
acts_as_variant
end

14. The "Guts"

15. Cart Form and Cart
● included as Rails partial view (include)
● passes variant id and quantity to cart

16. Line Item Structure
● Order has many line_items:
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
● 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

17. Photo Break
Stop! Tell me it's Almost Over!!

18. 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

19. Authorize.NET
class AuthorizeNet
KEYS = ["login", "password"]
KLASS = ::ActiveMerchant::Billing::AuthorizeNetGateway
end
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.

20. USPS Shipping
class 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
end
end

21. USPS Shipping

22. 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

23. Piggybak
● This "Ecommerce as an Engine" philosophy
is the foundation of Piggybak
ff on s!
o ti
ke mp
ha su
S s
a
se
tho

24. 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"
Engine #1
Rails application Piggybak
Engine #3

25. 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.

26. Questions?
/me eyes
glaze over