Exchange data between 2 Rails apps (preferably offline) on the same server

Question

I have 2 Ruby on Rails 4 apps on the same server (they do not - and should not - share database):

deploy@Ubuntu-1404-trusty-64-minimal:~/applications$ ls
app1  app2

How do I exchange data between app1 and app2?

My current implementation is unstable and not secure:

app1 requests app2 to update first and last name of the user with username bobby:

# app1
HTTParty.get("https://app2.com/update_full_name?username=bobby&first_name=Bob&last_name=Dylan")

app2 receives app1's request and processes:

# app2 app/controllers/some_controller.rb
def update_full_name
  user = User.find_or_create_by(username: params[:username])
  user.update_attributes(first_name: params[:first_name], last_name: params[:last_name])
end

I have read that ActiveResource has been removed from Rails 4. I never really understood ActiveResource anyway, so I will not explore it further and will prefer a different solution.

Answer 1

I had the same problem and explored every option: ActiveResource (which is deprecated), callbacks with my own homegrown API wrappers, queueing with Redis or RabbitMQ. Nothing was easy enough for my simple mind to implement. If Model1 in App1 will always update Model2 in App2, then best solution I've found with Rails is the Promiscuous gem

It's makes it pretty simple to run a pub/sub system that keeps data synched up between two ruby/rails apps. It works with both ActiveRecord & Mongoid. The documentation goes into more depth, but here are a few gotchas I found when trying to set it up using the Quick Start guide on the github page.

1. Make sure you have an initializer file in both apps that connects to your shared RabbitMQ instance.

2. If using ActiveRecord on the publisher side, you will need to create a new table (subscriber does not need this table to my knowledge):

   create_table :_promiscuous do |t|
     t.string    :batch
     t.timestamp :at, :default => :now
   end
   

3. You will also need to add a column to every publisher and subscriber model

   # in App1 - publisher
   add_column :publisher_model, :_v, :integer, limit: 8, default: 1
   
   # in App2 - subscriber
   add_column :subscriber_model, :_v, :integer, limit: 8
   

4. You can set the name of the published model. For example if I have a namespaced class Admin::User in App1, I can publish the attributes :as => 'AdminUser' and App2 has the model AdminUser it will listen correctly.

5. If you've followed the instructions from the github page, included your mixins and set publishable/subscribable attributes, you will inevitably want to run it in production in which case your subscriber will need to run a worker. I use a pretty shameless ripoff of this Resque deploy script, my version for Promiscuous can be found here and it seems to work.

I'm finding more and more ways to use this setup. Gives me a lot more flexibility with sharing and managing my data. Good luck.

Answer 2

So if i was you, i would look into a queueing system.

The nice thing about it is that it's asynchronous, so you don't really have to worry if both apps are up and running as soon as an update occurs.

I'm not really an expert on message queues, but RabbitMQ with something like RubyBunny could do a fine job if you ask me.

Anyone with experience on message queueing feel free to edit me.

Answer 3

My suggestion is to keep an API and for that if you want a quick solution you may take a look at rails-api gem and their documentation.

For the data exchange you can use a persistent HTTP library like Typhoeus and queue the requests, the same way is explained in the documentation in the section Making Parallel Requests.

Concerning security, a simple "token" would be enough to make use you don't get forged requests. You could also keep a table of hosts to exchange data and they token.

Other option is to use the Publisher/Subscriber pattern, where I recommend this article to have a more in depth knowledge and this blog post.

Answer 4

It seems that you are required to share something between these two applications, in your example, it is a URL. I understand the need for separate databases, but I'm going to assume you're okay with having some sort of 3rd shared resource.

I like Paulo's idea of using Redis here, but I think going into pub/sub and Typheous could be more complexity than is necessary. My suggestion is:

1. Store update-able info in Redis
2. Use cron to run a rake task to pull updates

#1

Assuming you setup Redis and redis-rb

When you update a model on app1, store the applicable changes in Redis:

### User just updated! ###
# Grab the attributes you want to update on other server
attributes_i_care_about = user.attributes.extract!(*%w( username first_name last_name ))

# Set a key for this user, future updates will overwrite, leaving only most recent
key_for_this_user = "user_updates:#{user.username}"

# Store it
@redis.hmset(key_for_this_user,*attributes_i_care_about)

#2

Setup cron to run as often as you like, I won't go into cron details here but the command should be pretty simple once you setup a Rake task. Something like: bundle exec rake user_updates:process

Where the rake task might look something like this:

namespace :user_updates do

  desc "Process user updates from other server"
  task process: :environment do

    @redis.keys("user_updates*").each do |key|
      updated_attributes = @redis.hgetall(key)
      user = User.find_or_create_by(username: updated_attributes["username"])
      user.update_attributes(updated_attributes)
      @redis.del(key) # get rid of the key after use
    end

  end

end

No internet connection required!

Answer 5

My primary choice would be implement an api using ActiveResource. If you wouldn't use the API solution, you can use rake tasks with cron to exchange data between two Rails applications, like @TheWorkwerAnt suggested, but without redis.

The difference is:

• Add a column to your records to indicate which of then are synchronized.
• Make connections to your two databases in your rake tasks. Reference.

The advantage of this approach is that it don't rely on external systems.