Lightning Talk: Building a RethinkDB Module for Meteor (Video)

Last week a former graduate of Hack Reactor's programming boot camp, Tuhin Chakraborty, conducted a lightning talk (five minute presentation) about building a RethinkDB module for Meteor. Tuhin is currently a member of our school's Hacker in Residence program, which employs former grads part-time to assist with debugging projects, teaching code and working with applicants through our customized interview process.

Below is a video and transcription of Tuhin's talk. Enjoy!

Building a RethinkDB Module for Meteor

How many of you guys love MongoDB? (Hands go up.) Ok, we're probably not going to be friends after this presentation, haha.

I was working at a startup and I learned about reactivity - that's how I first got into Meteor. When I started using it, it really felt like magic. And I wanted to figure out how the backend was working, and that's one of the reasons I got into this project. I sincerely, in my heart of hearts, believe it's the future of the Internet.

However, I was so disappointed because I had this feeling inside of me that Mongo is not what people should be using. It's a really great tool for prototyping, but around the time I started doing research, I was reading a lot of press on the Internet that Mongo had trouble scaling, and there were questions about how it would function in a production environment. And people were saying that their data was disappearing. I wasn't really a fan of their syntax. There's some difficulties involved with deploying Mongo in a sharded environment.

So, RethinkDB has an awesome syntax. It was created with a production environment in mind. It's really robust, it's scaleable. It's like the second generation of NoSQL databases. There are some weaknesses, but there are weaknesses with everything. Rethink only works with the newest version of Node. Meteor ships with version eight. It all started with a backwards compatibility hack for the Rethink driver. I have tables.js validated: [ 'instert', 'update', 'remove'].

Mini Rethink I wrote. It's a JavaScript version of Rethink that sits on the client side and it works with Meteor syntax as well as beautiful, wonderful syntax. I have a Rethink cursor that I implemented and Meteor's code is very modular. That's the reason I was able to do this in the first place. Every single piece is so well separated I was able to create a Rethink cursor that worked with the subscribe and publish functionality that already exists.

What's Next for the RethinkDB Module for Meteor?

This is a little map that I drew for myself. As I was digging into Meteor's source it was difficult to keep the entire thing in my head. On the right, you'll see what actually happens in Meteor right now. Query to Mongo returns a cursor which returns a live result set, and the live result set does an initial caching, and then it uses long polling to pull the data base every ten seconds and then broadcast those changes to the client.

The question I asked myself when I got to this point was can this be avoided? Do we need a live result set?

When you insert a document or you update a document, particularly with RethinkDB, you  get a callback that tells you exactly what's been updated, so we don't need to use a diffing algorithm to figure out what the changes in the database were. The other thing that Rethink is working on right now is a database trigger and those triggers will happen on the database and bubble up all the way to the client side.

If that is possible, we won't need live result sets at all, or any kind of polling.

Audience Questions about Building a RethinkDB Module for Meteor

Can we use it today?

It's not live, it's a work in progress. I've only had about 10-14 days to work on it. I'm looking for contributors. If you want to contribute, please let me know!

Is this a mental exercise?

Haha. No, this is not a mental exercise. By the time it's complete, by the time it catches up to Mongo, it will be a better version of what exists today.