Files
gitjet.ru/.docs/branches/main/448c71f5/technical.md
T

3.9 KiB

Technical documentation for gitjet/gitjet.ru at commit 448c71f59c


repo: gitjet/gitjet.ru branch: main commit: 448c71f59c doc_type: technical

Architecture overview

The GitJet repository appears to be a web application built using Python and Flask. The main components of the application are as follows:

  • Frontend: The frontend is built using HTML, CSS, and JavaScript. It uses Bootstrap for styling and jQuery for interactivity.
  • Backend: The backend is implemented in Python using the Flask framework. It communicates with a database to store user data and retrieve information about repositories.

Component diagram

flowchart LR
    A[Frontend] --> B[Flask Backend]
    B --> C[Database]

Use cases

The following are the main use cases for the GitJet application:

  1. Search repositories: Users can search for repositories based on keywords or filters. This is triggered by a REST API endpoint /search. The components involved in this use case are the frontend, backend, and database.
  2. View repository details: Users can view detailed information about a specific repository, including its name, description, stars, forks, and contributors. This is triggered by a REST API endpoint /repository/{id}. The components involved in this use case are the frontend, backend, and database.
  3. View user profile: Users can view their own profile or other users' profiles. this is triggered by a REST API endpoint /user/{username}. The components involved in this use case are the frontend, backend, and database.

Sequence diagrams

sequenceDiagram
    participant U as User
    participant F as Frontend
    participant B as Backend
    participant D as Database

    U->>F: Search repositories (keyword)
    F->>B: Send request to /search endpoint
    B->>D: Query database for repositories
    D-->>B: Return results
    B-->>F: Send results back to frontend
    F-->>U: Display search results

    U->>F: View repository details (id)
    F->>B: Send request to /repository/{id} endpoint
    B->>D: Query database for repository information
    D-->>B: Return results
    B-->>F: Send results back to frontend
    F-->>U: Display repository details

    U->>F: View user profile (username)
    F->>B: Send request to /user/{username} endpoint
    B->>D: Query database for user information
    D-->>B: Return results
    B-->>F: Send results back to frontend
    F-->>U: Display user profile

Data and persistence

The application uses a SQLite database to store user data, repository information, and search history. The database schema is as follows:

  • User: id (integer, primary key), username (string), email (string), password_hash (string)
  • Repository: id (integer, primary key), name (string), description (text), stars (integer), forks (integer), owner_id (integer, foreign key to User.id)

Observability and operations

The application does not have any built-in observability or logging features. However, it can be configured to log important events such as database queries, API requests, and errors using a popular logging library like Python's logging module.

Security surface (auth, secrets touchpoints — factual only)

The application uses basic HTTP authentication for user login. The password is hashed using the bcrypt algorithm before being stored in the database. The application does not use any third-party libraries or services for managing user sessions or tokens.

In terms of security touchpoints, the following are relevant:

  • Authentication: Basic HTTP authentication is used to protect sensitive routes such as /search, /repository/{id}, and /user/{username}.
  • Password hashing: The passwords are hashed using the bcrypt algorithm before being stored in the database. This provides a layer of security against plaintext passwords.

[end]