This repo holds an Android app that mimics the functionality of Twitter using Java and AWS (API Gateway, Lambda Functions, DynamoDB, SQS).
The app supports:
User registration/login (with secure authentication and best practices, such as password hashing and salting and invalidating auth tokens), profile pictures, and bios
User feed (a collection of all posts of the user's followed list) and stories (a collection of all a given user's posts)
(See a UML description of these relationships here)
A Model View Presenter architecture (MVP) is used to separate logic from the backend:
In addition, a network layered is used as a façade to interface with the backend (abstacting the AWS connections to a single layer).
The model layer contains plain old Java objects (POJO) that simply store the required data:
The view and presenter handle the presentation of the app and connection to the backend (respectively):
For an example of how data is sent through the different layers, see the Login Sequence Diagram:
In the backend, we use Gateway to create a REST API with the required endpoints. The endpoints take the data in the API call and run Lambda Functions. The results of the Lambda Functions are then bundled into the API call's response objects.
Additionally, the feeds are always paginated - meaning we avoid pull excess data while maintaining a smooth user experience.
The Gateway API can be seen in the Tweeter-dev-swagger.json (online tools, such as editor.swagger.io/ can be useful to view the file).
We use DynamoDB to store the user information, posts, and feeds. To see how the databases are formatted, see documentation/DynamoDB Table Descriptions.pdf.
Finally, we use Simple Queue Service (SQS) to pin up multiple lambda functions to update at the feeds after a user posts a new status. Two queues are spun up: one to get the followers of the person who postest the status. The second queue is given those user ids and handles updating the feeds of those users with the new post.
Because two queues are used the following performance requirements are satisfied:
- The perceived latency of the create new status operation (from the perspective of the author) is to be less than 1000 milliseconds.
- When a new status is created, that status is visible in the feeds of all of the followers of the author within 120 seconds, for authors with up to 10K followers.
- Each page of a user's feed is returned in less than 1000 milliseconds, from the perspective of the user.
