ruby-on-railstwitterrubygemsdatabase-connectionbackgroundrb

Need help designing my first Rails app! (involves Twitter, databases, background processes)




Firstly let me mention that I'm new to web-frameworks.

I have to write my first web-app for a Uni project. I spent two weeks learning Grails and Django. Started working with Rails yesterday and loved it. So I've decided to go with it and discard my work in the other frameworks.

About the app
It's supposed to be a Twitter app that utilizes Twitter's Streaming API to record tweets which match a set of specified filters. (I'm going to use the Tweetstream gem which takes care of connecting to Twitter and capturing matching tweets).

The app's web interface should have the following functionality -

My inexperience is showing as I'm unable to comprehend -

  • what my models should be (maybe Request should be a model. Tweet doesn't need to be a model as it's not being stored locally)
  • how I'm going to connect to remote databases.
  • how I can create background processes (backgroundrb??) and associate them with request objects so that I can terminate then when the user asks.

    At the end of the day, I've got to build this myself, so I'm not asking for you to design this for me. But some pointers in the right direction would be extremely helpful and appreciated!

    Thanks!


  • Solution

  • Hmm.

    Since the web app is just a thin wrapper around the heavy-lifting processes, it might be more appropriate to just use something like Sinatra here. Rails is a big framework that pulls in lots of stuff that you won't need for this project, even though it will work.

    Does the "background process" requirement here strictly mean a separate process, or does it just mean concurrency? TweetStream uses the EventMachine gem to handle updates as they come, which uses a separate thread for each connection. It would be quite possible to spawn the TweetStream clients from a simple Sinatra web app, keep them in a big array, have them all run concurrently with no trouble, and simply run stop on a given client when you want it to stop. No need for a database or anything.

    I'm not sure exactly what your prof is looking for you to do here, but MVC doesn't really fit. It's better to work with the requirements than to mush it into a design pattern that doesn't match it :/

    Even so, I <3 Rails! Definitely get on that when you're working primarily with objects being represented in a database :)