How I learned to stop worrying and use the Spree

Tokyo Rubyist Meetup 2014/05/14

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

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