Social Network Matchmaking
The Social Network Matchmaking App will be an android application that will allow users to promote matchmaking within their social networks. The app will be created using Java, Google Firebase, NodeJS, and Neo4j.
- 1 Links
- 2 Project Proposal
- 3 Design and Solutions
- 4 Results
- 5 Next Steps
- 6 References
Social Network Matchmaking Log
Online matchmaking has become much more popular in recent years driven by the popularity of online services such as Tinder and Match.com. Most of these apps operate on exposing you to as many people as possible whether that is through geolocation (Tinder, Bumble, etc.) or preferences (Match.com, EHarmony). The central idea behind the Social Network Matchmaking app is to connect individuals to others within their own social networks. Ideally their would be a few crucial benefits to this such as self moderated behavior and better thought out matches.
A common complaint for women in online dating apps is that men will send unwanted crass or explicit messages. Ideally this behavior could be reduced by removing anonymity from the process. For every person that is connected, they are aware that their behavior might be relayed back to their social network.
Another complaint of apps that are based on generating many matches is that the value of an individual match is extremely low. Ideally people that know both people will be able to give a more informed assessment which will lead to better matches, better conversations, and ultimately better relationships.
The planned app will contain two main features: connect with people you know and matching people in your network together.
Connecting with people in Network
Users can search for their friends and send friend requests to them.
Matching people in your network
Users will be able to match their 1st degree connections with other 1st degree connections in their network. When users do this, both of the matched persons will be alerted that someone has matched them together. As more people match them together, they can see that more people believe they would be a good match. Users that have been matched can also at anytime signal that they want to chat with the person they were match with and if both people accept then a chat will be opened between them.
The app will be develop for the android using a combination of Java, Firebase, NodeJS, and Neo4j.
Java is the primary language used to develop android applications. Also considered was the language Kotlin but the decision was ulimtately made to go with Java as I am more familiar with Java and want to prioritize time towards building the backend.
Firebase is a Backend As a Service (BaaS) offered by google. Using firebase will for easy implementation of authentication and database service. Many features of the app such as signing up and maintaining friends list will be handled by Firebase and allow for more time to be devoted to implementing the core features of the app. Firebase uses a NoSql structure. The entire backend could be placed on Firebase but given the complexity of a social network structure and the exponential increase as it gets larger, another database will be used to supplement firebase.
NodeJS and Express will be used as the backend web server and to build the API logic. NodeJS was chosen due to the past experience using it and because of the great support it has for Neo4j.
Neo4j is a graph based database. Neo4j was chosen as the primary database because it was developed with graphs in mind unlike relational databases and has key core functionality built in that will allow for easier implementation of features. It was also chosen because I have no experience using graph databases and I believe that this experience should be a learning one. As I'm unfamiliar with Neo4j, some time will be needed to evaluate the full list of features and ensure that it is possible. Something that should be completed by the final proposal deadline.
The anticipated budget for this project is 0$. This might change if free tier hosting limits in Amazon AWS or Firebase are exceeded.
Design and Solutions
Registration and Login
The first step of creating the app was implementing user authentication and account creation. This feature was a good starting point because it allowed me to become familiar with building Android UI and working with activities. The backend of this feature was implemented using Firebase. Google Firebase has an authentication module that produces a unique user id and handles user authentication and login. Using it in the app was as easy as importing the approbate libraries and learning to use the Firebase api.
On the front end I built a registration page and login page in Android studio using XML and Java. At this stage it was very important to to decide exactly what information is important for users to provide. Because this is ultimately a dating app I decided that the most basic information needed included user's names, ages, location, and gender. We also take user input for an email address and password and pass everything along to to the Firebase authentication api. Whenever a user is created, Firebase assigns them a unique ID. This ID is used throughout to ensure unique friend connections and matches. We also add the user to the FirebaseFirestore database. The Firestore database is a NoSQL database that use a nested hierarchy to store information. We use this to store the user's info. We store the majority of user information here because it is less computationally expensive to retrieve that data from this database. When we add a user we also add them to the Neo4J database. The Neo4j database uses a system of nodes and edges to store information about users. Nodes consist of labels and we can also store information within the node. We label our user nodes as Persons and we also label them by their gender. In addition to this we pass along the ID and the names.
The Neo4j database is much larger and much more computationally extensive than relational databases and because of this we don't want to use it as our primary database. The Neo4j database is also not well suited for certain tasks. Things like chat would not work well in a graph database. These are all things I have to keep in mind.
The creation of the api for the Neo4j database is more intensive than the Firebase API. To access the database from online we have to use a web server and we need to use a server side language to communicate between the API, the app, and the database. To accomplish this we use Amazon AWS EC2 cloud server along with NodeJS and Express. Using express we can create 'routes' that make it very easy to process url requests to our server. We structure these routes based on the three core functionalities we will be using our server for: creating users, handling friending features, and handling matching features. We also install Neo4j in the server. This allows us to make calls to the server from online using ports. This also allows us to use Neo4j's interactive database explorer in the browser. This helps to quickly check the information we are placing in the database.
(Labels: Person, Gender)
"name": <String>, "id": <String>
"age":<String> "city":<String> "name": <String>, "gender": <String> "img_url":<String>
Adding friends was created in Firebase and Neo4j although we only really use the Neo4j to add the friends. We also created the list in Firebase because we wanted to reduce the amount of queries that we sent to the Neo4j server. By having the list in Firebase we can easily pull a list of friends from there. On adding friends we use the Neo4j to handle the friend request functionality and the suggested friend functionality. We can query based on directions to different nodes and this allows us to pull all friend requests pointing to the user for example with a simple command.
For Matching we used Neo4j. Whenever someone matches two people we create an edge between them in our graph. We pull this information using a query. For suggesting matches we also use Neo4j. We pull a list of potential matches using algorithms.
We implement the chat feature using Firebase