The 5-Minute Interview: Rachel Lader, Software Engineer at Clippr


Catch This Week’s 5-Minute Interview with Rachel Lader, Software Engineer at AppleFor this week’s 5-Minute Interview, I caught up with Rachel Lader, a Software Engineer at Apple. Here’s what we talked about:

Editor’s Note: Rachel’s work with Clippr is not in any way affiliated with her position at Apple, Inc. as the project was completed during her time at MakerSquare.

Q: Talk to me about one of your favorite Neo4j projects.


Rachel Lader: My most recent project was called Clippr, and basically its goal was to reinvent the way people interact with their favorite websites. We found that the problem right now was that people were bookmarking sites, and when they went to find the website it was a just a list of black and gray words, and they couldn’t remember the title or when they bookmarked it.

With Clippr, we had three points that we wanted to change. The first was that we implemented a naive Bayes machine learning algorithm that would automatically categorize the bookmarks at the time that they were chosen so we created terms and categories, and it went through our trainer and classified it.

We also wanted to be able to provide suggestions from keywords that we extracted, and we also wanted to provide visual snapshots so that the user could actually see the site so when they logged onto the website they saw exactly what they bookmarked rather than having to search the title. Those are the main things that Clippr was trying to change about bookmarks and the existing process.

Neo4j fit perfectly into that because it not only let us say that each node we created was related, but it also let us define the exact relationship between the nodes and even on top of that, we use adding properties to that relationship. It was super valuable to us because when we extracted the keywords, we were able to define specificity and how strongly they were related to each clip, and we used that to power the suggestions.

We had worked with SQL databases before with JOINs and everything like that, but we found from two days of learning Cypher and picking up that language, that we were able to query pretty much anything we wanted in one line versus having to worry about massive JOINs and all of those intricate operations, so it really worked out perfectly for us.

We also found that the Neo4j Browser really was amazing because it was not only great to see all of our data in one place, but it was great for debugging also because we could test any query before writing a line of code.

Q: What were some of your most surprising results while you were working with Neo4j?


Rachel: Our long-term vision for the project involved being able to provide suggestions not only on external API calls but on how closely they were related to another user. Essentially, we were trying to tap further into the power of finding users who had bookmarked similar content.

With Neo4j, we could do a query in all of one line that said, “Find me all users who have bookmarked sets of this title,” and then we could grab suggestions that the other user had come up with and populate it. We could easily connect the users together and see how they were linked together in a really cool way.

Q: Can you talk to me about why you guys chose Neo4j? What made it stand out?


Rachel: The biggest thing was the fact that you could not only see how different entities were related, but how they were related and to be able to dynamically change and alter our schema as we went along.

We found especially in the fast-paced environment that we were working in that the project was constantly evolving. We were constantly thinking of new things we wanted to add so rather than having to edit our schemas and redo all of our data. If we decided that we wanted to do separate nodes, we could easily create one and label it at that moment or easily create a new relationship on nodes that already exist without having to worry about changing everything as we always had done in the past.

Q: If you could start over completely with Neo4j, what would you do differently?


Rachel: It went very smoothly for us but what would I do differently? Sometimes there were times when we wanted to delete a specific node, and then we realized that it had relationships so we couldn’t just dynamically delete it and things like that.

We also got ourselves really deep into a callback hell system because we had this map and a lot of data coming in at once, put it all through one function. I think that one thing I would do is really just think about the relationships that outline maybe the key functions and queries before I ever wrote the code and see how those functions all relate to each other. Because sometimes it was a much easier Cypher query than maybe we were even thinking about, and there were things that Cypher provided that maybe if we looked deeper into it, it wasn’t as complex as we made it.

That being said, the queries that we wrote were so infinitely shorter than what we had done in the past so we didn’t run into any major hiccups with it.

Q: Anything else you want to add or say?


Rachel: A lot of people are hesitant to jump into a new database because of the query language and using Cypher.

One thing I did want to mention was that I was developing with Node.js and Express.js on my backend server, and we used Seraph as kind of like an ORM to connect with our database and it was so easy.

And a really cool thing about that was that we were able to put raw Cypher queries straight into our Node server, which on some of the other ORMs it was kind of more like you didn’t really know what was going on behind the scenes, but this let us query for exactly what we were looking for. I just want to emphasize Cypher was super easy to pick up, and it was well worth the adjustment.

Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at content@neotechnology.com


Want to try out a graph database for your next project? Click below to get your free copy of Learning Neo4j and catch up to speed with the world’s leading graph database.