Apollo and Rails

On hype with Apollo launch, I’ve found one quite interesting information. About Slingshot, tool which allows developers to deploy Rails applications that work the same online and offline (with synchronization). Unfortunately Slingshot won’t be available for free (probably).

Well, it looks I had an idea how such solution should be build, at least in terms of synchronization. When You need drag and drop deployment You may consider JRuby? But lets talk about synchronization. My idea is based on fact that basically local Ruby on Rails application and normal web application are identical. Most important they share data structure – models. Magic ingredients would be:

  • updated_at
  • created_at
  • acts_as_paranoid and deleted_at
  • custom web service on web application side

Every table needs those three fields in schema. Based on information in them and last date of synchronization we can tell which rows were changed, added or deleted. Using web service we can exchange this data.

When syncing we can find following cases:

  1. data were updated/deleted on one side
  2. data were updated on both sides
  3. on one side entry was deleted and on the other side were updated

Ad. 1
Newer entry takes precedence.

Ad. 2
Conflict can be resolved in few ways: by date of change, by side (for example, web server wins always) or leave to user to decide.

Ad. 3
Like in 2 or by operation type (delete takes precedence over change).

One issue more which I came when thinking about those tool, are IDs for new entries. It is obvious (is it ?) IDs for entries have to be taken from different, distinctive spaces just to avoid conflicts. There can not be possible to create two different object in local application and web version with the same ID.

I can not find any more potential issues so I’m sure that I’m missing something important – it just looks to easy :)

Join the Conversation

1 Comment

  1. I’ll tell you how I did it:
    There was a model called sync, which had polymorphic associations with a model called ‘folder’ (and a few others). A ‘sync’ has three types, created, updated and deleted. An ‘after_update’ and relevant methods assured that were I to CRUD an asset, a sync record would be created. When a user asks for ‘all assets’ a sync time is set in their session. Then, when a user polls for changes, all ‘syncs’ – made after the ‘sync time’ would be displayed. The sync time would then be updated to the current time.
    Hope this helps

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.