This week’s 5-minute interview is with Aseem Kishore. Aseem is the Web Engineering Lead at FiftyThree, the makers of the popular iOS app, Paper. I sat down to chat with Aseem at GraphConnect San Francisco.Q: Talk to me about how Paper uses Neo4j.
Aseem: Paper is an app for capturing your ideas, but it also has a lot of social and collaboration features built into it. It allows you to share your ideas, follow other Paper users, remix their ideas and get inspiration from others. We’re working on even more stuff, and all of that is part of Neo4j on the backend.
Q: Why did you guys choose Neo4j over other options?
Aseem: When we first started, we knew that we had a very interconnected domain and data model, and it felt like implementing it in any relational or key-value data store would be pretty tricky. We also knew that we would be implementing a lot ourselves, so we did some research and we discovered Neo4j. It was a “Wow!” experience and was a good fit.
Q: What are some of the most interesting results you’ve seen while using Neo4j?
Aseem: We have a notion that ideas can remix with other ideas, and so then you get this tree of remixes, and when we were developing the web version of Paper and the collaborative layer early on, we experimented with a few different ways to convey that.
One approach we considered was to show direct remixes kind of like YouTube video comments, as if they were inline comments. Once you clicked on that one, and then you can see its remixes and all that stuff.
But ultimately we realized that’s too many clicks to navigate this tree and users don’t really think in terms of trees. They just think in terms of a list of related stuff, and we wanted the remixes to convey a story.
So, what we do now is we actually create the whole tree and sort it in an interesting way, and we return that directly. That kind of query – being able to do that without denormalizing the data or precomputing the list – was pretty powerful.
Q: If you could go back and start all over again with Neo4j, what would you do different?
Aseem: That’s a good question. I just started my GraphConnect talk with a lesson learned that if I were to do it again, I would not have monolithic nodes that contain disparate types of data.
An example that I shared was our user nodes contain account information, social information (like followers and following) and social profile information like your bio and profile pic. They also contain stuff like your backups. User nodes are also connected to your notifications and your ideas.
All that information means there is a lot of contention if you start getting to a point with high write throughput. I’ve also learned that as the number of properties on a node get bigger and bigger, performance starts degrading.
What I would do differently is break out those categories into their own separate nodes while keeping those nodes still connected. That way you could get the whole picture if you wanted, but you wouldn’t have to if you didn’t need it. For example, you’d have a user account node that’s separate from a user profile node and separate from a user home stream node.
Q: Anything else you want to add or say about Paper or Neo4j?
Aseem: We’re always excited to come out here because it’s getting the insight and glimpse into the roadmap is always very educational and helpful. We’re really excited about Neo4j 2.3, but especially 3.0 and all the stuff coming out of that release. And it’s always nice to be part of this community and ecosystem.
Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at content@neotechnology.com
Ready to master the world’s leading graph database? Click below to get your free copy of Learning Neo4j and get started on a graph database project today.
