$30 off During Our Annual Pro Sale. View Details »

How I learned to stop worrying and use the Spree

How I learned to stop worrying and use the Spree

Tokyo Rubyist Meetup 2014/05/14

http://trbmeetup.doorkeeper.jp/events/10739

Kei Shiratsuchi

May 14, 2014
Tweet

More Decks by Kei Shiratsuchi

Other Decks in Technology

Transcript

  1. How I learned to stop worrying and use the Spree

    ࢲ͸೗Կʹͯ͠৺഑͢ΔͷΛࢭΊͯ
 4QSFFΛ࢖͏Α͏ʹͳ͔ͬͨ Tokyo Rubyist Meetup, 2014.05.14(Wed) ന౔ܛ, Shiratsuchi Kei, @kei_s
  2. Questionnaire A. Now using Spree. B. High probability to use

    Spree. C. May use spree. D. Seems unlikely to use Spree.
  3. Agenda 1. Why we use spree? 2. Spree’s structure 3.

    Spree’s good parts and bad parts 4. How to use Spree in OhMyGlasses 5. Difficult parts in real life 6. If I reinvent now
  4. We use Spree •Our own store, not hosting store. •Rails,

    not PHP framework. •Spree, not from scratch.
  5. Our own store •Not hosting store • like Shopify, Χϥʔϛʔγϣοϓ

    •Pros: Business scalability •Cons: Need development
  6. Our own store •We are engineers developing business value. •We

    choose building own store to control development.
  7. Rails • We need a familiar platform. • At least

    for me, it’s Ruby on Rails. • There are many knowledge about developing web app(not only building EC site). • Testing, deploying, better coding.
  8. Spree • First time to develop an E-Commerce service. •

    We need to build well structured cart/payment features. • Open source. We can read the codes. • I could rely on official documents only for partial to extend Spree codes.
  9. Spree’s structure Rails spree_core Ver 2.3.0 spree_api spree_frontend spree_
 auth_devise

    spree_cmd Ruby spree_backend Optional Kaminari Paperclip ActiveMerchant Devise Cancan RSpec FactoryGirl
  10. spree_backend • Order control: canceling order, shipping units • Product

    control: editing product’s info, image, stock • Site configuration interface: • Configuring payment method, Tax rate, promotion(Coupon)
  11. Spree’s design concept •Configure without development. •By business owner, site

    admin. •Customize with development. •By developer.
  12. Spree's good parts • Well structured cart/payment. • Statuses of

    payment, shipment. • Extensible price adjustments. • Tax, shipping cost, discount.
  13. Statuses of payment, shipment Order Payment 1 1 Shipment 1

    1 • Order has (at least) one payment and shipment objects. • Payment conducts paying affairs: amount, payment method(e.g. credit card) and paying status. • Shipment conducts shipping affairs: shipping address, tracking number, and shipping status.
  14. Statuses of payment, shipment Payment statuses Shipment statuses • Ship

    after paid. • When payment goes “Completed”, shipment goes to “Ready”.
  15. Order line_items 1 * adjustments 1 * Product A :

    Product B : 20000 JPY 23000 JPY Shipping : Coupon : Tax : Item total : 43000 JPY 500 JPY -3000 JPY (included) 0 JPY Total : 40500 JPY { { Extensible price adjustments
  16. Order line_items 1 * Product A : Product B :

    20000 JPY 23000 JPY Shipping : Coupon : Tax : Lens : Item total : 43000 JPY 500 JPY -3000 JPY (included) 0 JPY 1500 JPY Total : 42000 JPY adjustments 1 * { { Lens adjustment Extensible price adjustments
  17. Spree’s bad parts • Product information modeling • EAV (Entity,

    Attribute, Value) • SQL anti-pattern • Due to control product information without database migration.
  18. Product information modeling Property 1 * ProductProperty 1 * id

    product name 1 Glass1 2 Glass2 id property name 1 lens_width 2 material Product
  19. Product information modeling id product_id property_id value 1 1 1

    52 2 1 2 metal 3 2 1 49 4 2 2 cellulose • “value” column must be string to store various data. • Can’t validate value on database. Property 1 * ProductProperty 1 * id product name 1 Glass1 2 Glass2 id property name 1 lens_width 2 material Product
  20. How to use Spree in OhMyGlasses • Customize aggressively. •

    Two customizing example: • Treat lens in ordering eyeglasses. • “Home-try” feature.
  21. Treat lens in ordering eyeglasses •Added “lens data” to order.

    •Order has_many LineItems. • LineItems = each items in cart. •LineItem has_one LensData.
  22. Treat lens in ordering eyeglasses • When extending class, Spree

    recommend to • name file with “_decorator.rb”, • use `.class_eval` to inject logic. Spree::LineItem.class_eval do! has_one :lens_data, dependent: :destroy! ...! end app/models/spree/line_item_decorator.rb
  23. “Home-try” feature • Spree::HometryOrder inherits Spree::Order. • Change order number

    rule. • And various tangled logics. class Spree::HometryOrder < Spree::Order! # OVERRIDE! def generate_order_number! ...! end! end
  24. Difficult parts in real life (1) • Developing promotion(coupon). •

    There seems to be various requirements by your own business. • Promotion modeling on Spree is well structured but still complicated.
  25. Difficult parts in real life (2) • Testing • It’s

    difficult to setup statuses of order, payment and shipment in specified situation. • Some statuses get tangled up as indicated above.
  26. Difficult parts in real life (3) • Upgrading Spree •

    When it has changes around business core, they’ll be annoyances. • Order, payment, product’s stock. • Upgrading Rails requires upgrading Spree. • Be sensitive to upgrading Spree.
  27. If I reinvent now •Use Spree as needed, •Not entire

    feature. •In spree_core, frontend, backend
  28. If I reinvent now • In spree_core, • Still use

    models around order. • Order, payment, shipment and so on. • Build own structure to store product info. • It would be better performance and robustness than Spree’s.
  29. If I reinvent now • In frontend, • Still use

    controllers around cart and paying. • They are closely related to order models. • Building own controllers about products or so on. • If necessary, use spree_api to separate apps.
  30. If I reinvent now • In backend, • Still use

    entire backend system. • It has coordinated views about order. • And extend own views as needed.