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
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.
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.
Spree’s bad parts • Product information modeling • EAV (Entity, Attribute, Value) • SQL anti-pattern • Due to control product information without database migration.
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
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
“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
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.
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.
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.
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.
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.