Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

    View Slide

  2. @kei_s
    •ന౔ܛ Shiratsuchi Kei
    •Web app engineer
    •http://github.com/kei-s

    View Slide

  3. •Thank you for coming!!

    View Slide

  4. Questionnaire
    A. Now using Spree.
    B. High probability to use Spree.
    C. May use spree.
    D. Seems unlikely to use Spree.

    View Slide

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

    View Slide

  6. View Slide

  7. OhMyGlasses
    http://www.ohmyglasses.jp

    View Slide

  8. OhMyGlasses
    •E-commerce site selling
    eyeglasses and sunglasses.
    •Built w/ Ruby on Rails, Spree.

    View Slide

  9. OhMyGlasses
    •Public release in January 2012.
    •Containing 15,000+ products.
    •5 Engineers+.

    View Slide

  10. We use Spree
    •Our own store, not hosting store.
    •Rails, not PHP framework.
    •Spree, not from scratch.

    View Slide

  11. Our own store
    •Not hosting store
    • like Shopify, Χϥʔϛʔγϣοϓ
    •Pros: Business scalability
    •Cons: Need development

    View Slide

  12. Our own store
    •We are engineers developing
    business value.
    •We choose building own store to
    control development.

    View Slide

  13. Rails
    •Not PHP
    •There are some well-made EC
    softwares written by PHP.
    •Magento, EC-Cube

    View Slide

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

    View Slide

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

    View Slide

  16. View Slide

  17. Spree E Commerce Platform
    Ruby On Rails
    100% Open Source

    View Slide

  18. View Slide

  19. View Slide

  20. View Slide

  21. Spree’s structure
    Rails
    spree_core
    Ver 2.3.0
    spree_api spree_frontend spree_

    auth_devise
    spree_cmd
    Ruby
    spree_backend
    Optional

    View Slide

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

    View Slide

  23. spree_core
    •The basic models of Spree.
    •Products
    •Orders, payments, shipments
    •Users

    View Slide

  24. spree_frontend
    •Shop interface
    • Product page, its index page
    • Checkout controller
    • Payment views

    View Slide

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

    View Slide

  26. Spree’s design concept
    •Configure without development.
    •By business owner, site admin.
    •Customize with development.
    •By developer.

    View Slide

  27. Spree's good parts
    • Well structured cart/payment.
    • Statuses of payment, shipment.
    • Extensible price adjustments.
    • Tax, shipping cost, discount.

    View Slide

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

    View Slide

  29. Statuses of payment, shipment
    Payment statuses
    Shipment statuses
    • Ship after paid.
    • When payment
    goes “Completed”,
    shipment goes to
    “Ready”.

    View Slide

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

    View Slide

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

    View Slide

  32. Spree’s bad parts
    • Product information modeling
    • EAV (Entity, Attribute, Value)
    • SQL anti-pattern
    • Due to control product information
    without database migration.

    View Slide

  33. Product information modeling
    Property
    1
    *
    ProductProperty
    1
    *
    id product name
    1 Glass1
    2 Glass2
    id property name
    1 lens_width
    2 material
    Product

    View Slide

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

    View Slide

  35. How to use Spree in OhMyGlasses
    • Customize aggressively.
    • Two customizing example:
    • Treat lens in ordering eyeglasses.
    • “Home-try” feature.

    View Slide

  36. Treat lens in ordering eyeglasses
    •Added “lens data” to order.
    •Order has_many LineItems.
    • LineItems = each items in cart.
    •LineItem has_one LensData.

    View Slide

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

    View Slide

  38. “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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  42. If I reinvent now
    •Use Spree as needed,
    •Not entire feature.
    •In spree_core, frontend, backend

    View Slide

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

    View Slide

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

    View Slide

  45. If I reinvent now
    • In backend,
    • Still use entire backend system.
    • It has coordinated views about order.
    • And extend own views as needed.

    View Slide

  46. And, We are hiring:
    Engineer, Designer

    http://tech.ohmyglasses.jp/

    https://www.wantedly.com/projects/545
    Thank you!

    View Slide