upgrade-ability of ror_ecommerce

[Dave]

I'm starting a conversation about upgrades to ror_ecommerce. This is general conversation that I'd love to hear different opinions.

HISTORY:

One of the main reasons I started this project was because I thought spree's upgrade process was broken.  You could upgrade spree but the process was extremely painful.  Originally I started ror-e to behave like a normal rails app that people can use as there own project.  This would mean that when you start a project you own the code.  The changes you make would branch from the ror_ecommerce base app.  Hence I felt it was your responcibility to take your project the direction you want it to go. 

There are other options. 

• Make ror_ecommerce a gem.  (this hides code and makes figuring things out painful in my opinion)
• Make ror_ecommerce an engine.  (this hides code and makes figuring things out painful but is probably better that a gem)
• stop making many changes to ror_ecommerce and future upgrades will come mostly from engines. (this was my original thought)
• change ror_ecommerce into an SEO architecture.  (When I originally envisioned this project this was the route I wanted to take, I quickly realized this was not going to work for most shops)
  

I'm sure there are more options and I' love to hear some feedback.  I do eventually want to create engines for affiliates, a blog, reports, and anything else I can think of in the future.

Dave

[Torsten]

Since I am considering jumping on the wagon, I think:

One of the main reasons I started this project was because I thought spree's upgrade process was broken.  You could upgrade spree but the process was extremely painful.  Originally I started ror-e to behave like a normal rails app that people can use as there own project.  This would mean that when you start a project you own the code.  The changes you make would branch from the ror_ecommerce base app.  Hence I felt it was your responcibility to take your project the direction you want it to go. 

This is not really a working model for evolving software: in fact I tried it with spree and it was horrible. Trying to re-sync the upstream changes back in was worse than all the other options.

 

