How Talentopoly is Built
Today’s post is written by my guest and fellow Indianapolis-ite, Jared Brown. I asked Jared to guest post here because he has created an application using Ruby on Rails, Heroku, and a host of other bits and services that I’ve also been using to bootstrap my new business, beautifulsavings.com which I’ll post more about in the near future. He’s done a fantastic job with Talentopoly, and he’s a developer I respect. Talentopoly is on my short-list when it comes to finding useful tidbits to expand my tech horizons. Check out my profile here.
Jared Brown is the founder of Talentopoly.com, a community for programmers, designers, and IT professionals staying current by sharing the best of what they discover online.
I wanted to take a minute to give a glimpse into the platform Talentopoly is built on. A lot of this may not be familiar to non-Rails developers.
The site is hosted on Heroku. I use it for staging as well as production. To say Heroku makes deployment easy would be an understatement. To deploy Talentopoly all it takes is a quick “git push heroku” or “git push heroku-staging”. To setup your project is also one command.
The production server consists of two dynos (Heroku’s term for a virtual server unit) for a cost of $36/mo. This setup can handle dozens of concurrent users per minute. The site regularly peaks at 50 users and doesn’t break a sweat.
Add-ons are Heroku’s way of making it easier to integrate with other services. Often times no configuration is necessary when turning on an add-on.
My staging server mirrors production. It uses the same add-ons. The WebSolr folks were nice enough to setup a free staging instance. So the staging server is free. I populate staging with production data via Heroku’s handy PostgreSQL commands.
Heroku uses nginx as the http server acting as a cache store and reverse proxy. nginx is written in C and super fast. Behind nginx are a load-balanced cluster of Thin servers (modified Mongrel servers) running the application stack. Heroku is constantly monitoring the health of the dynes and will spin up new ones to replace hung processes if necessary.
Other than Heroku non of these things are exclusive to Ruby on Rails developers. The following services help make my life easy.
Search is provided by WebSolr and the excellent Solr search engine. Search is configured on a per-model basis. Only a few lines of code are responsible for making the models searchable. It provides geospatial search as well as full text search. Unlike Sphinx Solr doesn’t rely on fragment indexes. Everything is handled transparently. When new records are added or destroyed the index is updated. WebSolr costs $20/mo. for 75k documents.
The database is a shared PostgreSQL instance on Heroku. It performs well under load. There are other options such as Amazon’s RDS but for simplicity of deployment I have stuck with Heroku’s native solution.
SendGrid handles all the outgoing email. It’s accomplished via a SMTP gateway, which saved time over using their API.
S3 handles user uploaded image assets via the awesome paperclip gem. Paperclip re-sizes and stores the images on S3.
Scribd is used to store and convert uploaded resumes. This is why Talentopoly can accept and properly display so many different file formats.
New Relic is also provided as an add-on. It’s invaluable for investigating bottlenecks. It provides a breakdown of the request stack tracing it through the database.
Chartbeat provides real-time analytics and alerts. I can see how many concurrent users I have on the site, which is useful if it’s seeming slow. Google Analytics gives me the full stats to analyze.
I haven’t had a strong need to implement an in-memory key-value store like Mongo, Memcached, or Redis yet. Though hopefully the increasing traffic on the site makes that a priority soon.
There are other great services, gems, and plug-ins I could talk about but hopefully that gives you a sense for how Talentopoly is built and what it’s like to build a Ruby on Rails app on Heroku.