Spree e-commerce on budgethoster Site5

Recently I rolled out a
Ruby-on-Rails/Spree-based webshop on the
budgethoster Site5. I thought to share some gotcha's, reasoning
around this project. To debunk the idea that hosting for Rails is either
complex and hard, or done on Heroku. To explain a bit about Spree as a
good option for your e-commerce (or not) and to go a little into how I modified
Spree.

Reasons for choosing for Spree

I decided to go for Spree, after some investigation. A few important
reasons where:

It's catchphrase It was designed to make customization and upgrades
as simple as possible.

It is built in Ruby on Rails, and that is what I do. (Although I
probably know more about PHP, and Drupal, at that).

We wanted a simple shop. Her needs are mostly simplicity; less
features in the shop equals better. Spree promises that; as opposed to
most ready-to-go shopping tools, that promise every feature you may
wish. And get in your way.

We needed flexibility. Simple means that it offers less options and
choices. But also that the business-logic needs to handle more.

I wanted the site to be ready for mobile and thus to be responsive. Rails is ready for this. HTML5 and all that. So is Spree.

Some reasons why I had thoughts about either writing my own e-commerce or
going with a PHP-solution were:

I had (and have, read on) my questions about how true the catchphrase
It was designed to make customization... as simple as possible was,
in reality.

Spree is Rails. Rails requires professional hosting; not a problem for
a project developed for over 1k; where hosting at $20 per month is peanuts. In this
case $20 per month is far over budget; again, the insides of her exact
business-choices are out of scope for this project. Good-enough
PHP-hosters come for under the $5 per month.

I was going to build it for free, obviously. So we could not afford me
spending hundreds of hours on tweaking some tool, CSS and whatnot. A
turnkey-solution like Magento would be a faster solution.

We chose the Dutch bank and payment provider Omnikassa because
they simply offered the best deal for her. There was no omnikassa
payment plugin for Spree, but there were some for more famous
frameworks.