• Make ror_ecommerce a gem.  (this hides code and makes figuring things out painful in my opinion

Not bad (even with actual released versions, as a git copy) 

• Make ror_ecommerce an engine.  (this hides code and makes figuring things out painful but is probably better that a gem)

Yes, even better.

 

• stop making many changes to ror_ecommerce and future upgrades will come mostly from engines. (this was my original thought)

Ror is not ready for that. In fact most software that is still being developed isn't. That would mean bug-free and feature-complete. not.

 

Torsten

[Dave]

Are there other projects that have different options?

Making things upgradable when your are dealing with a small project is very easy.  Once you have a huge project like an end-to-end solution involve more. 

Are there healthcare or social apps that need to deal with this?  diaspora?

[Torsten Rüger]

Hi,

spree actually went to the rails engine model before 1.0 . Whatever they did before was a mess, and that is off course because rails is the level where this functionality must be (not above).

But the upgrade to it was quite a pain. So one could do this thing that spree did at 0.09, make a baseline.

I mean not to consider upgradability for this "jump". After all, when done right, every class needs to be namespaced (moved in the tree), every url-helper prefixed, every view moved .... (maybe time for a shorter name/abreviation to ror_ecommerce)

Then one could roll all existing migrations into one. Make a more feasable shop view and come out with a 0.9 version to gather some feedback before a 1.0

Actually I don't see an alternative to the engine thing. But even that does not solve how upgradability of views is going to work.

Torsten

[David Henner]

This is why I was considering making ror-e a service oriented architecture.  Once I started down that path I quickly realized it might be the best approach but only truely advanced developers would use the project. 

I'm actually planning to go down the SOA approach but I don't think it will be open source.  I'll either charge or use it for my own.

SOA would take a while to finish.  I'm guessing well over a year.

[Raoul de Villiers]

Hi Dave,

I am just starting out and I like your overall philosophy. I think it depends if you want to personally keep on 'owning' this project. If so, keep it as it is, i.e. a comprehensive code template.

Thanks again for a great project.

[David Henner]

I just sent an email to the diaspora project to get their thoughts.  I'm definitely not going to move quickly on this.  If I can't think of a win win I'm not changing.

That said I know there is a solution that can make upgrading easy and keep the code looking and feeling like a rails app.  I'll be thinking...

[Torsten Rüger]

That said I know there is a solution that can make upgrading easy and keep the code looking and feeling like a rails app.  I'll be thinking...

I just read the rails engine guide. And it sounds like if you'd add a gemspec you'd be about there. (if you don't namespace). Engines are just like apps it says.

I think it's just about who owns the application, and that should be the developer.  So he does rails new and adds ror as a gem and then goes about adding views, patching controller/models if really needed and adding more. 

While you own the ror git and make improvements there (mostly bug fixes, small enhancements) that the developer can then pull at leisure by bundle update ror. 

It's what I would do if I were to start now. Possibly as a git submodule then it would be easier to also develop ror. 

But working in the ror repo is really just killing cooperation. Because then I would have to keep my own stuff on a branch, so I can keep the master to push back fixes. Or not bother with that and then you'd never get anything back.

And this lack of cooperation is actually happening as you can see by looking at the network. Several people have forked and worked on their fork, but never have you pulled from them (or they pushed)

So I think the engine approach is a small change and the only way to make cooperation easy. 

Torsten

[David Henner]

So here is what I will do...

I'll make a branch where ror-e is just an engine.  Then I'll start playing around to see how I like it as an engine.  If it runs smoothly I'll make the project completely an engine.

It is a huge engine though =)

[David Henner]

Checking this out...

http://confreaks.com/videos/863-railsconf2012-rails-engines-patterns

Looks like the greatest benefit happens when the engines are small.  I'm still not done with the video. 

[David Henner]

Judging from the video it would be best to break ror-e into about 5(or more) different engines..

• Customer facing
• Admin - merchandising
• Admin - fulfillment
• Admin - inventory
• Admin - orders
• Admin - users
• Migration - engine

This need a bit of thought.  It's also more work than i have from the next few months.

[Torsten Rüger]

For me the main benefit is mounting an engine under a different path than /.

And then having the stuff from my application loaded first, so I can money patch or override ror as required (and not have to change it's code)

Having another app is so far future that it can be left for later (and the guy who needs it). That throws (usually) user integration issues up for which there is no consensus solution yet.

That would mean 1 engine would be enoug, but 2 may be nice for:

- shop, so one can code ones own app (if such be needed) next to it

- admin, mount under weird path for security by obscurity

Having otherwise engines for things that are not really replaceable, or there is no use-case for replacing them JAWOT (just a waste of time)

For the grunt namespacing work I would offer help. One can split by directory and just start moving files and adding the module and url helper changes. Start testing when it's all back together.

Torsten

[Torsten Ruger]

http://confreaks.com/videos/863-railsconf2012-rails-engines-patterns

I don*t know. That wasn't soo good I thought. There are definitely better ways to work with the app/engine inclusion. Especially when more engines are used (I use 8) using git submodules is much quicker and easier. As the engine sits in a path in the main apps root folder, switching work between the app or within the engine is really quick. and since one can have the app running and reload engine parts his problem of seeing the error later is not happening.

And all that footwork that was described with templates just doesn't scale up to ror size. Even the thing that spree tried with predefined "hook" points of change is not flexible enough. 

One has to be able to squeeze even a class into any div or remove any random html element.

But lets hear how the playing goes when you have something

Torsten

[David Henner]

Right now I am leaning toward maintaining 2 projects...  One engine and one just a regular ole rails app. 

I personally don't like "big" engines but I do know many people do like them.  I would say it is a debate about upgradeability vs changeability. 

• If you run a huge dev team the engine doesn't buy you upgradeability or changeability
• If you run a small dev team the engine buys you upgradeability over changeability
• If you run a huge dev team the app buys you changeability but you would have a difficult time with upgrading with any solution. 

I was at shoedazzle and we had more than 10 developers and I can definitely say an engine approach couldn't be upgraded easily because too many things were changing at one time.

The reason I say changeability suffers is because you might need to change the implementation of a method in your main app. Then you start needing to shift from the base app to the engine's implementation to figure out what is happening.  Plus when you are working on your base app many of the methods are hidden from you.  This might not be a big deal if you don't make many changes but I assure you I had serious issues tracking down code at ShoeDazzle.  Eventually I had to rip spree's heart out of shoedazzle.  (Oh boy that fun a fun X-mas)  I laugh every time I see Spree advertise that SD uses spree when it was me that ripped it out.  =)

Thus for a large project I will always recommend staying away from the engine.  It really doesn't buy you much.  Especially since you will fix a bug in a different way than I fix it.  Then when you upgrade the "fix" is no longer "fixed".

_________________________

I don't think it will be much of a burden to support this engine because 1) it will have the same changes as the app, 2) most new functionality will be implemented in yet another engine.

Thoughts?

I'm thinking this is the best I can offer.  People that want an engine win and people that like it the way it is win.

Dave