Ever wish you could trade Twitter timelines with someone for a day? Or just a few minutes?
weeve goes one step further, allowing groups of Twitter users to combine their timelines to create an uber-timeline. Try it out - join the weeve at http://weeve.dzello.com/.
I created weeve in 2 days over the winter holiday as a fun way to get hands-on with some new tech. My goals for weeve were:
- to play with some APIs I’d been hearing a lot about
- to build a server-less app using a Backend-as-a-Service
- to open-source the project for others to benefit from
- to build something useful that could help people discover new content on Twitter
- to distract me lest I consume hordes of delicious holiday foods
All but one of those goals was accomplished. :)
In this blog post I’ll talk about how weeve works and APIs that made it possible.
These APIs, and the companies behind them, are doing great things. It’s no coincidence I chose them to hack on. Here they are, including a brief summary of what they do in (mostly) my own words.
Firebase - https://firebase.com/
Example code, taken from writing data in the Firebase docs:
1 2 3 4 5 6 7 8
Keen IO - https://keen.io/
Example code, taken from weeve:
1 2 3 4 5 6
Singly - https://singly.com/
Singly is the intelligent, unifying proxy for social network APIs you asked Santa for this year. Singly already has support for over 35 services. One thing I love about Singly is that their APIs are open source.
And if that wasn’t enough, Singly is also behind The Locker Project, which has the bad-ass mission of making it possible for you to keep track of the mountains of personal data you spread around the nets. It’s like insurance for the next time this happens: “All Online Data Lost After Internet Crash”.
Example code using the profile Singly endpoint:
1 2 3 4 5 6 7
The following services and libraries are also used by weeve.
Twitter - https://twitter.com/
When people say ‘the twitters’ they really just mean Twitter.
jQuery, Bootstrap, Backbone, twitter-text, socket.io, CDNJS & more
Get the full list on the Github README.
How weeve works
weeve has no server. weeve is just an HTML page, a JS file, and a CSS file. You can deploy weeve under to any static web server like Apache and nginx, or to Github Pages.
Despite being flat, weeve has a host of features that traditionally require a server:
Singly proxies the OAuth conversation with Twitter. Then, Singly creates a Firebase authentication token and hands it back to weeve as a location fragment. The weeve Backbone router uses the token to establish a faux ‘session’ backed by localStorage, so the authentication persists across page refreshes. Read more about this flow here - Firebase Authentication Setup and here.
Central data storage
Firebase is used to store data in a way that’s accessible to all clients, yet still secure. User A cannot tamper with User B’s data, etc. See the weeve security rules JSON definition to see what’s defined.
Shared messaging layer
Clients get notifications about what’s going on by binding to Firebase data references. Everything happens in real-time and neatly stays in sync. weeve uses Firebase ‘on’ bindings to reflect the presence of users and to add tweets to the uber-timeline.
weeve uses Keen IO to display who’s contributing the most tweets (pie chart), how many total weevers there are (number), and recent tweet volume as a series (line graph).
weeve uses the user stream endpoint of the Twitter streaming API. Tweets appear instantaneously; as in the instant someone pushes ‘send’. It’s quite thrilling.
Get the code
weeve is open source. You can read the annotated source code and learn how to host your own weeve(s) on Github at dzello/weeve.
If you’re looking to build something with one or more of these APIs, definitely check out the repo - there’s a good chance you might find a relevant example of something you’d like to do.
I’m very happy with the way things turned out. I started with quite a few unknows and estimated at least a few unsightly hacks would be required to get it all working.
The streaming proxy was the only ‘hack’ required. I think that says a lot about the feasability of these API’s for pure-client-side development and the readiness of backend-as-a-service providers for real-world HTML5 apps.
And what’s positively mind-altering is that there’s no server to scale,
deploys are sub-second (
cp baby), and the heavy lifting is distributed across the browsers of your users and
your API providers. Quite literally, I’m already thinking about new domains this topology can be applied to.
Overall, I’m excited to see what other apps & patterns emerge as developers consider ‘staying off the server’.
Now then. Why not head over to a weeve and try it out?