-
1.
Powered by
-
2.
Me llamo Miguel
I do this
-
3.
My Team
-
4.
“Mermaid Tucker”
-
5.
#OpenCommerce
mtucker@godaddy.com
@mtazva
-
6.
Online Store
The Pit of Success
-
7.
Why Spree?
● Easily Customizable
● Fully Featured
● Existing API
● Highly Extensible
● Great Community!
-
8.
by developers
for developers
-
9.
Simplifying the Experience
● Grid-based options building
● Simple customization via themes engine
● Automatic PayPal activation
● Automatic domain management
● Automatic SSL management
● Automatic label printing
● Hiding the dirty details
-
10.
Magnifying the Impact
● Automatic email marketing integration
● Simple and automatic Facebook store
● One-click product reviews engine
-
11.
SaaS-ification
● Multi-tenancy
● Themes engine
● Internal integrations (single sign-on, domains, others)
● GoDaddy branding
-
12.
We are
the 1%
-
13.
Making the Sale
Get Published
-
14.
Making the Sale
Get Social!
-
15.
Scaling Spree - Tech Stack
● CentOS 6
● Ruby 2.2
● Ceph (internal cloud storage)
● Github / GHE
● Jenkins for CI/CD
● Puppet
● Hadoop
● StatsD and Graphite
● NewRelic
● SumoLogic
● Honeybadger
● Apache Traffic Server 5.3
● HAProxy 1.5
● Apache 2.2
● Unicorn 4.9
● Rails 4.1 [https://github.com/spree/spree/pull/7192]
● Spree 2.2
● Bootstrap 3
● React 0.14
● Delayed Job
● Memcached
● MySql 5.5
● Akamai CDN
-
16.
Scaling Spree - Architecture
A10
CommonDB
API
(4)
App
(6)
MerchantDB
ATS
HAProxy
ATS
HAProxy
ATS
HAProxy
ATS
HAProxy
SSL Termination
Redundancy
Horizontal Scaling
Context-specific data
Global metadata
Job
(4)
Memcached
(4)
-
17.
Scaling Spree - Performance
● 10s of thousands of unique live storefronts
● ~1.5M page views per day
● Average page response time ~2.5s
● Average server response ~300ms
● Capable of ~400rps per app server before performance degrades
● >99.99% uptime
-
18.
The ActiveRecord Callbacks Problem
● Obscure business logic. Explicit => Implicit
● Often have unintended side effects
● Require deep understanding of AR internals
● Can cause a chain reaction performance nightmare
-
19.
that!
-
20.
The AR Callbacks Problem
Option Type Product
Taxonomy
Taxon
Option Value
1:1 1:M
1:M
1:M
Variant
1:M
1:1
parent
Variant
Product
Taxonomy
Taxon
belongs_to :option_type,touch: true
after_touch :touch_all_variants
after_touch :touch_all_products
belongs_to :product, touch: true
after_save :run_touch_callbacks
after_touch :touch_taxons after_touch :touch_parent
-
21.
Yo Dawg
I heard you like ActiveRecord Callbacks
So I added a callback that will call you back
When your callback calls my callback
-
22.
The AR Callbacks Problem
A Stop Gap Solution
https://github.com/godaddy/activerecord-delay_touching
ActiveRecord::Base.delay_touching do
# touch_all_the_things
end
-
23.
The AR Callbacks Problem
What do we do?
Be more explicit with Service Objects
OptionValueUpdater.new(option_value).call
● Explicit, clear business logic
● No hidden side effects
● No magic to understand
● Aggregation of bulk updates
-
24.
My time with Rails is up (Piotr Solnica)
http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html
“People are attracted by Rails because it gives you a false sense of
simplicity, whereas what really happens is that complexity is being hidden
by convenient interfaces. [...] ActiveRecord is just one, representative
example, [...].”
All Things in Moderation
Rails has won: The Elephant in the Room (Fabio Akita)
http://www.akitaonrails.com/2016/05/23/rails-has-won-the-elephant-in-the-room
“[…] for all intents and purposes, Active Record still does much better than
average. But if you're big, you should be careful. That's all.”
-
25.
Spree Wish List
Improve Order Consistency
● Do not trigger order recalculation once complete (or at least be more explicit)
○ Some operations can cause completed orders to be recalculated
● Snapshot product details on orders
○ Modifying product information is reflected in completed orders
-
26.
Spree Wish List
Maintain Clear Upgrade Paths
● Semantic versioning
● Non-breaking data migrations
● Upgrades without downtime
-
27.
Spree Wish List
Preview/Publish Mechanism
● Allow site changes to be staged and viewed before making live
-
28.
Spree Wish List
Simplify Customization
● Better hooks for overriding flows and replacing features
○ Dependency Injection
○ Configurable Service Locators
○ Integration Hooks in Service Objects
-
29.
Spree Wish List
Support Automated Integrations
● First class application marketplace
○ Engine to plugin extensions without development work
○ Oauth-based activation and requirements-based authorization
■ Generates unique, role-based api users
Spree :)
-
30.
Spree Wish List
Keep on Being You!!
● Retain a helpful and collaborative community
● Share and learn from each other
-
31.
mtucker@godaddy.com
At GoDaddy
we're pulling for small business.
Help us transform the global economy, one entrepreneur at a time.
-
32.
@mtazva
mtucker@godaddy.com
You probably don’t know godaddy
More than domains and flashy commercials
Small business advocate
Shift the world to small business advantage
My Team
My team thinks this is me.
This is how I often perceive myself.
The truth is, this is what I probably most often look like at work.
Online Store has a single goal: simplicity
Setup and sell with no technology or ecommerce skills
We surveyed many OS projects and chose spree for our future
DISCLAIMER: covering Spree 2.0 - 2.2
Out of the box, there were some challenges in fulfilling simplicity goals
Removed most of Spree and reintroduced with care
Hid the “dirty details”
Provide tools to strengthen the power of the individual
Necessary evils of a Service-based platform
First challenge: GET LIVE
Our median publish rate is 25 hours
Social, mixed with discounts, is THE differentiator
Facebook likes and instagram, as well as telling story on Reddit (hug of death, 10x)
Quick look at our stack.
NOTABLE: Spree 2.2 on Rails 4.1
PR for this, you will need to upgrade your extensions
Happy to discuss anything in this stack
Build for full horizontal scalability
High volume SSL termination
Multi-tenancy: sharding by account
Rails and Spree CAN scale
Uptime is HUGELY important
Performance problems: AR Callbacks
See what others have to say
Demo: focus on TOUCH operations only
Run through the delay_touch example.
Shows that a set of 500 products can generate over 7k update statements by simply touching a single option value
Wrapping in delay_touch reduces this to 6; the number of discrete models involved in the relational tree
Library is freely available on GD public github
This is a temporary solution!
Service objects can handle the previously noted issues
Great, timely discussion in the community!
Order calculation and snapshot issues
Backward Compatibility
Uptime!!
BIG/COMPLEX Ask: Staged changes to store
First class, well designed customization hooks
Third party ecosystem
Retain the community that brought us here!!
WE ARE HIRING - please connect with me