Week 13 Subscriptions and Cursors
Working with Meteor: automating modifications to the hashtag database.
Streamlining the app
Originally, the implementation of Hashtag collection additions and look-up required a number of “manual” code modifications. This week, I refactored the code to leverage the database functionalities in Mongo / Meteor.
Rather than publishing many versions of the Tweet database, the client-side subscription takes the relevant hashtag as an argument, and passes this to the server which then provides the appropriate publication - the tweets filtered on the appropriate hashtag. There is a fall-back defaulting to the “occupy” hashtag, if the app cannot access the geolocation of the client’s device, or if there is no hashtag paired with that location.
Previously, there was a separate array to track the hashtags and make a Twitter API query - however, this was inefficient. By utilizing the functionality of the Mongo find() command to return a cursor that can be used as a dynamically-updated array, the Hashtag collection now also functions as the basis for the Twitter REST API call.
Template mods
I’ve also restructured the application so that Meteor appends a header HTML block with references to css and Google fonts. I based the application file structure on The Meteor Chef recommendations, resulting in a more maintainable and legible code base.
Stream vs REST
This is the major decision that still needs to be made. Currently, I’m using the Twitter REST API to request the last 20 tweets for each hashtag in the database. This approach has several limitations:
- Dilution of the concept of merging two simultaneous, multi-sited events
- Age-til-die-off is often inappropriate - this needs to be normalized per hashtag
The REST API does have a few advantages:
- Predictable number of query results
- Static database once the app is running
- Ensures that tweets will be present in the AR frame, even if there isn’t a lot of recent activity on the hashtag
- Provides a framework for future deployment with historic tweet data (ie as part of Invisible Monument)
I think the best approach is to blend the two - to make an initial REST query when the app initializes, to ensure that there is a corpus of tweets to display in the AR frame. The age-til-die-off might be normalized based on the results of the initial query. Then as the app runs, it will connect to a multi-channel stream. Tweets will be added to the database - up to 100 per hashtag. Once the limit is reached, the database will delete the oldest tweet as each new one arrives.
Next steps
The REST API has already been implemented, so implementing the stream is not mission-critical at this time. At this time I’ve got a number of pressing issues to finalize the documentation page.
- Normalizing age-til-die-off
- Styling the documentation page
- Adding a map to the documentation page
- Using accelerometer data to change the tweet positions
- Styling the tweets
- Deploying annotatAR on Digital Ocean