I went for Spree after proof-of-concepting my two biggest challenges:
offsite payment and (Zurb-foundation](http://foundation.zurb.com) as CSS/HTML framework, instead of
the default Skeleton, came out quite
alright. And a 30 days trial on Site5 proved me that hosting there was
going to work out.

Zurb Foundation

I replaced most views with my own HTML, so that I can use Zurb
foundation. It offered just a little more features, such as a slider
and more advanced responsive features; like hiding entire subtrees of
elements on certain devises.

In the end, we decided to go Desktop-first; I am re-doing some of the
views now, so they are prettier on mobile too. The reason we put this
lower in our todo, is that the most-used payment system in the
Netherlands, iDeal, trough our PSP omnikassa, is not mobile-friendly in
the first place. So why offer an entire mobile-webshop when people
cannot pay (properly) on a mobile?

It turned out to be really easy, but quite a journey of discovery trough all the
spree-gems and its views, before I found out what views to copy into my
own projects. The CSS was just as cumbersome to override. In the end, I
decided to simply do away with all CSS and JavaScript for the front-end and roll my own.

Site5 Hosting.

For under €5 per month you get a server with git, ssh-access and
Passenger to host your Rails application. A few Euro more for a static
IP address, which I need for the SSL-certificate. It is an e-commerce,
you need HTTPs.

It requires a few settings to be changed to my Rails application and it
requires Ruby 1.8.7 since that is what their Passenger is configured
to use, but in the end it works just fine.

The only problem I had was some asset-precompiling issue, where the
compiler just died on me. After a support-call, the Site5-engineers upped
some memory on the server and I could compile just fine.
It turned out that some spree plugin came with several hundreds of
(demo) asset-files like huge videos that needed to be "compiled" by the
asset-pipeline. Cleaning up Spree Slider and removing its assets
fixed the issue for good. But hey, I don't expect a budget-hoster to
support me compiling hundreds of megabytes of video and other
demo-stuff. Fair enough.

Also, their uptime is reasonable. Not enterprise-alike reliable (IMHO), so I
have nagios to check the
frontpage every several minutes for certain strings to occur (It looks
if the words "Anna Treurniet" occur in the <title>). Every odd
month (or so) there is a restart or some short downtime. One time Site5
changed the MySQL-setup (location of the socket moved to elsewhere) so I
had over half a day of downtime until solved. And now and again the
application gets shut-down for no clear reason, so it needs to boot,
resulting in the webshop loading very slow for one or two visitors. The
nagios checking actually kind-of solves this too, since it acts as a
"visitor" opening the site every five minutes.

All in all, I am very happy with this host. It offers far (far!) more then one
would expect from a €5/month. In my "enterprise"-jobs, I have to deal with €500-and-up-per-month
hosters who have far worse deals, support, deployment and uptime.

Their absolute biggest downside is the way their bulkhosting environment holds them back from upgrading to Ruby 1.9.3.
So, if you depend on a reasonable recent Ruby-version, bad luck.

Git Deploy

In order to keep the deployment smooth and somewhat close to the
experience I have with Heroku, I use git-deploy. Git deploy consists of a few simple hooks that run on the server in post-receive hooks. So, after you push your changes to production with git push production, the server runs a few commands, like (when needed) database-migrations, assets and cache-refreshing and then a restart of the Rails application. I have used this for other, PHP-based systems too.
Some problems, as mentioned above with asset-precompiling aside, it
works like a charm.

Obviously, when using git to manage the deployment, you need a good
branching and releasing management. With that in place, I can fix and deploy changes within minutes. Yes. Minutes. Probably faster than most of you can log in over SSH, find the sourcecode on production, and hack a fix in with Vim.

Testing and TDD

Unfortunately, I did not manage to get good integration tests for Spree
going. Most of the extensions lack any form of tests. Spree itself is is
covered pretty well, but integrating Spree means changing configuration,
overriding behaviours with Decorators. And I still have no idea how
to tests these properly. The rest is mostly view-overrides, which often
breaks Spree's own tests and requires me to rewrite all the spree-tests
in my application. It mostly boils down to my inexperience with testing
mostly, though.

Omnikassa

A Spree Extension was written to allow offsite-payment with the
Dutch payment-system Omnikassa. This is and was a mess. Spree had no
(proper) support for offsite payments, so I had to hack into the entire
checkout-workflow in order to get this payment-system going. The
Omnikassa-extension somehow breaks the feature in Spree to allow
discounts; it breaks certain orders in the back-end and whatnot. Spree
1.2.0 promises to have this checkout-workflow-inflexibility fixed, but
an upgrade is rather hard, seeing all the customisations the application
needed.

Spree again?

I don't think I will use Spree for a future e-commerce project. Despite
its promise to be the most flexible solution, I found it making too much
assumptions and being far too inflexible in areas. I'd rather roll my
own, next time.
The most important parts that Spree offers me, are either very easy to
develop myself (products, categories, their views, content-management),
not needed (credit card-handling, user-login, 3rd party
statistics) or covered in solid Rails plugins (administration, editors).

Against small-things-made-hard, like changing the checkout-workflow
(one-click-checkout?, offsite-payments), manually ordering the products
on the frontpage, integrating a simple CMS for the few "static pages"
and so on. Usually, in an Average Rails-projects these things take a
few hours programming and deploying. Here they took me days of stepping
through spree-core code in order to understand how my Decorator did
(not) change some ordering or some menu-addition.

For me, Spree offers me too little benefits to overcome its downsides. Despites
its promise, it is very much a ready-made application, which works
according to various assumptions about workflow, features and even looks, that you can
configure and beat into shape; mostly. The very same conceptual things that Drove me
from Drupal.

But overall, rolling a simple, Spree-site on Site5, gives you a
well-designed, ready-to-go e-commerce environment for under €10 per
month. And with a few hacks and tools, you can make the deployment to
that host really easy. Whether Spree is the best solution for your
e-commerce needs, depends on how much (and what exactly) you need to
customize.

Doré Woodcut. Its only function is to make the layout look better. And these images are really nice themselves

About the author: Bèr Kessels is an experienced webdeveloper with a great passion for
technology and Open Source. A golden combination to implement that technology in a good and efficient
way. Follow @berkes on Twitter. Or read more about Bèr.