A pure-java implementation of Twitter's server using a REST API and no additional frameworks.
This project has been done as the final project of the advanced programming course in AUT. As one of the projects' constraints, use of any backened-related frameworks was not allowed (e.g. Spring Boot etc).
For addressing various needs in the Twitter server such as the database, serialization etc, different technologies were researched carefully and then chosen:
Regarding the relational nature of most of the saved data in the project, MySQL database was chosen as a robust and scalable SQL database that provides one with many feasible features. Some others databases were also investigated such as PostgreSQL and MongoDB but MySQL still seemed like a better fit for my use. Querying the database was done using SQL queries only.
used libraries:
As one of the most robust and vastly used serialization protocols, JSON was used, but for larger data structures (photos, videos etc) Apache Commons IO was utilized as the serializer/deserializer.
used libraries:
A REST API was designed and implemented from scratch using HttpServer library (built-in to java). For method validation, request format validation, sending responses etc no frameworks were used due to project constraints.
used libraries:
To address various neeeds in the project and also achieving important software engineering principles such as separation of concerns, encapsulation, maintainability, scalability, etc, many different design patterns were used:
• As the main communication way between the server and the client, RSET API was used. After the needed methods were identified, related actions were put in the well-defined hierarchy of the API which separated them according to their responsibilities.
An ER schema of the implemented design is shown below:
• The main design in the server part was The Layered architecture as it could best help encapsulate different components and separate the concerns of accessing data (both on disk and database) from concerns of request handling and controlling.
• Although the MVVM design pattern is mostly related to the client part, but in the whole project (server and client together) the so-called Model components were kept in a module named Commons and were only used as data entities with no buissiness related logic in them.
The UML schema for the commons module can be seen below:
• DAO design pattern was effectively applied in the database part to encapsulate the database access logic from other parts. each table in the database has a corresponding class which is the only class that can add, remove or modify the data in that table.
The database schematic can be seen below:
• Using a logger for better monitoring the server
• Keeping hashed passwords instead of actuall passwords in the database
• Encrypting the Http connection between the server and the client
• Putting server configurations in a separate file instead of hardcoding.