Best approach to integrate JumpStart Pro with an existing codebase?

I've been a subscriber to GoRails and have started piecing together some of the core functionality that JumpStart Pro includes. I've also added some functionality that is specific to the product I'm creating. Instead of hacking together what is covered by Jumpstart Pro, I just purchased a license, whats the best way to integrate this with my current app?

Hmm, that's a good question. It's not really intended for that, but I've thought about porting over some older apps for mine to Jumpstart Pro as well (like GoRails).

What I would probably do is copy your migrations, models, controllers, and views over to the Jumpstart Pro app. You can make adjustments as necessary like adding associations to Teams so that it will work better with Jumpstart Pro. Most of your business logic and models won't really change other than being associated with teams instead of users.

Trying to think of other things that might be tough, but models seems like the primary thing.

Thanks Chris, that's kinda what I was thinking but didn't know if there was a better way to approach this that I was unaware of. For me personally, a big part of buying Jump Start Pro was the payments piece. I've never done that before and didn't want to mess that up. 

Yeah! Payments is really tough. I spent like 3 months re-learning how Stripe does payments now for SCA regulations in the EU and it was hard for me even though I'd done it like 15 times before.

Matt Bjornson The approach that I took is to use the rails engines. For example the POC that I was working is nothing but a bunch of rails Engines. Here are few of the engines that I had

When I bought the license to the template couple of days ago I moved the rails engines from the old POC to this template and had to make few minor modifications to use the teams functionality.

My code is still in engines and it does not pollute the global template which should make my life easier when pulling the upstream changes which are made in the template.

Let me know if you want more information and I will be happy to discuss

A C I'd be interested in hearing more about what you did.

+1 for learning more about what you did,  A C  

William Flanagan   Jeff Helman  

I started working on a side project few months back and it was a greenfield rails project without any starter template. I have been a fan of the architecture described in https://cbra.info/ and I used that in this project. I did not went too crazy with the components but has few components (rails engines) like marketing, app_ui, app_backend, app_auth (device based), app_branding etc. 

I organized all my components in rails application under components folder so I don't have to deal with multiple projects and gem version etc. The idea is that I would be able to separate the components into rubygems or separate rails apps if I ever needed that kind of ability but for now it worked great.

When I bought the template last month I copied all the components from my original rails app into this template and did not touch the original template files at all which will make pulling my changes from upstream easy. In my engines I monkey patched the teams model and added the associations that are specific to my application. Here is an example code of the monkey patch that I am talking about

module AppBackend
  class Team < ::Team
    include Brandable
    has_many :my_domain_models
  end
end

module AppBackend
  class MyDomainModel < ApplicationRecord
    belongs_to :team
  end
end

In my engines controller I populate the current team using a before_filter. Something like

require 'app_backend/application_controller'

module AppBackend
  class ApiController < ApplicationController
    before_action :set_team

    protected

      def set_team
        @team = AppBackend::Team.find(current_team.id)
      end
  end
end

The biggest pain for me was to deal with the webpacker gem as its support for rails engines is not that great. I have multiple UI components and they all use different UI frameworks and different webpack configs.

Hope this helps. 

Thanks,  A C . This looks very promising (as in "my brain thinks it can grok this, but time will tell.")

I am a big fan of DRY at this more meta-level, so I look forward to digging into this. Thanks again!