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'].
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.