Ios app - Backend Development

This document describes the different parts of the backend (be) we need to build to support the ph client apps (mobile).

As a general rule all transactions (even GET requests) in all services should be persisted, and stored in cloud storage to allow further analysis on the data. Ideally technologies like bigTable or redshift should be used.

Another thing to have in mind is the technology used to run the services. It should scale easily in an horizontal fashion (with a load balancer as front­end). Ideally technologies like appEngine, docker or AWS’s elastic computing should be used.


Systems:

1) User
The user system persists the user personal data including:
● userId, name, email, DOB, city or zipcode, country
● user’s impact score,
● login credentials
● social network tokens (twitter, fb, etc..)

And it’s API allows querying and modifying the data stored.
There has to be a minimal security check where user’s are only allowed to modify their own data, so API should only support authenticated requests.

Technology:
For the storage layer a NOSQL database (Cassandra, Google cloud datastore, or similar) should be used, this will enable for scale.

2) Social graph
This service manages the following/follower model and it’s API should allow:
*­ getting the list of followers for a certain user
­* getting the list of users a particular user is following
­*  get a count of followers/following without querying the actual list of users.
­* The API should support pagination

Technology:
a NOSQL like db should be good enough as graph datastores are still a bit immature.

3) Stories store
This service stores all of the stories content, where the API should support:
*­ create new stories
­* update stories (modify, add some data)
­* delete
* rate a story
­* verify story
­* image upload endpoint (will probably have to support transcoding)

All the API calls should be authenticated and enforce mutable actions to be done either by the story owner or an admin account
The data stored for each story should contain: reference to the user who created the story an the user tagged as a hero once the story is verified.

Technology
A nosql datastore could be used for the metadata and a cloud storage service like gcs or s3 should be used for the actual image storage.

4) Feed Service
The backend for the feed service could be simplified by using ElasticSearch (or similar technology) initially so the stories get indexed and queries can be done on the fly to fetch a feed for the user. The api should allow for queries to the indexed pool of stories using filters such as:
­ * order by popularity
­ * filter by location
­ * filter by social graph

Technology
ElasticSearch or similar

5) Real-Time pipeline
A pipeline subscribed to the story creation events is needed, to trigger:
­* re­indexing in the feed service
­* Trigger notifications

Technology: something similar to kafka can be used.

In addition to this BE services, we would need an administration webpage to be able to access at least the user and stories API to perform actions like:
­ add/delete/modify user
­ add/delete/modify story
Just admin users should be granted with privileges to modify this: