Spree or Solidus? Which OSS project Nebulab, as an agency involved in Ruby on Rails eCommerce development, should invest on? This blog post tells the story about what's happening inside our agency in choosing where to put more effort.
Spree and Nebulab
Nebulab has proudly been one of the first company that adopted Spree. In fact we are using it since version 0.30. We always did our best contributing actively to the project and its extensions, attending almost all SpreeConf around the world and supporting the community via the Spree Mailing List.
We strongly believed in this project that we used for 100% of our eCommerce customers, often recommending them to migrate to Spree from other platform, like Magento or custom Ruby on Rails eCommerce applications.
We have also been one the first company that applied to be a Spree Solution Partner. This partnership allowed us to give something back to the project and take a lot of contacts with clients all over the world.
On October 28th Spree announced that they will no longer maintain the OSS project. The main reason is that the Spree company has been acquired by another bigger company, First Data.
It's easy to imagine our feelings hearing that our favorite OSS project would have a so drastic change in its maintenance and community management.
Bad news never come alone. Wombat, an integration platform built from Spree company that we were using for some of our clients, would be discontinued soon. Fortunately, according with one of our cool customers which was extensively using that service, we developed Cangaroo, an Open Source alternative to Wombat, that we are currently using successfully in production.
Months before this event, a group of developers from Bonobos, one of the biggest online retail store in the United States and Stembolt, a Canadian web development firm, forked Spree because they started to diverge from the direction Spree was taking. They called the project Solidus, naming it after an old Roman coin and the SOLID principles of Object Oriented Design.
Having more activity we naturally started taking a look at this fork, understanding its principles and its different approach that we started to appreciate and share.
If you are interested in differences between the two platforms this article is a great resource.
Here's a list of stuff that we like about Solidus:
A Solid Roadmap
Solidus guys decided to put focus on fixing and improving current codebase instead of adding new features that are probably unnecessary for many stores.
Here you can find the full Solidus Future Plans.
We trust developers involved in the Solidus project, we can see on the Solidus GitHub Repository that they are great in what they do and lately they also have emerged for their attention for security issues.
Top Priority to Code Integrity
Solidus is trying to get rid of stuff that doesn't look clean like the
improper use of
class_eval. This is not only a question of code
style but ensure it's easier to customize your stores, your extensions and
to update Solidus from one version to the next one.
But why class_eval is not a good practice?
Of course it depends by the situation but in general using class_eval you
are re-opening the general class definition; technically this is not
an inheritance and this means that into the re-opened class you cannot use
super to replicate a previously defined method behavior. For the
sake of better understanding this concept, let's make a simplified example:
Spree::Stock::ShippingRateSorter is a class defined into the solidus core that defines how to sort shipping rates.
# Solidus Core # app/models/spree/stock/shipping_rate_sorter.rb module Spree module Stock class ShippingRateSorter attr_reader :shipping_rates def initialize(shipping_rates) @shipping_rates = shipping_rates end def sort shipping_rates.sort_by(&:cost) end end end end
Now, in your store or extension, suppose you want to change how to sort those elements. Specifically we want to reverse the order of shipping rates. We used to write in our stores something like:
# Our App or Extension # app/models/spree/stock/shipping_rate_sorter_decorator.rb module Spree module Stock ShippingRateSorter.class_eval do def sort shipping_rates.sort_by(&:cost).reverse end end end end
This is not terrible, at least until the default way shipping rates are sorted changes into core, and our code is no more compliant with it making it a mess to update solidus to more recent versions.
Often, the solution to this kind of problem is using super to inherit the behavior of core code in order to make our extensions less dependant to that code.
Solidus is proposing to change this
class_eval over-usage, moving to a more
clean way to extend stuff.
# Our App or Extension # app/models/spree/stock/custom_shipping_rate_sorter.rb module Spree module Stock class CustomShippingRateSorter < ShippingRateSorter def sort super.reverse end end end end # config/initializers/spree.rb Spree::Config.shipping_rate_sorter_class = Spree::Stock::MyShippingRateSorter
Awesome, isn't it?
Forked from Spree 2.4
Solidus has been forked from Spree 2.4, and now Spree is at 3.0. The main change between these versions is the introduction of Twitter Boostrap into both frontend and backend. That wasn't a good idea in our opinion for several reasons:
- updating would mean changing frontend code of all stores we were working on;
- 90% of our clients are not interested in bootstrap themes but a custom frontend style, so often it would probably be more work to remove it than to adapt the spree frontend to that specific store needs;
- in our vision the frontend HTML should not include front-end framework class names but semantic ones that represents what's inside that specific element.
Lot of friends and contributors that we did know on the Spree community have already joined the Solidus community. In fact, in the Solidus Slack channel there are already 400+ developers that discuss, support each other and design together the future Solidus moves.
We also love conferences, and we look forward to attend Solidus Conf 2016 in Toronto, an opportunity for us to learn, to better understand the Solidus goals and to meet community members and clients in person.
Our plan is to start all new stores using Solidus but to stay with Spree for the majority of those already developed. We think that this is the decision that makes more sense, also because Spree has new maintainers now and this should ensure quick response to any security issue that could come out.
Even if Spree seems to be reborn with a new core team and roadmap, we think that there's still a lot to do for Spree to recapture our interest and we currently feel comfortable with the Solidus approach, which we hope to contribute to as much as we can.