{"id":26962259,"url":"https://github.com/yavarguliyev/invoice_hub_microservices_express_js","last_synced_at":"2026-04-12T06:35:13.351Z","repository":{"id":282293743,"uuid":"936712062","full_name":"yavarguliyev/invoice_hub_microservices_express_js","owner":"yavarguliyev","description":"Invoice-hub-microservices","archived":false,"fork":false,"pushed_at":"2025-10-26T14:47:02.000Z","size":3239,"stargazers_count":1,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2026-01-03T13:43:43.921Z","etag":null,"topics":["dependency-injection-pattern","design-patterns","docker","docker-compose","factory-pattern","inversion-of-control","kafka","microservices","nginx","nodejs","oop","postgresql","redis","routing-controllers","singelton-pattern","solid","typeorm","typescript","winston","yarn-workspaces"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/yavarguliyev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-02-21T14:57:04.000Z","updated_at":"2025-10-26T14:47:05.000Z","dependencies_parsed_at":"2025-08-05T10:35:41.909Z","dependency_job_id":null,"html_url":"https://github.com/yavarguliyev/invoice_hub_microservices_express_js","commit_stats":null,"previous_names":["yavarguliyev/invoice_hub_microservices","yavarguliyev/invoice_hub_microservices_express_js"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/yavarguliyev/invoice_hub_microservices_express_js","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/yavarguliyev%2Finvoice_hub_microservices_express_js","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/yavarguliyev%2Finvoice_hub_microservices_express_js/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/yavarguliyev%2Finvoice_hub_microservices_express_js/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/yavarguliyev%2Finvoice_hub_microservices_express_js/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/yavarguliyev","download_url":"https://codeload.github.com/yavarguliyev/invoice_hub_microservices_express_js/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/yavarguliyev%2Finvoice_hub_microservices_express_js/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31504897,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-07T03:10:19.677Z","status":"ssl_error","status_checked_at":"2026-04-07T03:10:13.982Z","response_time":105,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dependency-injection-pattern","design-patterns","docker","docker-compose","factory-pattern","inversion-of-control","kafka","microservices","nginx","nodejs","oop","postgresql","redis","routing-controllers","singelton-pattern","solid","typeorm","typescript","winston","yarn-workspaces"],"created_at":"2025-04-03T05:19:34.319Z","updated_at":"2026-04-07T08:01:45.016Z","avatar_url":"https://github.com/yavarguliyev.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Project Overview\n\n##### This Node.js application is built using a microservices architecture, designed for scalability, modularity, and maintainability. It uses TypeScript for strong typing and integrates key technologies such as ExpressJS, PostgreSQL, Redis, Apache Kafka, REST APIs, and Docker to ensure optimal performance and flexibility in scaling individual services. The application applies multiple design patterns and software engineering principles to promote clean, maintainable, and testable code.\n\n---\n\n# 📖 Table of Contents\n\n1. Features\n2. Architecture Overview\n3. Interaction Flow in Microservices and Architecture\n4. Domain-Driven Design Principles and Patterns\n5. Design Patterns\n6. Principles\n7. Technologies\n8. Getting Started\n9. Project Structure\n10. API Documentation\n11. Running the Application\n12. Running Tests\n13. Usage\n14. Contributing\n15. License\n\n---\n\n# ✨ Features\n\n## Order Management\n* **Order Creation and Lifecycle Management**\n  * Creates orders with initial PENDING status with user association\n  * Uses distributed transactions to ensure data consistency across services\n  * Supports order approval flow with automatic invoice generation\n  * Handles order cancellation with compensation actions\n  * Publishes events on state changes via Kafka\n\n* **Order Retrieval and Querying**\n  * Fetches paginated lists of orders with filtering and sorting options\n  * Optimizes data retrieval with Redis caching\n  * Implements DataLoader pattern for efficient batch loading\n  * Provides order details with associated user information\n\n## Invoice Management\n* **Invoice Generation and Processing**\n  * Automatically generates invoices as part of order approval process\n  * Maintains invoice status synchronized with order status\n  * Uses transaction coordinator to ensure data consistency\n  * Supports compensation mechanisms for failed transactions\n\n* **Invoice Retrieval and Querying**\n  * Provides APIs to retrieve invoice details with related order and user data\n  * Implements caching for performance optimization\n  * Supports filtering and pagination\n\n## User Service\n* **User Management**\n  * Manages user accounts and profile information\n  * Handles user authentication and authorization\n  * Associates users with roles for permission management\n  * Validates data integrity (unique email, password requirements)\n\n* **Role-Based Access Control**\n  * Manages user permissions through role assignments\n  * Secures endpoints based on user roles\n  * Provides role management capabilities\n\n## Distributed Transaction Management\n* **Saga Pattern Implementation**\n  * Coordinates multi-step transactions across microservices\n  * Implements compensation mechanisms for failed transactions\n  * Maintains transaction state in Redis for reliability\n  * Provides transaction monitoring and status tracking\n\n* **Event-Driven Communication**\n  * Uses Kafka for reliable event publishing and consumption\n  * Implements event-based service communication\n  * Ensures loose coupling between services\n\n## Resilience and Performance\n* **Caching Strategy**\n  * Implements Redis caching for frequently accessed data\n  * Uses cache invalidation strategies to maintain data consistency\n  * Optimizes query performance with selective caching\n\n* **Error Handling and Recovery**\n  * Implements retry mechanisms for transient failures\n  * Provides detailed error reporting and logging\n  * Ensures graceful degradation during partial system failures\n\n## Future Enhancements\n* Email notifications for order approvals, cancellations, and user account actions\n* Enhanced monitoring and alerting capabilities\n* Performance dashboard for real-time system metrics\n* Enhanced security features (2FA, OAuth integration)\n\n---\n\n# 🏗 Architecture Overview\n\n![Architecture Overview](./image/logical-diagram.png)\n\n---\n\n#### This application follows a microservices architecture where each core business function (Order Management, User Management, etc.) is handled by an independent service. This ensures better scalability, fault isolation, and maintainability.\n\n* Microservices: Each business domain (Orders, Users, Invoices) is isolated into its own service, allowing independent scaling and development.\n* Modular Design: Each service follows clear boundaries and can be developed/deployed independently.\n* Event-Driven Communication: Services interact asynchronously via Kafka events (e.g., order creation, user updates).\n* Asynchronous Processing: Redis is used for caching and message queues, ensuring non-blocking operations.\n* Load Balancing: The system scales horizontally using Docker, Kubernetes, and Nginx.\n\n---\n\n# 🧩🔄⚙️🌐 Interaction Flow in Microservices\n\n\n![Interaction Flow in DDD and Microservices](./image/interaction-diagram.png)\n\n---\n\n## 1. Domain Layer:\n\n* Houses the core business logic for each microservice (Orders, Users, Invoices).\n* Encapsulates operations like changing order statuses, creating users, and generating invoices.\n\n## 2. Service Layer:\n\n* Handles interactions between the domain logic and infrastructure.\n* Uses repositories for data persistence and Kafka for event-driven communication.\n\n## 3. Infrastructure Layer:\n\n* Manages PostgreSQL, Redis, Kafka, and email notifications.\n* Redis is leveraged for caching frequently accessed data.\n\n## 4. API Gateway:\n\n* Routes client requests to the appropriate microservice.\n* Can aggregate responses from multiple services, reducing client complexity.\n\n## 5. Event-Driven Communication:\n\n* Kafka publishes and consumes events for system-wide updates.\n* Example: When an order is approved, a Kafka event triggers the invoice generation process.\n\n---\n\n# ⚙️ Domain-Driven Design Principles and Patterns\n\n* REST API with ExpressJS \u0026 TypeScript\n* PostgreSQL with ORM for database management\n* Redis for caching and queue management\n* Dependency Injection using typedi\n* Event-driven architecture with Kafka for inter-service communication\n* Microservices architecture for scalability\n* Robust Logging \u0026 Monitoring\n* Unit \u0026 E2E Testing for reliability\n* Security Best Practices\n* Scalable \u0026 Maintainable Codebase\n\n---\n\n# 🧩⚙️🛠️📐 Design Patterns\n\n##### The following design patterns have been applied to the system to ensure modularity, flexibility, and scalability:\n\n## 1. Singleton Pattern\n* Used for managing database connections and Redis cache instances\n* Ensures single instances of service connections (Kafka, Redis, PostgreSQL)\n* Implemented in infrastructure services to prevent duplicate resources\n\n## 2. Factory Pattern\n* Encapsulates object creation in the Container system\n* Enables dynamic service instantiation based on configuration\n* Used for creating repository instances and data access objects\n\n## 3. Dependency Injection (DI)\n* Uses TypeDI to inject dependencies across services\n* Reduces coupling between components\n* Simplifies testing through mock injection\n* Implemented throughout the codebase to manage service dependencies\n\n## 4. Observer Pattern\n* Implemented via Kafka event system for real-time updates\n* Services subscribe to relevant events and react accordingly\n* Used for propagating changes across microservices\n\n## 5. Strategy Pattern\n* Allows dynamic switching between querying strategies\n* Used in data access layer to support different query patterns\n* Supports flexible filtering and sorting mechanisms\n\n## 6. Command Pattern\n* Encapsulates operations as objects\n* Implements transaction steps as atomic commands\n* Used in distributed transaction management\n\n## 7. Decorator Pattern\n* Adds cross-cutting concerns without modifying core functionality\n* Used for Redis caching (@RedisDecorator)\n* Implements event publishing decorators for Kafka messages\n\n## 8. Proxy Pattern\n* Implements service proxies for API gateway routing\n* Provides caching and rate-limiting for API calls\n* Controls access to underlying services\n\n## 9. Repository Pattern\n* Abstracts database access behind clean interfaces\n* Separates domain models from data access logic\n* Used consistently across all services\n\n## 10. Builder Pattern\n* Constructs complex objects with clear, step-by-step processes\n* Used for building invoice and order objects\n* Simplifies object creation with many dependencies\n\n## 11. Publisher-Subscriber Pattern\n* Implemented via Kafka for asynchronous messaging\n* Enables event-driven architecture\n* Decouples services through message passing\n\n## 12. Circuit Breaker Pattern\n* Prevents cascading failures across microservices\n* Implements retry logic with exponential backoff\n* Used in service communication to handle transient failures\n\n## 13. Adapter Pattern\n* Creates compatible interfaces between different components\n* Used to integrate external services and libraries\n* Provides consistent abstractions over infrastructure services\n\n## 14. Saga Pattern\n* Coordinates distributed transactions across services\n* Implements compensating transactions for failure scenarios\n* Maintains transaction state and handles recovery\n* Core pattern for ensuring data consistency in the microservice architecture\n\n## 15. Façade Pattern\n* Provides simplified interfaces to complex subsystems\n* Used in API layer to simplify client interactions\n* Hides implementation details of underlying services\n\n## 16. Service Layer Pattern\n* Defines application's boundary and API set for client access\n* Encapsulates business logic implementation details\n* Coordinates responses to client operations with domain operations\n\n## 17. Specification Pattern\n* Used for complex querying with composable filter criteria\n* Supports advanced search and filtering operations\n* Implemented in repository query methods\n\n---\n\n# 📏🧭💡⚖️ Principles\n\n##### This project follows key software design principles to ensure a robust and maintainable codebase:\n\n## 1. SOLID Principles\n\n* Single Responsibility Principle (SRP): Each class and module has a single responsibility, minimizing changes and complexity.\n* Open/Closed Principle (OCP): Classes and modules are open for extension but closed for modification, enabling easier feature additions without breaking existing functionality.\n* Liskov Substitution Principle (LSP): Derived classes can be used in place of their base classes without altering the correctness of the program.\n* Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. This helps in creating smaller, specialized interfaces.\n* Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions, which is achieved through DI.\n\n## 2. DRY (Don't Repeat Yourself)\n\n* The codebase ensures that redundant logic and code are minimized. Reusable components and functions are created for common tasks such as error handling, logging, and validation.\n\n## 3. KISS (Keep It Simple, Stupid)\n\n* The application follows a simple and clear architecture, avoiding unnecessary complexity in both the design and implementation. We favor simplicity and readability.\n\n## 4. YAGNI (You Aren't Gonna Need It)\n\n* Only essential features and functionality are implemented. The project avoids overengineering, focusing on the current requirements.\n\n## 5. Separation of Concerns\n\n* The project ensures that business logic, data access, and presentation are separated. Each module is responsible for a specific concern, promoting modularity and maintainability.\n\n## 6. Composition Over Inheritance\n\n* The project favors composing objects and reusing behavior through composition rather than relying heavily on inheritance.\n\n---\n\n# 💻 Technologies\n\n## Backend Core\n* **Node.js** - JavaScript runtime environment\n* **TypeScript** - Typed superset of JavaScript for better development experience\n* **Express.js** - Web framework for building APIs\n* **routing-controllers** - Controller-based routing framework\n\n## Database \u0026 Storage\n* **PostgreSQL** - Relational database for persistent storage\n* **TypeORM** - Object-Relational Mapping for database interactions\n* **Redis** - In-memory data store for caching and distributed state\n\n## Messaging \u0026 Event-Driven Architecture\n* **Apache Kafka** - Distributed event streaming platform\n* **KafkaJS** - Kafka client library for Node.js\n\n## Dependency Management\n* **TypeDI** - Dependency injection container for TypeScript\n* **DataLoader** - Batching and caching for database queries\n\n## Containerization \u0026 Deployment\n* **Docker** - Containerization platform\n* **Docker Compose** - Multi-container Docker applications\n* **Nginx** - Load balancing and API gateway routing in production\n\n## Authentication \u0026 Security\n* **Passport.js** - Authentication middleware\n* **JSON Web Tokens (JWT)** - Secure information transmission\n* **bcrypt** - Password hashing\n\n## Testing \u0026 Quality Assurance\n* **Jest** - Testing framework\n* **eslint** - Code linting for quality control\n* **class-validator** - Runtime type checking and validation\n\n## Resilience \u0026 Performance\n* **Circuit Breakers** - Preventing cascading failures\n* **Connection Pooling** - Optimizing database connections\n* **Rate Limiting** - Protecting services from overload\n\n---\n\n# 🚀 Getting Started\n\n## 1. Prerequisites\n\n### For Docker Usage\n\n* Install Docker Desktop and ensure it is running.\n\n### For Application Usage\n\n* ✅ Node.js (v23.x or higher)\n* ✅ TypeScript\n* ✅ PostgreSQL\n* ✅ Redis\n* ✅ Kafka\n* ✅ Docker \u0026 Kubernetes\n* ✅ yarn\n\n## Installation\n\n## 1. Clone the repository:\n\n```javascript\ngit clone git@github.com:yavarguliyev/invoice_hub_microservices.git\n```\n\n## 2. Set Up Environment: \n\n#### The Docker setup is located at {main_root}/deployment/dev. For managing containers, we do not use the docker-compose up -d command directly. Instead, we use specific scripts to handle the container lifecycle.\n\n#### 1. To start the containers:\n\n```javascript\nbash start.sh\n```\n\n#### 2. To stop the containers:\n\n```javascript\nbash stop.sh\n```\n\n#### 3. To remove the containers, images, and volumes:\n\n```javascript\nbash remove.sh \n```\n\n## Environment Configuration\n\n* The .env file located in {main_root}/deployment/dev/.env is required for configuration.\n* You can copy the example file (.env.example) to create your own .env file.\n\n## 3. Install dependencies:\n\n```javascript\nyarn add\n```\n\n## 4. Run Migrations:\n\n##### Run migrations:\n\n```javascript\nyarn mup\n```\n\n##### Revert migrations:\n\n```javascript\nyarn mdn\n```\n\n##### Copy the .env.example file to .env and fill in the appropriate values for your environment.\n\n---\n\n# 📂 Project Structure\n\n```javascript\n/api-gateway             # API gateway for routing requests to microservices\n/common                  # Shared utilities, configs, and common code\n  ├── /src\n     ├── /application    # Application bootstrap and IoC helpers\n     ├── /core           # Core configs, middlewares, and types\n     ├── /domain         # Domain enums, interfaces, and types\n     ├── /infrastructure # Infrastructure implementations (DB, Kafka, Redis)\n/deployment              # Deployment configurations\n  ├── /dev               # Development environment setup\n  ├── /prod              # Production environment configs with Nginx\n/services                # Individual microservices\n  ├── /auth-service      # Authentication and user management\n  ├── /invoice-service   # Invoice operations and management\n  ├── /order-service     # Order creation and processing\n/package.json            # Workspace definitions and scripts\n/README.md               # Project documentation\n```\n\nEach service follows a similar structure:\n\n```javascript\n/services/\u003cservice-name\u003e\n  ├── /src\n     ├── /api            # REST API controllers and routes\n     ├── /application    # Service-specific application logic\n        ├── /helpers     # Helper functions and utilities\n        ├── /kafka       # Kafka event handlers and subscribers\n        ├── /services    # Core business services\n        ├── /transactions # Distributed transaction managers\n     ├── /domain         # Domain entities and repositories\n        ├── /entities    # TypeORM entities\n        ├── /repositories # Repository interfaces and implementations\n     ├── /test           # Unit and integration tests\n  ├── package.json       # Service-specific dependencies\n```\n\n---\n\n# 📚 API Documentation\n\n## Documentation Access\n* API documentation is available through Swagger UI when running the application:\n  * Auth Service: `http://localhost:4001/api-docs`\n  * Invoice Service: `http://localhost:4002/api-docs`\n  * Order Service: `http://localhost:4003/api-docs`\n\n## Testing with Postman\n* A Postman collection file is provided for testing the API endpoints:\n  ```\n  /postman/invoice_hub_microservices.postman_collection.json\n  ```\n* Import this collection into Postman to easily test all available endpoints\n* The collection includes environment variables for easy configuration\n\n## API Structure\n* All APIs follow a consistent RESTful structure\n* Endpoints are versioned (e.g., `/api/v1/orders`)\n* Standard HTTP methods are used (GET, POST, PATCH, DELETE)\n* Responses follow a consistent format with status codes and meaningful messages\n\n# 🚀 Running the Application\n\n## Development Mode\n\nTo start the application in development mode:\n\n1. First, start the infrastructure services using Docker:\n   ```bash\n   cd deployment/dev\n   bash start.sh\n   ```\n\n2. Start each microservice in development mode (in separate terminals):\n   ```bash\n   # From the project root\n   cd services/auth-service\n   yarn start\n   \n   cd services/invoice-service\n   yarn start\n   \n   cd services/order-service\n   yarn start\n   \n   cd api-gateway\n   yarn start\n   ```\n\n3. The services will be available at:\n   * API Gateway: http://localhost:3000\n   * Auth Service: http://localhost:4001\n   * Invoice Service: http://localhost:4002\n   * Order Service: http://localhost:4003\n\n## Production Mode\n\nFor production deployment:\n\n1. Build all services:\n   ```bash\n   yarn build\n   ```\n\n2. Start the production stack:\n   ```bash\n   cd deployment/prod\n   docker-compose up -d\n   ```\n\n3. Access the application at: http://localhost\n\n# 🧪 Testing\n\n## Running Tests\n\nTo run unit tests for all services:\n```bash\nyarn test\n```\n\nTo run tests for a specific service:\n```bash\ncd services/auth-service\nyarn test\n\ncd services/invoice-service\nyarn test\n\ncd services/order-service\nyarn test\n```\n\n# 🛠 Usage\n\n## Authentication\n\n### Login to get JWT token\n```bash\ncurl -X POST {{URL}}/auth/api/v1/auth/login \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"email\": \"admin@example.com\",\n    \"password\": \"Password123\"\n  }'\n```\n\n### Response:\n```json\n{\n  \"result\": \"SUCCESS\",\n  \"token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\n  \"expiresIn\": 3600\n}\n```\n\n## Order Management\n\n### Create a new order\n```bash\ncurl -X POST {{URL}}/orders/api/v1/orders \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: Bearer YOUR_TOKEN\" \\\n  -d '{\n    \"totalAmount\": 180.20,\n    \"description\": \"Monthly office supplies\"\n  }'\n```\n\n### Get list of orders\n```bash\ncurl -X GET {{URL}}/orders/api/v1/orders?page=1\u0026limit=10 \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n### Get order details\n```bash\ncurl -X GET {{URL}}/orders/api/v1/orders/{{id}} \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n## Invoice Management\n\n### Get list of invoices\n```bash\ncurl -X GET {{URL}}/invoices/api/v1/invoices?page=1\u0026limit=10 \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n### Get invoice details\n```bash\ncurl -X GET {{URL}}/invoices/api/v1/invoices/{{id}} \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n## User Management\n\n### Get list of users\n```bash\ncurl -X GET {{URL}}/auth/api/v1/users?page=1\u0026limit=10 \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n### Get user details\n```bash\ncurl -X GET {{URL}}/auth/api/v1/users/{{id}} \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n## Working with Filters\n\nYou can add filters to list endpoints:\n\n```bash\ncurl -X GET {{URL}}/orders/api/v1/orders?page=1\u0026limit=10\u0026filters[status]=PENDING \\\n  -H \"Authorization: Bearer YOUR_TOKEN\"\n```\n\n---\n\n# 🤝 Contributing\n\n1. Fork the repository.\n2. Create a new branch (git checkout -b feature-name).\n3. Commit your changes (git commit -am 'Add new feature').\n4. Push to the branch (git push origin feature-name).\n5. Create a new Pull Request.\n\n---\n\n# 📝 License\n\n#### This project is licensed under the MIT License. See the [LICENSE](https://github.com/yavarguliyev/invoice_hub_microservices/blob/master/LICENSE) file for details.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fyavarguliyev%2Finvoice_hub_microservices_express_js","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fyavarguliyev%2Finvoice_hub_microservices_express_js","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fyavarguliyev%2Finvoice_hub_microservices_express_js/lists"}