geeksoflondon / retainapp Goto Github PK

Just a brain dump of what has been discussed in the last few days for rewriting Retain into a more modular and stable infrastructure.

Current purpose of retain

Currently Retain has (incorrectly) multiple goals:

• Storing attendee information and history
• Tracking event signups
• Tracking event confirmation (retaining users)
• Tracking event attendance, including check in/out during events
• Badge tweaking for users

Current data stored

Objects

• Attendees and their "static details" (email, diet, tshirt shirt size, etc)
• Events
• Tickets (attendee for an event)

States

• Whether an attendee is checked in or out of the venue atm
• Whether an attendee has edited their badge
• Whether an attendee is confirmed or cancelled
• Whether an attendee is crew, volunteer, etc
• Whether an attendee has confirmed the details on their badge

Problems

The current problems include

• Code is hard to read
• Code is not very modular (causing above issue)
• States are stored on models making it hard to add new states and keep track of history
• Retain does more than just "retaining" users
• Hard to do stats on current data models
• Code is not tested

Suggestions

• Build a single data store for the objects and interactions ("events", bit unfortunate naming seeing as we run events, but you get what I mean, let's stick with "interactions".
• We store events and attendees as regular objects
• For every interaction an attendee makes, we add a record to the interactions table.
• Current status for an attribute can be determined by getting the last interaction of a certain type for an attendee
• We could even make signing up for an event an interaction, but inclined to stick with regular model.

So for example we will have the DB models:

create_table "attendees", :force => true do |t|
  t.string   "first_name"
  t.string   "last_name"
  t.string   "email"
  t.string   "phone_number"
  ...
end

create_table "events", :force => true do |t|
  t.string   "name"
  t.date     "start"
  t.date     "end"
  t.string   "venue"
  ...
end

create_table "tickets", :force => true do |t|
  t.integer "attendee_id"
  t.integer "event_id"
  ...
end

create_table "interactions", :force => true do |t|
  t.integer "attendee_id"
  t.integer "name"
  t.integer "value"
  ...
end

Now this might be easier to do in something like MongoDB, but that's beside the point and can be looked at.

Modules

With this data store in place I think we can, with an API and possible a nice gem to use it, move all the user interaction into other apps. Every app can "register" the desire to read or write certain attributes from out data store via an API or via the gem (which just uses the API).

So for example I can imagine use building a new retain app that talks to the data store as such

Retain.store.user(user_id).confirmed?

Here Retain.store would just be an instance of the API client loaded with an initializer, and checked_in? checks the confirmed attribute for a boolean value.

We could do something special where we make a User object in the Retain app that is not tied to a DB but to the data store, allowing us to write custom functions like this:

class User < DataStore::Model
  def confirmed? 
    self.confirmed  ==  "confirmed"
  end
end  

Which allows us to store complex values on every attribute instead of having a poop ton of booleans

Benefits

1. We could make loads of little tools that run on top of this data store without the need to make 1 big heavy app
2. We could run a staging version of the DataStore that anyone could use to make new apps with, meaning they don't need to setup the DB locally and load it with test data.
3. Concerns are separated
4. Models stay light
5. We preserve full history of what a user has done even when their state changes.
6. Analytics will be easier because of 5

From IRC:

17:33 <theartisan> kevinprince / mseckington_afk / cbetta  when i update my badge, and then go back in, it should show me the updated data right?
17:33 <theartisan> because i changed my overnight from yes -> no, went back through the process, and it still said yes