Over a million developers have joined DZone.

Case Study: How KinCards Used Neo4j to Revolutionize Business Cards

DZone's Guide to

Case Study: How KinCards Used Neo4j to Revolutionize Business Cards

KinCards has used Neo4j to help manage the data of all the complex interpersonal relationships individuals can have.

· Big Data Zone
Free Resource

See how the beta release of Kubernetes on DC/OS 1.10 delivers the most robust platform for building & operating data-intensive, containerized apps. Register now for tech preview.

Learn How KinCards Used the Neo4j Graph Database to Revolutionize the World of Business CardsBusiness cards: We forget them, lose them or run out of them – usually when we need them most.

Just think how many times you’ve said, “I’m sorry. I don’t have my business cards with me,” or “I just ran out of business cards.”

After enough hassle carrying, sharing and managing business cards, I decided to found KinCards. Once I set to work, I knew we needed a technology that was fast, reliable and robust, not to mention scalable and efficient at managing complex relationships. After a lot of research, the answer was obvious: Neo4j.

Here’s the story of how my team and I used Neo4j to take a concept and turn it into a successful business card app.

How We Got Started

A little background: KinCards lets you create and personalize your own virtual business card and share your contact information immediately. Your connections can then easily exchange, collect and store KinCards. Your contact information is never shared publicly, and access to your information is provided only upon your approval.

As you can see, all these features would require multiple levels of relationships and complex business logic. With Neo4j, it was easy.

Why We Chose Neo4j

We knew we needed to use a robust NoSQL database that could handle relationships well. The database had to handle large volumes of data yet still return results in milliseconds. We had so much on our plate to work on, and the last thing we wanted to do was to spend too much time learning a new database.

Initially, we compared Neo4j, InfiniteDB and FlockDB for KinCards, but when it came down to meeting our challenges and requirements, Neo4j was the solution for us.

Our team had zero experience with graph databases when we started working on KinCards. Fortunately, Neo4j provided an intuitive platform that was straightforward to learn and implement. Their startup program also offered all the support and resources we needed.

How We Used Neo4j to Build KinCards

Using Neo4j, we built our solution from the ground up within no time.

Within KinCards there are various workflows to share a KinCard with other users and to add others’ KinCards to your own dashboard. All of these complex workflows and ever-increasing relationships are managed by Neo4j in the backend.

Since we have to store not only a large amount of user data but also the relationships between users, Neo4j was the perfect fit for our database since it stores data and data relationships.

Our Results

KinCards is quickly gaining popularity, and with Neo4j we are successfully able to handle all the load, still returning blazingly fast results. Even as we grow, we are seeing great outcomes in terms of response time, flexibility, scalability and availability.

The KinCards team is always gathering new feedback from users and adding new features to the app. With Neo4j, we have a very flexible database model that allows us to quickly make modifications to our existing setup, so adding a new feature or functionality is never painstaking on the database end.

KinCards was created with one goal in mind: Eliminate physical business cards. With Neo4j, we’re getting there one data relationship at a time.

Interested in KinCards? Sign up here.

Editor's note: This article was written by Prashant Yadav, Founder of KinCards.

New Mesosphere DC/OS 1.10: Production-proven reliability, security & scalability for fast-data, modern apps. Register now for a live demo.

big data ,neo4j ,big data applications

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}