A Simple Leaderboard
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
app
bin
config
db
lib
log
public
spec
vendor/assets
.gitignore
.rspec
.rubocop.yml
.ruby-gemset
.ruby-version
Bowerfile
Gemfile
Gemfile.lock
Guardfile
Procfile
README.md
Rakefile
config.ru

README.md

A Simple Leaderboard

This somewhat simple leaderboard is meant to exhibit some of the approaches and design decisions that are important to me when creating a Rails app.

Technology Decisions

For a leaderboard, the persistence store is a pretty simple call. Redis is built for this kind of data, making it very easy to ZADD and ZREVRANGE the members of the board. So, Redis is the only persisitence I am using.

Design Decisions

I am a big fan of keeping controllers as small as possible, which often means using service objects to get the business work done. I did that here, which allowed me to write easy specs for the business logic, etc. It would also allow us to move the important bits to other apps, gemify it, etc.

Also, I did not allow the ability to create multiple leaderboards. It wasn't specified, so I didn't add the complexity. However, this would be very simple to add, both to the app and the service objects.

Refactorings

  • Controllers: The respond_to blocks in the controllers would greatly benefit from something like Wisper.
  • Input validation: The scores are not really validated at this point.
  • Delete returns to page 1. That's probably not what is desired.
  • If we get tons of users, it probably makes sense to post he current score with a new score, then increment the value in Redis.

Roadmap

This leaderboard app is VERY simple. For next steps, I'd look at:

  • Authentication. I didn't add it because it wasn't required. I thought about using Devise, but if the app ends up being used somewhere that already had authentication, it'd be unnecessary. Again, this would be pretty trival to add.
  • Front-end work. I did add some Angular, just enough to make updating a bit more sassy. But, the presentation is very simple and would need a fair amount of love to make it "modern". If this app got serious, I'd probably unhinge the front-end altogehter and make the Rails backend an API (with Grape, etc.).
  • Event Sourcing. If/when this leaderboard app takes off and we have millions of users, I'd probably like to use Event Sourcing and CQRS to scale and allow us to snapshot leaderboards, etc. Event Sourcing is my new shiny, and it's utility continues to amaze me.