Skip to content
This repository has been archived by the owner on Apr 9, 2024. It is now read-only.

Latest commit

 

History

History
86 lines (65 loc) · 6.77 KB

ARCHITECTURE.md

File metadata and controls

86 lines (65 loc) · 6.77 KB
Raw

Old notes from when QM got started:

Rails and Ruby versions

Some notes on how I'm making certain architectural-ish decisions (expanding on an email to the 'civio-dev' mailing list):

  • Heroku and Postgres were definitely in, no question about it. That stays.

  • Rails 4 has some interesting things, like support for Postgres native types: the key-value store hstore - built by Heroku - looks nice, and useful!, and is well liked even in YC; and it's supported by Heroku in dev, and also in my local Postgres.app (version 9.2.4 > 9.1). I can see myself using hstore beyond the basic model attributes (I even thought of using MongoDB last summer, when I first thought about the QM backend, precisely for this flexibility), but still, Rails 4 felt too inmature: the RC1 was released in May, and critical gems like Devise had been compatible only a couple of days ago. Well, it was May when I took those notes, and now it's almost August, so Rails 4 feels like the right choice. (I hope I won't regret it.)

  • The Ruby version was easier: Ruby 2.0 is the default in Heroku, recommended by Rails also, and it's probably not a big deal anyway.

  • Next was user registration and authentication, something that (oh, progress!) is now completely commoditized, and I'm happy for that. Devise is clearly the most popular option, together with OmniAuth for multi-log-in-provider support (i.e. log in using Facebook or Twitter or whatever). They work well together, so it's all good.

  • After authentication comes authorisation, and Cancan is by far the 'de-facto' standard.

  • While researching all this, I found 'starter kits' and 'app templates'. Suspenders is created and supported by the smart people of Thoughtbot, and seems focused on laying a good testing and dev environment, but there were too many little pieces I didn't know and wasn't sure I needed. Then there're the RailsApps templates, and one specifically for Devise+CanCan integration, which felt like a good idea initially. But I decided to do it myself to get a better understanding of how it all works, and it was the right decision: it wasn't that difficult once I understood what the different components were for.

Image uploads

On image uploads, Paperclip seems to be the traditional choice and is well documented. Dragonfly seems too weird and maybe unmaintained, so it's between Paperclip and CarrierWave.

Seems like CarrierWave overtook Paperclip at some point (S3 support for example) but it then came back, and Paperclip has S3 support too. The latest in Stack Overflow suggests both are fine, with Paperclip slightly more popular, but falling in popularity. All in all Carrierwave feels more agile, more modern, and I like little details like - for example - the fact that they use a smaller alternative to ImageMagick. Polish as heuristic.

Uploads to Heroku bring a number of issues, so I need to think about overall architecture (although not from day one probably, since we won't have many uploads). This answer explains it very well (and it's from the same guy who prefers CarrierWave).

PopIt

I seriously considered it for a while. I even made a now very obscure list of needed extensions or improvements:

  • Use links or positions to store relations?
  • Allow person on right side of position? Or create new category?
  • Add tags like in Alaveteli to people and orgs (including value tags CIF:123). Great extension mechanism, almost FluidInfo
  • Add Source in position
  • Add Dates in positions
  • Add media items to person (could use links)
  • Edit in place
  • How to merge two people?
  • Edit via API
  • Limit relations to limited set?

I thought it would be the quickest option, and made sense strategically, building on top of a potentially popular component. But I didn't like the idea on being dependent on it when there wasn't a clear strategy: proof of that, they created popit-django, a few months later. A bizarre architectural decision, and a mix-match of technologies: node.js, Mongo, Django, Postgres.

Dependencies

A brief summary of the main components used in the app: