A long time ago, the issues inside of Spree used to be either silly questions (usually by me) or noting another shipment/adjustment bug. You don’t see that anymore. You see serious performance issues in edge areas or pull requests for new features or to deprecate some not so ideal features.
Spree now has over 6000 stars, 350 people watching, and over 2800 forks. Spree is popular. GoDaddy is building their “Shopify killer” with it and I have no doubt they’ll crush them. They think about marketing and disrupting the media enough to make them, well, far more noticable than the polite Canadian ads from Shopify.
Shopify also has limitations. And people want and need to move off. ShoeMe is on Shopify and they’ve purchased an already established .NET storefront to move everything over to. Its not uncommon for me to check my inbox and read an email from someone wanting to migrate from Shopify. GoDaddy is and has created a marketplace platform, integrated liquid, and built a Rails application structure that will make Shopify rethink its tech stack and its features.
Its also great for the Spree community because of the publicity this gives Spree. And Spree is getting popular. Very very popular.
Its also insanely complex. You have around ~75 tables in your DB with Spree and over 100 models for your business logic. However, this is expected. This is ecommerce. If you think you can make a store with no more than 20 models, I’ll point you to the door and if I’m in a good mood, hold it open for you.
If you think that you can walk into ecommerce and modularize the functionality, lets sit down and talk. The fact that you can walk up and say “Hey, this is big and its messy and its world changing. How to do we contain it and make things easier for people?” then you might find a place in ecommerce in general.
The web in a whole is moving to an API driven ecosystem. I don’t even use the spree_frontend. I just bundle with the spree_backend and I get the spree_api and the spree_core automatically. This means Spree storefronts are using Backbone, Angular, and Ember. I’m a plus one for Ember due to its convention over configuration. Backbone also has its place for legacy and wider support. Its minimal, its easier to learn, but I also think its more for the experienced to ensure the application follows standard best practices and conventions as well as ensuring its supportive of legacy. Angular seems to be doing its own thing by making antipractices best practices and lying out its teeth in its marketing (you only need angular.js! as 1 dependency, we follow MV*, we’re really good with data. I spent more time trying to work around their BS than anything else. IMO don’t pick a framework that’s marketed by a company. There’s been too much lying to actually get work done. And too many white promises.)
If you’re building your next Spree store with Ember, you’ll probably be wanting an API to work with. Right now, you have to sorta build your own. I’m hoping I can set time away to get an Ember friendly Spree API built for 4.0. Work has already started since 3-0-stable was created.
Making a single page storefront is hard. You’ll have enourmous amounts of data and a lot of components to manage. I highly recommend Ember for the job. It Rails developer-ish friendly. Its also great for people moving from Backbone since it has the same dependencies. Its the type of framework I see surviving the long battle as people discover its doing all the right things and it doesn’t sit and lie to its users (read: angular).
Lets talk about JSON. You know when you do an API request and you want to get your data back? That’s the first thing that’s changing in Spree. I think many people can agree that Spree needs a consistent and established way for serializing the JSON. Spree is currently using Rabl and to be frank, it needs to go. Rabl has not been supportive of multiple rails applications. So, if you’re trying to load a rabl template in Spree from your main application, its not going to work. You just lost all the benefits and you might as well build your own API.
The API in Spree is being switched from Rabl to Active Model Serializers. Caching is going to be a neccessity so we won’t be using 0.9. 0.8 is currently being used and when 0.10 comes out, Spree will switch to that ASAP. I’m looking forward to AMS 0.10.
After the AMS change and all the rabl templates have been deprecated, work can be started on changing Spree’s API up to be more Ember friendly. If it can work on Ember, it can work anywhere, mainly because Ember inforces best practices and if the JSON can be rendered using the best practices, it shouldn’t matter if you’re on Backbone, (Angular,) Knockout, or Kendo.
The aim of this blog post was to communicate three things: (1) Spree is growing and with that, its API is going to be changing, (2) more storefronts are using JS frameworks so the API needs to shape up where it may be lacking, (3) people need to serializer JSON in ruby, AMS is going to support that and that’s also a reason for the change.
- My notes on Angular are my opinion. I still work with it and I’m enthusiastic that they might treat their users (read: me) nicer. I still use it on a lot of Rails applications. Its my opinion.