Loading repository dataβ¦
Loading repository dataβ¦
ADIthaker / repository
π A command line ecommerce application that uses various middleware communication layers and provides a variety of services given by modern websites
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
The system comprises several interconnected components, each serving a specific role in the functionality of the application. The main components include:
Buyer Server Frontend
Seller Server Frontend
Buyer Server Backend
Seller Server Backend
The server frontends act as intermediaries, receiving requests from clients and establishing connections with the relevant database instances. The database instances consist of the Product Database and Customer Database, each managed by separate server backends. The flow of a typical request follows this sequence:
Client ---REST Request---> Server Frontend ---*gRPC Request + *---> Target Backend Functionality ---MySQL Request---> Database Query
Target Backend Functionality ---SOAP Request---> Financial Server
The current state of the application effectively supports all the functionalities outlined in the specification document. It operates under certain assumptions:
Database Consistency: Sellers and their corresponding items are linked through the seller ID, essentially forming a foreign key relationship. However, the application does not automatically handle the deletion of related objects when the reference object is deleted. Deletion is an independent operation performed by the server and may lack consistency in the event of node failure.
Database Service Availability: The system assumes that the backend database service is consistently operational before starting the server frontend service.
Shopping Cart Handling: The application assumes that the client is responsible for saving the cart when needed. It only retains changes made to the cart in memory until explicitly saved.
Transaction History: The user's transaction history is not stored as a timeline but rather as a snapshot of the cart when the "make purchase" functionality is invoked.
Search Mechanism: The buyer's search functionality attempts to match the existence of the exact keyword as a substring in the concatenated string of all keywords associated with a product.
Same as Client-side buyers interface
Session Timeout: Clients are logged out automatically if there is no client activity for at least five minutes. Displays a warning message one minute before automatic logout.
Stateless frontend: Frontend server components are designed to be stateless. All state is stored in the backend databases (customer and product databases).
Registration and login: A very simple mechanism, e.g. store/transport login name and password in clear text. Allow a buyer or server to login and interact with the server from multiple client machines simultaneously.