Enriching mobile apps with social networking experience using Go and Redis

Every mobile app these days is using some social network integration for making the application more unique and more attractive for the different range of users. Social network experience and gamification are two very important parts of every mobile app doesn‘t matter in which category the application belong, Lifestyle, Entertainment, Sport, Education, Healthcare or E commerce, every mobile app is using some social integration. For making the application more popular and more attractive not only the beautiful user interface ( UI ) is required but also there are other conditions like ( user experience ) UX and user interaction within the application.

Social networking is enriching UX which keep the users busy interacting with each other in the application, making them to stay longer and to use it more actively in the every day life as part of their life, in other words social network experience makes the users more addictive to the application. Social network interaction affects also on easy attracting and targeting specific users groups and makes the application organically grow which is very important for every business model.

But implementing social experience in the application could be very interesting and challenging job because of so many social services on the web with the same or similar options they provide and obstacles for implementation, for example service which provide API for setting the photo or the product as favorite, setting like or rate on the photo / product, sharing the photo / product with the friends / followers, recommendation based on some criteria or Geo location etc.

Its very important to notice that for most of the services using some proprietary SDK is required which makes our app vulnerable of leaking the data and using it for different purposes.

In this tutorial we will see how easy is to implement personal social service and use it to make the mobile application more unique and more attractive for the end users. Our goal is to implement standalone restful microservice which will provide some mostly used social functionality like we mention before, favorites, followers, likes, rates etc.

Because of the simplicity and performance we’ll implement our microservice in the Go lang using Redis NoSQL as a data store.

Required basic endpoints for following and favorites social events:

  • /set_relation – endpoint required for setting / unsetting follow relation
  • /list_following – endpoint required for listing users which user X is following.
  • /list_followed – endpoint required for listing users that follows user X
  • /list_connections_stat – endpoint required for listing simple info, how many users are following the user X and how many users, user X is following
  • /add_favorite – add something favorite for user X
  • /remove_favorite – remove favorite from user X
  • /list_favorites – list user X favorites

Short microservice explanation:

This microservice is using two databases MySQL RDBMS, the most popular open source RDBMS, and Redis NoSQL, the most popular data structure NoSQL.

Why two databases when everything can be stored at only one?

Suppose we have application which is used daily from thousands of concurrent users which require fast access to the user social information and must fast calculate statistics in the realtime, using only RDBMS is not enough. In the RDBMS we’ll store data which is not often modified, like user profile, image infos, video infos, news, statuses etc. Following the best practices of popular social networks like Facebook, Instagram and many other companies that make realtime statistics, NoSQL DB is required because of easy horizontal scaling and fast realtime access to specific information used in different cases. In our case Redis NoSQL is selected as most adequate DB for storing dynamic data like user relations, indexes for favorites, number of visits, storing social likes, storing and calculating social rates also using it for basic analytic’s etc.

Because of the many Redis client libraries for Go, decision for using the client lib is left to the developer, in this tutorial we use “github.com/go-redis/redis” but first we will use only Redis commands for explaining the logic and later we’ll see only the specific pieces of code how this is implemented in Go.

Following event:

Following event is very popular social event implemented in every social network which describe relation between two users.

For example:

Scenario 1:

User A is following User B, User A → User B

Scenario 2:

User A is followed by User C, User C → User A

User A is following User C, User A → User C

In this short example we see 2 scenarios where in the first one relationship is only in the one way or single direction and the second one is in both ways or bi-directional relationship.

What does it mean in one way or in two ways?

In the simple social network, in the first relation, when the User B trigger some social event, for example, upload new photo, write new comment, write new status, User A will be notified for that event but when the User A trigger some social event this event will not notify the User B because the User A is following the User B and User B is not following User A. In the second scenario we have bi-directional relationship where the User C is following User A but also User A is following User C, which means that when one of them will trigger social event the other will receive notification, doesn’t matter which one, User A or User C because they are both in relationship.

How is this implemented with simple Redis commands?

We will use Redis Set data structure for keeping user IDs which are in relation and simple incremental Key for getting fast information about number of relations for specific user instead of counting the Set structure.

In our example we will describe one way relationship where User A is with ID: 1111111111 and User B is with ID: 2222222222.

SADD user:1111111111:following 2222222222
SADD user:2222222222:followed 1111111111

INCR user:1111111111:followingNo
INCR user:2222222222:followedNo

So for bi-directional relationship we will duplicate SETs and KEYs, but bi-directional relationship can only happened when the second user decide to follow the first user, or, if User A is following User B, for bi-directional relationship User B must also follow User A, like in the second scenario from the first example with bi-directional relationship between User A and User C.

Removing the relation is also easy, using Redis command SREM will remove specific ID from the specific Set.

SREM user:1111111111:following 2222222222
SREM user:2222222222:following 1111111111

But also we need to decrement the users counter with the command DECR.

DECR user:1111111111:followingNo
DECR user:2222222222:followedNo

With simple call of the Redis command bellow, we can extract all user ids from the SET of the User A, which User A is following:

SMEMBERS user:1111111111:following

Or for the extraction of the users id which follow the User A we are only changing the last part of the key because those user ids are stored in the other SET, so:

SMEMBERS user:1111111111:followed

If we want to check if some user is followed by some other or is following some other user, we can use Redis command for checking if some value exist in the specific SET, SISMEMBER, so,

SISMEMBER user:1111111111:following 2222222222

or:

SISMEMBER user:2222222222:followed 1111111111

Implementation in Go lang is straightforward but we will see only the methods important for the routes, database connection and setting the relationship.

main.go

routes.go

handlers.go

dbconnection.go

userscontroller.go

Compiling the source code is not enought for proper testing. Because we are using 2 databases, first we need to have them installed somewhere and then configured in the dbconnection.go. Also we need to modify the simple SQL query in userscontroller.go to match existing DB schema.

The rest of the service is available on the GitHub.

Print Friendly

Leave a Comment

Your email address will not be published. Required fields are marked *