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
2. @kei_s •ന౔
   ܛ Shiratsuchi Kei •Web app engineer •http://github.com/kei-s
3. •Thank you for coming!!
4. Questionnaire A. Now using Spree. B. High probability to use Spree. C. May use spree. D. Seems unlikely to use Spree.
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
7. OhMyGlasses http://www.ohmyglasses.jp
8. OhMyGlasses •E-commerce site selling eyeglasses and sunglasses. •Built w/ Ruby on Rails, Spree.
9. OhMyGlasses •Public release in January 2012. •Containing 15,000+ products. •5 Engineers+.
10. We use Spree •Our own store, not hosting store. •Rails, not PHP framework. •Spree, not from scratch.
11. Our own store •Not hosting store • like Shopify, Χϥʔϛʔγϣοϓ •Pros: Business scalability •Cons: Need development
12. Our own store •We are engineers developing business value. •We choose building own store to control development.
13. Rails •Not PHP •There are some well-made EC softwares written by PHP. •Magento, EC-Cube
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.
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.
17. Spree E Commerce Platform Ruby On Rails 100% Open Source
21. Spree’s structure Rails spree_core Ver 2.3.0 spree_api spree_frontend spree_
 auth_devise spree_cmd Ruby spree_backend Optional
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
23. spree_core •The basic models of Spree. •Products •Orders, payments, shipments •Users
24. spree_frontend •Shop interface • Product page, its index page • Checkout controller • Payment views
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)
26. Spree’s design concept •Configure without development. •By business owner, site admin. •Customize with development. •By developer.
27. Spree's good parts • Well structured cart/payment. • Statuses of payment, shipment. • Extensible price adjustments. • Tax, shipping cost, discount.
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.
29. Statuses of payment, shipment Payment statuses Shipment statuses • Ship after paid. • When payment goes “Completed”, shipment goes to “Ready”.
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
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
32. Spree’s bad parts • Product information modeling • EAV (Entity, Attribute, Value) • SQL anti-pattern • Due to control product information without database migration.
33. Product information modeling Property 1 * ProductProperty 1 * id product name 1 Glass1 2 Glass2 id property name 1 lens_width 2 material Product
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
35. How to use Spree in OhMyGlasses • Customize aggressively. • Two customizing example: • Treat lens in ordering eyeglasses. • “Home-try” feature.
36. Treat lens in ordering eyeglasses •Added “lens data” to order. •Order has_many LineItems. • LineItems = each items in cart. •LineItem has_one LensData.
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
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
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.
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.
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.
42. If I reinvent now •Use Spree as needed, •Not entire feature. •In spree_core, frontend, backend
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.
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.
45. If I reinvent now • In backend, • Still use entire backend system. • It has coordinated views about order. • And extend own views as needed.
46. And, We are hiring: Engineer, Designer
 http://tech.ohmyglasses.jp/
 https://www.wantedly.com/projects/545 Thank you!