Implement customer management domain with authorization and API enhancements
- Introduced a new customer management domain, including entities, services, handlers, and forms for customer operations. - Added JWT-based user authorization settings in the configuration file for both user and customer management. - Updated API endpoints to reflect the new structure, including changes to health check and user management routes. - Enhanced Swagger documentation to include new customer-related endpoints and authorization details. - Refactored the Makefile to include a target for generating API documentation. - Removed obsolete documentation files to streamline the project structure.
This commit is contained in:
n.nakhostin
Binary file not shown.
@@ -1,746 +0,0 @@
|
||||
#
|
||||
|
||||
#
|
||||
|
||||
#
|
||||
|
||||
# Development Specification
|
||||
|
||||
# Tender Management
|
||||
|
||||
#
|
||||
|
||||
## **For AEC**
|
||||
|
||||
##
|
||||
|
||||
# **Document Metadata** {#document-metadata}
|
||||
|
||||
| Field | Information |
|
||||
| ----- | ----- |
|
||||
| **Document Name** | Tender Management Development Specification |
|
||||
| **Version** | 1.0 |
|
||||
| **Created By** | Niki Sagharidooz |
|
||||
| **Creation Date** | Jun 09, 2025 |
|
||||
| **Last Updated** | Jun 28, 2025 |
|
||||
| **Status** | Draft |
|
||||
|
||||
#
|
||||
|
||||
# Table of Content
|
||||
|
||||
[**Document Metadata 2**](#document-metadata)
|
||||
|
||||
[**Project Overview 5**](#project-overview)
|
||||
|
||||
[Purpose 5](#purpose)
|
||||
|
||||
[Problem Statement: Why This System Is Needed 6](#problem-statement:-why-this-system-is-needed)
|
||||
|
||||
[Scope 8](#scope)
|
||||
|
||||
[Technology Stack 11](#technology-stack)
|
||||
|
||||
[Step-by-Step Workflow 12](#step-by-step-workflow)
|
||||
|
||||
[Technical Implementation 16](#technical-implementation)
|
||||
|
||||
##
|
||||
|
||||
# **Project Overview** {#project-overview}
|
||||
|
||||
## **Purpose** {#purpose}
|
||||
|
||||
The purpose of this project is to develop a smart system that:
|
||||
|
||||
* Uses AI and machine learning to identify tenders that are relevant to a company’s products, services, or interests.
|
||||
* Automatically extracts and interprets tender deadlines and required documents.
|
||||
* Sends real-time notifications to customers based on their favorite topics.
|
||||
* Downloads all tender-related documents automatically, including from websites requiring login, reducing the need for manual monitoring and data entry.
|
||||
|
||||
##
|
||||
|
||||
## **Problem Statement: Why This System Is Needed** {#problem-statement:-why-this-system-is-needed}
|
||||
|
||||
Organizations often face major inefficiencies and missed opportunities when trying to stay updated with relevant tenders. These challenges include:
|
||||
|
||||
### **1\. Manual Tender Discovery**
|
||||
|
||||
* Companies must monitor various tender websites manually—each with different formats, layouts, and login requirements.
|
||||
* Most tender platforms are designed for desktop, making them inconvenient for mobile-first customers.
|
||||
* This results in delayed access and increased risk of missing relevant tenders.
|
||||
|
||||
### **2\. Language Barriers**
|
||||
|
||||
* Tenders are often published in local or foreign languages, requiring manual translation for teams to understand the content.
|
||||
* This slows down decision-making and increases dependency on translators.
|
||||
|
||||
### **3\. Unstructured and Scattered Documents**
|
||||
|
||||
* Tender documents are scattered across platforms and hidden behind logins.
|
||||
* Required documents may include PDFs, scanned images, Excel sheets, and multi-part attachments.
|
||||
* Manual download and sorting wastes time and increases the risk of incomplete or incorrect submissions.
|
||||
|
||||
### **4\. Irrelevant Notifications**
|
||||
|
||||
* Existing systems typically send bulk notifications, regardless of a company’s business focus.
|
||||
* Without AI to understand company profiles or documents, users receive low-value and unrelated tenders, causing disengagement.
|
||||
|
||||
### **5\. Missed Deadlines**
|
||||
|
||||
* Deadlines are often hidden deep in documents, not always in structured form.
|
||||
* Manual review means companies often respond too late.
|
||||
|
||||
### **6\. Missing Legal Documents or Partnership Requirements**
|
||||
|
||||
* Some tenders require specific legal registrations or partner documentation that the company may lack.
|
||||
* Without guidance or support, companies are **disqualified** or discouraged from applying.
|
||||
|
||||
##
|
||||
|
||||
## **Scope** {#scope}
|
||||
|
||||
### **Tender Discovery & Matching**
|
||||
|
||||
* Automatically gather and classify tenders from various portals using scraping and APIs.
|
||||
* Use NLP to categorize tenders by industry, keywords, and relevance.
|
||||
* Enable users to filter and search based on personalized criteria.
|
||||
|
||||
### **Document Management & Automation**
|
||||
|
||||
* Automate downloading of tender documents from multiple portals, even behind logins.
|
||||
* Securely store and organize documents, avoiding duplicates using checksums.
|
||||
* Support uploads via dashboard or email for company files like catalogs or contracts.
|
||||
|
||||
### **Company & Business Knowledge Integration**
|
||||
|
||||
* Extract structured insights from business documents using AI and NLP.
|
||||
* Understand products, services, and offerings to inform tender matching.
|
||||
* Continuously enrich the system’s contextual knowledge of each company.
|
||||
|
||||
### **Tender Recommendation Engine**
|
||||
|
||||
* Match tenders with company offerings and user interests using advanced AI models.
|
||||
* Use semantic similarity, document analysis, and saved preferences to score relevance.
|
||||
* Provide tailored recommendations and allow user feedback for improved results.
|
||||
|
||||
### **Notification system**
|
||||
|
||||
* Send email and mobile alerts for new and relevant tenders.
|
||||
* Support customizable frequency settings (real-time, daily, weekly).
|
||||
* Highlight high-priority tenders and deadline reminders automatically.
|
||||
|
||||
### **Mobile and desktop application**
|
||||
|
||||
* Offer a responsive web and mobile app experience for viewing tenders and alerts.
|
||||
* Allow users to review, filter, and act on tenders anytime, anywhere.
|
||||
* Ensure mobile-first UI for busy professionals on the go.
|
||||
|
||||
### **Legal & Compliance Assistance**
|
||||
|
||||
* Identify legal requirements and missing documents for specific tenders.
|
||||
* Recommend document preparation or suggest potential partners for compliance.
|
||||
* Support multi-party collaboration for joint tender submissions.
|
||||
|
||||
### **User & Company Profiles**
|
||||
|
||||
* Enable users to save interests, keywords, and preferred industries.
|
||||
* Store company-specific information to personalize tender discovery.
|
||||
* Adapt AI recommendations based on evolving preferences and behavior.
|
||||
|
||||
### **Dashboard & Administration**
|
||||
|
||||
* Provide an intuitive dashboard for tender matches, documents, and timelines.
|
||||
* Include admin tools for managing users, scrapers, and system performance.
|
||||
* Offer insights and analytics on matching accuracy and user activity.
|
||||
|
||||
### **System Integration & APIs**
|
||||
|
||||
* Expose APIs for integration with external CRMs, ERPs, and tender management tools.
|
||||
* Use token-based authentication and modular services for extensibility.
|
||||
* Prepare the system for white-labeling or SaaS partnerships.
|
||||
|
||||
### **Reliability, Monitoring & Deployment**
|
||||
|
||||
* Ensure stable operation with automated testing, error monitoring, and alerts.
|
||||
* Deploy with Docker on secure cloud infrastructure.
|
||||
* Log system behavior and provide real-time status for key components.
|
||||
|
||||
### **Continuous Improvement & Scaling**
|
||||
|
||||
* Retrain AI models with new data to increase accuracy over time.
|
||||
* Update scrapers to adapt to changes in tender portal structures.
|
||||
* Evolve features based on feedback, business needs, and user behavior.
|
||||
|
||||
##
|
||||
|
||||
## **Technology Stack** {#technology-stack}
|
||||
|
||||
| Component | Technology Choices |
|
||||
| :---- | :---- |
|
||||
| **Frontend** | React Native (admin) |
|
||||
| **Mobile** | Flutter |
|
||||
| **Backend** | GoLang (Echo) |
|
||||
| **AI & NLP** | ? |
|
||||
| **Database** | MongoDB / Redis / RabbitMQ / Elasticsearch |
|
||||
|
||||
## **Step-by-Step Workflow** {#step-by-step-workflow}
|
||||
|
||||
### **1\. Tender Source Monitoring**
|
||||
|
||||
**Objective:** Identify potential tender opportunities in real-time.
|
||||
|
||||
* Maintain a list of trusted tender sources (URLs, portals, APIs like OPIC) in the database.
|
||||
* Schedule regular checks for each source (via scraping or API).
|
||||
* Detect and fetch new tenders based on publication date and update frequency.
|
||||
|
||||
### **2\. Tender Discovery & Data Collection**
|
||||
|
||||
**Objective:** Extract structured data from multiple tender platforms.
|
||||
|
||||
* Automatically navigate tender websites or APIs to collect metadata:
|
||||
* Title, deadline, description, type (RFI, RFP, Tender…), category codes, region, and budget.
|
||||
* For documents and deep content:
|
||||
* Use AI-assisted login handling.
|
||||
* Retrieve attachments (PDFs, Word, Excel) such as tender documents, terms of reference, eligibility criteria.
|
||||
* Automatically translate non-English documents into English using AI-based translation tools (e.g., DeepL API, open-source models).
|
||||
* Store raw and normalized tender data in the local database (MongoDB).
|
||||
|
||||
### **3\. Tender Data Normalization & Categorization**
|
||||
|
||||
**Objective:** Make tenders searchable, sortable, and ready for AI matching.
|
||||
|
||||
* Clean and preprocess texts (tokenization, language detection, stemming).
|
||||
* Use NLP/ML models to:
|
||||
* Classify tenders by industry, sector, or CPV codes.
|
||||
* Extract keywords and technical/legal requirement phrases.
|
||||
* Assign tags for internal indexing and filtering.
|
||||
|
||||
### **4\. Company Onboarding & Knowledge Extraction**
|
||||
|
||||
**Objective:** Understand the company’s business, products, and capabilities.
|
||||
|
||||
* Allow companies to upload documents:
|
||||
* Product catalogs, brochures, project history, certificates, etc.
|
||||
* Accept uploads via dashboard or email parser.
|
||||
* Apply NLP to extract and structure key information:
|
||||
* Keywords, product types, service areas, past experience, legal readiness.
|
||||
|
||||
### **5\. Interest Modeling (Company Preferences)**
|
||||
|
||||
**Objective:** Understand and learn company-specific tender interests.
|
||||
|
||||
* Build a dynamic interest profile using:
|
||||
* Onboarding data
|
||||
* Interactions (liked/disliked tenders)
|
||||
* Previously applied tenders
|
||||
* Use vector similarity models (e.g., SBERT, embedding-based matching) to align tender features with company profiles.
|
||||
|
||||
### **6\. AI-Powered Tender Matching & Feedback Loop**
|
||||
|
||||
**Objective:** Suggest best-fit tenders and refine recommendations.
|
||||
|
||||
* Propose tenders on web and mobile interface
|
||||
* Allow users to like/dislike tenders (swipe or button).
|
||||
* Log actions and train ML models continuously to refine relevance.
|
||||
* Use feedback to:
|
||||
* Improve the similarity score model
|
||||
* Adjust tagging/weighting for interests
|
||||
|
||||
### **7\. Tender Detail View & Document Requirement Analysis**
|
||||
|
||||
**Objective:** Prepare for successful application.
|
||||
|
||||
* Each tender has a detail page showing:
|
||||
* Full description, documents, deadline, eligibility
|
||||
* Analyze attached files (requirements, checklists) using AI.
|
||||
* Compare against company documents to identify what’s missing:
|
||||
* Legal documents (e.g., licenses, certificates)
|
||||
* Technical docs (e.g., specs, experience, financials)
|
||||
* Show completion progress bar and give upload recommendations.
|
||||
|
||||
### **8\. Document Finalization & Submission Preparation**
|
||||
|
||||
**Objective:** Automate preparation of a complete tender submission package.
|
||||
|
||||
* Once all required documents are available:
|
||||
* Convert to required formats
|
||||
* Merge, compress, and sign if needed
|
||||
Check for compliance or special formatting rules
|
||||
* Use submission method:
|
||||
* Self-Apply: Package is downloaded or submitted via tender portal.
|
||||
* Partnership-Apply: System suggests or connects with partners to complete missing parts (e.g., financial eligibility).
|
||||
|
||||
### **9\. Post-Submission Tracking & Follow-Up (Optional Future Phase)**
|
||||
|
||||
**Objective:** Extend lifecycle tracking for transparency and engagement.
|
||||
|
||||
* Allow companies to track status (submitted, under review, won/lost).
|
||||
* Gather outcome data to train models on winning patterns.
|
||||
* Enable reminders for re-submission, future similar tenders.
|
||||
|
||||
## **Technical Implementation** {#technical-implementation}
|
||||
|
||||
### **1\. Tender Source Monitoring**
|
||||
|
||||
Automatically monitor and extract tender metadata and documents from diverse sources (static sites, dynamic pages, APIs), normalize it, and store it in the internal database for further AI processing.
|
||||
|
||||
Goal: Keep track of trusted tender sources and detect the availability of new tenders in near real-time.
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **1\. Tender Source Configuration Table**
|
||||
|
||||
Maintain a registry of sources to monitor.
|
||||
|
||||
* **Sources (for example:)**
|
||||
* [**https://app.mercell.com/**](https://app.mercell.com/)
|
||||
* [**https://ted.europa.eu/**](https://ted.europa.eu/)
|
||||
* **Schema fields:**
|
||||
* id, name, type (API, HTML, JS, PDF)
|
||||
* base\_url
|
||||
* auth\_required (bool)
|
||||
* credentials\_id (link to secure store)
|
||||
* category\_tags, region, language
|
||||
* check\_interval
|
||||
* Last\_checked\_at
|
||||
* status
|
||||
|
||||
##### **2\. Job Scheduler (Dynamic Source Polling)**
|
||||
|
||||
* Use approaches for scheduling and tracking.
|
||||
* Each source is polled based on:
|
||||
* sync\_frequency (e.g., hourly, daily)
|
||||
* last\_checked\_at timestamp
|
||||
* Historical success/failure log
|
||||
* Jobs are batched and distributed to workers based on source type.
|
||||
|
||||
##### **4\. Logging, Monitoring & Recovery**
|
||||
|
||||
* Use ELK Stack or Prometheus \+ Grafana to monitor:
|
||||
* Job failures
|
||||
* Source availability
|
||||
* Scraping errors
|
||||
* Retry logic:
|
||||
* Exponential backoff on failures
|
||||
* Email alerts on consecutive errors per source
|
||||
|
||||
###
|
||||
|
||||
### **2\. Tender Discovery & Data Collection**
|
||||
|
||||
Automatically discover tenders from multiple trusted sources (public APIs, web portals, data feeds), collect and structure their metadata, extract/download documents, and store them in a standardized format for downstream AI processing.
|
||||
|
||||
Goal: Deep-dive into flagged sources, extract structured tender metadata and documents.
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **1\. Scraper Engines**
|
||||
|
||||
* For each source, use appropriate adapter:
|
||||
* **API-based**: REST/SOAP client with pagination and filtering
|
||||
* **HTML-based**: Headless browser automation (e.g., Playwright)
|
||||
* Authenticate if required (Basic Auth, OAuth, or Form login via AI-based login engine)
|
||||
|
||||
##### **2\. Metadata & Document Extraction**
|
||||
|
||||
* Parse listings to extract structured tender metadata:
|
||||
|
||||
| Field | Example |
|
||||
| :---- | :---- |
|
||||
| title | Billing system |
|
||||
| Summary | **Risks & contract compliance** Service Level Agreements (SLAs): Support and operational support should be available on weekdays, excluding holidays, where the lowest level should be 6 hours between 7 am and 5 pm Swedish time. Fines and fees: A penalty is payable for delays in commissioning according to the implementation plan. Compliance and Intellectual Property: The Supplier grants free, non-exclusive and unlimited rights of use for the licenses that are part of the Supplier's commitment. **Scope of delivery** Delivery Timelines \- Expected Delivery: 2025-12-01 |
|
||||
| type | RFP, RFI, Tender, etc. |
|
||||
| publication\_date | 2025-08-01T00:00:00Z |
|
||||
| deadline | 2025-08-15T00:00:00Z |
|
||||
| category\_codes | 48000000-8 Software and information systems, 48444100-3 Billing system |
|
||||
| region | Europe, Asia, etc. |
|
||||
| budget | $500,000 USD |
|
||||
| source\_link | Tender detail page: [https://www.opic.com/upphandling/debiteringssystem-(laholmsbuktens-va-ab-halmstad)-aid40481e6db4dfa80c3ead781d5a3fe3a9/?p=8](https://www.opic.com/upphandling/debiteringssystem-\(laholmsbuktens-va-ab-halmstad\)-aid40481e6db4dfa80c3ead781d5a3fe3a9/?p=8) |
|
||||
| document\_links | Tender document pages (Generate SHA256 for deduplication) |
|
||||
|
||||
#####
|
||||
|
||||
##### **3\. OCR & Translation Pipeline**
|
||||
|
||||
* Detect document language (via langdetect, fastText)
|
||||
* If not English:
|
||||
* Use AI for translation
|
||||
* Store both original and translated versions with versioning.
|
||||
|
||||
##### **4\. Normalization & Storage**
|
||||
|
||||
* Store in PostgreSQL or MongoDB:
|
||||
* **PostgreSQL** for structured metadata (good for querying, indexing)
|
||||
* **MongoDB** for semi-structured documents and text
|
||||
* Normalize dates, categorize tenders using tags and CPV codes
|
||||
|
||||
###
|
||||
|
||||
### **3\. Tender Data Normalization & Categorization**
|
||||
|
||||
Transform raw tender data into structured, consistent, and semantically enriched records to enable precise search, filtering, and intelligent matching. This step prepares tenders for downstream AI models by cleaning, classifying, and tagging their content.
|
||||
|
||||
Goal: Convert unstructured tender data into a clean, searchable, and categorized format, and enable accurate AI-powered tender matching through classification, tagging, and keyword extraction.
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Text Preprocessing Pipeline**
|
||||
|
||||
* Language Detection: Identify the language; translate non-English tenders.
|
||||
* Text Cleaning: Remove HTML, special characters, and noise.
|
||||
* Tokenization: Break text into individual words/phrases.
|
||||
* Stemming/Lemmatization: Reduce words to their root forms for consistency.
|
||||
* Stopword Removal: Exclude irrelevant filler words to improve keyword clarity.
|
||||
|
||||
##### **Tender Classification (Industry, Sector, CPV Code)**
|
||||
|
||||
* Model Training: Train classification models using labeled tender datasets with CPV codes.
|
||||
* Model Inference: Apply the trained model to new tenders to auto-assign categories and codes.
|
||||
* Confidence Scoring: Assign a probability score to each classification for accuracy evaluation or fallback logic.
|
||||
|
||||
##### **Keyword & Requirement Extraction**
|
||||
|
||||
* NER (Named Entity Recognition): Extract names, organizations, locations, and monetary amounts.
|
||||
* Keyphrase Extraction: Use tools to identify key requirements and tender focus areas.
|
||||
* Pattern Matching: detect technical/legal requirements (e.g., “ISO 9001”).
|
||||
|
||||
##### **Tagging & Indexing**
|
||||
|
||||
* Tag Assignment: Auto-generate tags (e.g., “LMS”, “CRM”) based on keywords, industry, and tender type.
|
||||
* Synonym Mapping: Normalize terminology (e.g., “solar” → “renewable energy”) using internal thesauri or mapping tables.
|
||||
* Elasticsearch Indexing: Store all structured and tagged tenders in a search engine like Elasticsearch for fast retrieval.
|
||||
|
||||
##### **Data Storage Format**
|
||||
|
||||
* Save normalized tenders in a JSON schema with fields like title, industry, cpv\_code, tags, keywords, description, and deadline.
|
||||
|
||||
###
|
||||
|
||||
### **4\. Company Onboarding & Knowledge Extraction**
|
||||
|
||||
This step enables companies to easily onboard by uploading their business-related documents. Using AI, we extract structured knowledge about their products, services, experience, and legal readiness to enhance tender matching accuracy.
|
||||
|
||||
Goal: Build a structured profile of each company based on uploaded documents and business data, and enable personalized tender recommendations based on real company capabilities and past experience.
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Document Intake & Upload**
|
||||
|
||||
* Dashboard Upload: Support uploading files directly via web interface (drag & drop or file selector).
|
||||
* Email Parser Integration: Set up a dedicated email and use IMAP to retrieve and parse incoming attachments.
|
||||
* Supported File Types: PDF, DOCX, XLSX, CSV, images (with OCR), and plain text.
|
||||
|
||||
##### **File Preprocessing**
|
||||
|
||||
* Document Parsing:
|
||||
* Use tools for text extraction.
|
||||
* OCR support for scanned/image-based documents.
|
||||
* Language Detection & Translation: Auto-translate non-English documents.
|
||||
|
||||
##### **NLP-Based Information Extraction**
|
||||
|
||||
* Named Entity Recognition (NER): Extract key entities such as product names, certifications, partner companies, dates, locations.
|
||||
* Keyphrase Extraction:
|
||||
* Product categories
|
||||
* Service areas
|
||||
* Experience keywords (e.g., “government projects”, “international tenders”)
|
||||
* Legal/readiness terms (e.g., “ISO”, “compliance”, “bond”, “bid security”)
|
||||
* Classification & Tagging: Categorize the company’s domain (e.g., construction, IT services) using multi-label classifiers.
|
||||
|
||||
##### **Structured Data Output**
|
||||
|
||||
* Create Company Profile Object: Normalize and store extracted data in structured format.
|
||||
* Store in Database: Save in MongoDB or PostgreSQL for relational access.
|
||||
|
||||
##### **Dashboard Visualization**
|
||||
|
||||
* Preview Extracted Info: Allow users to review and correct extracted info in their profile dashboard.
|
||||
* Editable Tags & Interests: Companies can refine their expertise or interests to improve recommendations.
|
||||
|
||||
###
|
||||
|
||||
### **5\. Interest Modeling (Company Preferences)**
|
||||
|
||||
This step creates a dynamic, evolving interest profile for each company based on onboarding data, behavior, and tender interaction history. It allows the system to tailor tender recommendations using AI-powered semantic understanding.
|
||||
|
||||
Goal: Accurately predict and recommend relevant tenders to each company using machine learning and semantic similarity and Continuously refine recommendations based on real-time feedback like likes, dislikes, and application history.
|
||||
|
||||
###
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Interest Profile Construction**
|
||||
|
||||
* Initial Profile Creation:
|
||||
* Extract from onboarding data (e.g., keywords, sectors, product types).
|
||||
* Store as structured embeddings using models or OpenAI embeddings.
|
||||
* Behavioral Signals:
|
||||
* Track:
|
||||
* Tenders the company liked/disliked (via UI interaction).
|
||||
* Tenders viewed in detail.
|
||||
* Tenders the company applied to.
|
||||
* Assign implicit weights to actions:
|
||||
* Applied \> Liked \> Viewed \> Ignored \> Disliked.
|
||||
|
||||
##### **Embedding & Vector Space Modeling**
|
||||
|
||||
* Embed Tender Metadata:
|
||||
* Use models or OpenAI to embed:
|
||||
* Title \+ Description \+ Category \+ Keywords of each tender.
|
||||
* Embed Company Profile:
|
||||
* Combine onboarding profile \+ interacted tenders to form a composite embedding.
|
||||
* Update periodically using weighted average of embeddings and attention mechanisms.
|
||||
|
||||
##### **Matching via Similarity**
|
||||
|
||||
* Calculate Similarity Scores:
|
||||
* Use similarity between tender vectors and the company interest vector.
|
||||
* Rank tenders based on similarity scores.
|
||||
* Dynamic Thresholding:
|
||||
* Auto-adjust thresholds to optimize for engagement.
|
||||
|
||||
##### **Continuous Learning**
|
||||
|
||||
* Feedback Loop:
|
||||
* After each interaction, retrain/update interest vectors with new signals.
|
||||
* Use weighting (e.g., recent feedback has higher influence).
|
||||
* Cold Start Handling:
|
||||
* For new users: rely more on onboarding data and sector-based popularity.
|
||||
|
||||
##### **Data Storage**
|
||||
|
||||
* Store embeddings in vector databases.
|
||||
* Maintain a link between company\_id and interest vectors.
|
||||
|
||||
##### **Dashboard Integration**
|
||||
|
||||
* Allow companies to optionally adjust their visible “interest tags.”
|
||||
* Show feedback insights: “Why this tender was recommended” using explainable AI labels.
|
||||
|
||||
###
|
||||
|
||||
### **6\. AI-Powered Tender Matching & Feedback Loop**
|
||||
|
||||
This step delivers personalized tender recommendations to users via a user-friendly interface and continuously improves accuracy by learning from their actions (like, dislike, apply). The system refines its AI model in real-time to better align future matches with user preferences.
|
||||
|
||||
Goal: Display top-matching tenders to companies using semantic similarity and preference learning, and continuously refine matching logic using interaction data to improve recommendation precision.
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Tender Recommendation Engine**
|
||||
|
||||
* Input:
|
||||
* Vector embeddings of tenders (from metadata and documents).
|
||||
* Company interest profile (from onboarding and behavioral history).
|
||||
* Processing:
|
||||
* Calculate similarity between tender vectors and company interest vectors.
|
||||
* Apply filters (e.g., deadlines, budget thresholds, region) as post-processing.
|
||||
* Return top N matches with ranking score.
|
||||
* Output:
|
||||
* List of tenders with scores, tags, and explanations (“matched based on your interest in X”).
|
||||
|
||||
##### **Frontend Integration (Web & Mobile)**
|
||||
|
||||
* Display Recommendations:
|
||||
* Swipe interface (Right \= Like, Left \= Dislike).
|
||||
* Tender Details Page:
|
||||
* View all tender information, documents, requirements.
|
||||
* Show AI-generated tags and relevance explanation.
|
||||
* UX Enhancements:
|
||||
* Save, share, and bookmark options.
|
||||
* Quick apply or partner apply triggers.
|
||||
|
||||
##### **Logging & Feedback Capture**
|
||||
|
||||
* Log every user interaction:
|
||||
* Swipe/Like/Dislike/Apply/Open/View duration.
|
||||
* Tag feedback with tender ID and company ID.
|
||||
* Store in an event table or analytics service.
|
||||
|
||||
##### **Feedback Loop for Model Refinement**
|
||||
|
||||
* Model Update Strategy:
|
||||
* Use positive actions (like/apply) to reinforce embeddings.
|
||||
* Use negative actions (dislike) to reduce weight for similar tenders.
|
||||
* Training Pipeline:
|
||||
* Batch trains daily or weekly on logged feedback.
|
||||
* Fine-tune vector weighting, tagging priorities, and scoring thresholds.
|
||||
* Use techniques like contrastive learning or reinforcement-based re-ranking.
|
||||
* Model Versions:
|
||||
* Track multiple versions of recommendation models.
|
||||
* Monitor engagement metrics for each.
|
||||
|
||||
##### **Continuous Learning Architecture**
|
||||
|
||||
* Maintain:
|
||||
* Embeddings index.
|
||||
* Interaction history per company.
|
||||
* Real-time scoring microservice for fast tender matching.
|
||||
* Periodic retraining with growing interaction dataset.
|
||||
|
||||
### **7\. Tender Detail View & Document Requirement Analysis**
|
||||
|
||||
This feature ensures companies are well-prepared to submit complete, compliant applications by analyzing tender requirements and comparing them against existing company documents. It surfaces gaps and guides users through completion with AI-powered recommendations.
|
||||
|
||||
Goal: Provide an intelligent tender detail view that highlights all requirements and tracks preparation status, and automatically detect missing documents and guide users to complete their application package efficiently.
|
||||
|
||||
###
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Tender Detail Page Interface**
|
||||
|
||||
* Display Components:
|
||||
* Tender metadata: Title, type (RFI/RFP), deadline, budget, country, CPV codes.
|
||||
* Downloadable tender documents (with preview).
|
||||
* Eligibility criteria, required legal & technical documents.
|
||||
* AI-suggested tags and summary (extracted from content).
|
||||
* “Like / Dislike” or “Apply Now” buttons.
|
||||
* Progress Features:
|
||||
* Upload area with drag-and-drop or document selection.
|
||||
* Visual progress bar (% of required docs completed).
|
||||
* Real-time upload recommendations: “You’re missing X document for eligibility.”
|
||||
|
||||
##### **Document Content Analysis**
|
||||
|
||||
* Extraction Pipeline:
|
||||
* Automatically parse PDFs, Word, and Excel files from tenders.
|
||||
* Use NLP models to detect requirement sections, deadlines, eligibility criteria, and file checklists.
|
||||
* Extract named entities (licenses, certifications, formats).
|
||||
* Identify legal, financial, and technical expectations using keyword and pattern detection.
|
||||
|
||||
##### **Company Document Matching**
|
||||
|
||||
* Cross-check Requirements vs. Company Assets:
|
||||
* Use company's previously uploaded/onboarded files.
|
||||
* Apply classification to each file (license, portfolio, certificate, etc.).
|
||||
* Match against tender needs using semantic similarity.
|
||||
* Identify missing or outdated documents (based on expiration or file type).
|
||||
* Output:
|
||||
* List of matched vs. missing docs with confidence scores.
|
||||
* Suggested templates or examples if the required doc is not available.
|
||||
* Button to request generation or partner document upload if needed.
|
||||
|
||||
##### **Completion Progress Engine**
|
||||
|
||||
* Logic:
|
||||
* Calculate completeness score as (Matched docs / Required docs).
|
||||
* Show color-coded progress bar (e.g., red \<50%, yellow 50–90%, green 90–100%).
|
||||
* Optional: provide estimated readiness time based on historical upload pace.
|
||||
* Notifications:
|
||||
* Trigger alerts for missing documents with deadlines.
|
||||
* Recommend upload or request from partners.
|
||||
|
||||
##### **Smart Upload Assistant (Optional AI enhancement)**
|
||||
|
||||
* Auto-suggest appropriate files from user’s document repository.
|
||||
* Pre-fill metadata for uploaded documents (e.g., expiry date, type).
|
||||
* Offer translation option for non-English documents before submission.
|
||||
|
||||
### **8\. Document Finalization & Submission Preparation**
|
||||
|
||||
This stage ensures that once all tender requirements are fulfilled, the system automatically assembles a submission-ready package, following each tender’s specific formatting, compliance, and submission rules. Whether submitting solo or through a partner, companies receive a polished, validated package.
|
||||
|
||||
Goal: Streamline and automate the final preparation of all tender documents into a compliant, complete submission package, and support both self-application and partnership-based submission paths
|
||||
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Document Aggregation & Validation**
|
||||
|
||||
* Trigger: Once all required documents are marked as “uploaded” and “valid.”
|
||||
* Actions:
|
||||
* Gather documents from company repository or upload history.
|
||||
* Validate document types, names, and formats against tender requirements.
|
||||
* Check for required elements (e.g., stamps, signatures, date fields, headers).
|
||||
|
||||
##### **Format Conversion & Compilation**
|
||||
|
||||
* Auto-conversion:
|
||||
* Convert all documents to required formats (e.g., PDF/A, DOCX, XLSX).
|
||||
* File merging & compression:
|
||||
* Merge into a single file or grouped ZIP, based on tender rules.
|
||||
* Compress files (e.g., using zip) to meet size limits.
|
||||
|
||||
##### **Compliance & Formatting Checks**
|
||||
|
||||
* Use rule-based validation for each tender (stored in tender metadata):
|
||||
* File size limits
|
||||
* Naming conventions
|
||||
* Required fields (e.g., bid amount, bidder name)
|
||||
* Format-specific checks (password protection, watermarking)
|
||||
* Highlight compliance issues and block submission until resolved.
|
||||
|
||||
##### **Submission Path Handling**
|
||||
|
||||
* Self-Apply Path:
|
||||
* Show final review screen with submission checklist.
|
||||
* Provide “Download Submission Package” or “Auto-submit” via portal login (if credentials provided).
|
||||
* Save submission receipt if submitted automatically.
|
||||
* Partnership-Apply Path:
|
||||
* Check which documents are missing or out of scope (e.g., large financial guarantees).
|
||||
* Initiate request to partner with progress tracker.
|
||||
* Once all parts are covered, follow same compilation and submission flow.
|
||||
|
||||
##### **Logging & Auditing**
|
||||
|
||||
* Save submission timestamp, method, and document hash for auditing.
|
||||
* Generate a PDF summary page: tender info, included documents, company details.
|
||||
|
||||
### **9\. Post-Submission Tracking & Follow-Up**
|
||||
|
||||
This step extends the tender lifecycle beyond submission by allowing companies to monitor outcomes, receive updates, and learn from past results. It also feeds valuable outcome data back into the AI to improve future tender matching and interest modeling.
|
||||
|
||||
Goal: Provide full visibility into the status of submitted tenders and enable intelligent follow-ups, and collect feedback data to refine AI recommendations and improve success rates over time
|
||||
|
||||
|
||||
#### **Implementation Steps:**
|
||||
|
||||
##### **Submission Status Tracking**
|
||||
|
||||
* Integration points:
|
||||
* Where supported, integrate with tender portals via API or email scraping to fetch status updates (e.g., “Under Review”, “Awarded”, “Rejected”).
|
||||
* Otherwise, allow companies to manually update status.
|
||||
* Statuses supported:
|
||||
* Submitted
|
||||
* Under Review
|
||||
* Clarification Requested
|
||||
* Won
|
||||
* Lost
|
||||
* Implementation:
|
||||
* Use webhook listeners or scheduled API polling to monitor external status (where available).
|
||||
* NLP-based email parser to extract outcome data from official tender authority emails.
|
||||
|
||||
##### **Outcome Logging & Analytics**
|
||||
|
||||
* After a result is confirmed:
|
||||
* Log result, including winning bidder info (if public), reason for win/loss (if available).
|
||||
* Store structured outcome data in database (linked to tender ID and company ID).
|
||||
* Trigger learning module: feed result into AI model to improve future predictions.
|
||||
|
||||
##### **Feedback to AI Models**
|
||||
|
||||
* Use outcomes to:
|
||||
* Refine tender-to-company matching algorithm (reward winning features).
|
||||
* Update company interest vectors to reflect real wins/losses.
|
||||
* Adjust tender classification/weighting based on what tends to succeed.
|
||||
|
||||
##### **Follow-Up Reminders & Re-engagement**
|
||||
|
||||
* Features:
|
||||
* Show follow-up prompts like:
|
||||
* “This tender reopens annually – set a reminder?”
|
||||
* “Missed this tender? 3 similar ones are now open.”
|
||||
* Schedule email/SMS reminders based on historical tender dates.
|
||||
* Implementation:
|
||||
* Use clustering or similarity search to suggest future relevant tenders.
|
||||
* Store and query tender metadata to detect recurring patterns (e.g., same title/code).
|
||||
|
||||
##### **Auditable History & Notifications**
|
||||
|
||||
* Display a full lifecycle log in the user dashboard:
|
||||
* Dates of submission, updates, outcome, actions taken.
|
||||
* Allow download of submission receipts and audit logs.
|
||||
* Notify teams of key status changes via web app and email.
|
||||
|
||||
@@ -1,491 +0,0 @@
|
||||
# API Examples
|
||||
|
||||
This document provides examples of how to interact with the Tender Management API using curl commands.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. **Start MongoDB**:
|
||||
```bash
|
||||
sudo systemctl start mongod
|
||||
```
|
||||
|
||||
2. **Start the server**:
|
||||
```bash
|
||||
make run
|
||||
```
|
||||
|
||||
3. **Verify server is running**:
|
||||
```bash
|
||||
curl http://localhost:8081/health
|
||||
```
|
||||
|
||||
## Customer Management Examples
|
||||
|
||||
### 1. Register a New Customer (Admin Only)
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/admin/customers/register \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"full_name": "John Doe",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"password": "securepassword123",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/avatar.jpg"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Customer registered successfully",
|
||||
"data": {
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"full_name": "John Doe",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/avatar.jpg",
|
||||
"status": "active",
|
||||
"is_verified": false,
|
||||
"created_at": 1703123456,
|
||||
"updated_at": 1703123456
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Customer Login
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/customers/login \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"email_or_mobile": "john@example.com",
|
||||
"password": "securepassword123"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Login successful",
|
||||
"data": {
|
||||
"customer": {
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"full_name": "John Doe",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/avatar.jpg",
|
||||
"status": "active",
|
||||
"is_verified": false,
|
||||
"created_at": 1703123456,
|
||||
"updated_at": 1703123456
|
||||
},
|
||||
"access_token": "abc123def456",
|
||||
"refresh_token": "xyz789uvw012",
|
||||
"expires_at": 1703127056
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Get Customer Profile (Protected)
|
||||
|
||||
```bash
|
||||
curl -X GET http://localhost:8081/api/customers/profile \
|
||||
-H "X-Customer-ID: 550e8400-e29b-41d4-a716-446655440000"
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Profile retrieved successfully",
|
||||
"data": {
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"full_name": "John Doe",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/avatar.jpg",
|
||||
"status": "active",
|
||||
"is_verified": false,
|
||||
"created_at": 1703123456,
|
||||
"updated_at": 1703123456
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Update Customer Profile (Protected)
|
||||
|
||||
```bash
|
||||
curl -X PUT http://localhost:8081/api/customers/profile \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Customer-ID: 550e8400-e29b-41d4-a716-446655440000" \
|
||||
-d '{
|
||||
"full_name": "John Smith",
|
||||
"profile_image": "https://example.com/new-avatar.jpg"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Profile updated successfully",
|
||||
"data": {
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"full_name": "John Smith",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/new-avatar.jpg",
|
||||
"status": "active",
|
||||
"is_verified": false,
|
||||
"created_at": 1703123456,
|
||||
"updated_at": 1703123456
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Change Password (Protected)
|
||||
|
||||
```bash
|
||||
curl -X PUT http://localhost:8081/api/customers/change-password \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Customer-ID: 550e8400-e29b-41d4-a716-446655440000" \
|
||||
-d '{
|
||||
"old_password": "securepassword123",
|
||||
"new_password": "newsecurepassword456"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Password changed successfully",
|
||||
"data": null
|
||||
}
|
||||
```
|
||||
|
||||
### 6. Add Device Token (Protected)
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/customers/device-token \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Customer-ID: 550e8400-e29b-41d4-a716-446655440000" \
|
||||
-d '{
|
||||
"device_token": "fcm_token_123456",
|
||||
"device_type": "android"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Device token added successfully",
|
||||
"data": null
|
||||
}
|
||||
```
|
||||
|
||||
### 7. Remove Device Token (Protected)
|
||||
|
||||
```bash
|
||||
curl -X DELETE http://localhost:8081/api/customers/device-token \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Customer-ID: 550e8400-e29b-41d4-a716-446655440000" \
|
||||
-d '{
|
||||
"device_token": "fcm_token_123456"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Device token removed successfully",
|
||||
"data": null
|
||||
}
|
||||
```
|
||||
|
||||
### 8. Logout (Protected)
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/customers/logout \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Customer-ID: 550e8400-e29b-41d4-a716-446655440000" \
|
||||
-d '{
|
||||
"device_token": "fcm_token_123456"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Logged out successfully",
|
||||
"data": null
|
||||
}
|
||||
```
|
||||
|
||||
## Admin Management Examples
|
||||
|
||||
### 9. List All Customers (Admin Only)
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:8081/api/admin/customers?limit=10&offset=0&search=john&status=active" \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Customers retrieved successfully",
|
||||
"data": [
|
||||
{
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"full_name": "John Smith",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/new-avatar.jpg",
|
||||
"status": "active",
|
||||
"is_verified": false,
|
||||
"created_at": 1703123456,
|
||||
"updated_at": 1703123456
|
||||
}
|
||||
],
|
||||
"meta": {
|
||||
"total": 1,
|
||||
"limit": 10,
|
||||
"offset": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 10. Get Customer by ID (Admin Only)
|
||||
|
||||
```bash
|
||||
curl -X GET http://localhost:8081/api/admin/customers/550e8400-e29b-41d4-a716-446655440000 \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Customer retrieved successfully",
|
||||
"data": {
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"full_name": "John Smith",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"national_id": "123456789",
|
||||
"gender": "male",
|
||||
"birthdate": 631152000,
|
||||
"profile_image": "https://example.com/new-avatar.jpg",
|
||||
"status": "active",
|
||||
"is_verified": false,
|
||||
"created_at": 1703123456,
|
||||
"updated_at": 1703123456
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 11. Update Customer Status (Admin Only)
|
||||
|
||||
```bash
|
||||
curl -X PUT http://localhost:8081/api/admin/customers/550e8400-e29b-41d4-a716-446655440000/status \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"status": "suspended"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Customer status updated successfully",
|
||||
"data": null
|
||||
}
|
||||
```
|
||||
|
||||
### 12. Get All Device Tokens (Admin Only)
|
||||
|
||||
```bash
|
||||
curl -X GET http://localhost:8081/api/admin/customers/device-tokens \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Device tokens retrieved successfully",
|
||||
"data": [
|
||||
{
|
||||
"token": "fcm_token_123456",
|
||||
"device_type": "android",
|
||||
"customer_id": "550e8400-e29b-41d4-a716-446655440000"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Error Examples
|
||||
|
||||
### 13. Invalid Email Format
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/admin/customers/register \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"full_name": "John Doe",
|
||||
"username": "johndoe",
|
||||
"email": "invalid-email",
|
||||
"mobile": "+1234567890",
|
||||
"password": "securepassword123"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": false,
|
||||
"message": "Validation failed",
|
||||
"error": "Email: invalid-email does not validate as email"
|
||||
}
|
||||
```
|
||||
|
||||
### 14. Duplicate Email
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/admin/customers/register \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"full_name": "Jane Doe",
|
||||
"username": "janedoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567891",
|
||||
"password": "securepassword123"
|
||||
}'
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": false,
|
||||
"message": "email already exists",
|
||||
"error": "email already exists"
|
||||
}
|
||||
```
|
||||
|
||||
### 15. Invalid Authentication
|
||||
|
||||
```bash
|
||||
curl -X GET http://localhost:8081/api/customers/profile
|
||||
```
|
||||
|
||||
**Expected Response**:
|
||||
```json
|
||||
{
|
||||
"success": false,
|
||||
"message": "Invalid authentication",
|
||||
"error": "Missing customer ID"
|
||||
}
|
||||
```
|
||||
|
||||
## Testing Script
|
||||
|
||||
You can use the following script to test all endpoints:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
BASE_URL="http://localhost:8081"
|
||||
|
||||
echo "Testing Tender Management API..."
|
||||
|
||||
# Test health endpoint
|
||||
echo "1. Testing health endpoint..."
|
||||
curl -s "$BASE_URL/health" | jq .
|
||||
|
||||
# Register a customer
|
||||
echo "2. Registering a customer..."
|
||||
CUSTOMER_RESPONSE=$(curl -s -X POST "$BASE_URL/api/admin/customers/register" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"full_name": "Test User",
|
||||
"username": "testuser",
|
||||
"email": "test@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"password": "password123"
|
||||
}')
|
||||
|
||||
echo "$CUSTOMER_RESPONSE" | jq .
|
||||
|
||||
# Extract customer ID
|
||||
CUSTOMER_ID=$(echo "$CUSTOMER_RESPONSE" | jq -r '.data.id')
|
||||
|
||||
if [ "$CUSTOMER_ID" != "null" ]; then
|
||||
echo "Customer ID: $CUSTOMER_ID"
|
||||
|
||||
# Test login
|
||||
echo "3. Testing login..."
|
||||
curl -s -X POST "$BASE_URL/api/customers/login" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"email_or_mobile": "test@example.com",
|
||||
"password": "password123"
|
||||
}' | jq .
|
||||
|
||||
# Test get profile
|
||||
echo "4. Testing get profile..."
|
||||
curl -s -X GET "$BASE_URL/api/customers/profile" \
|
||||
-H "X-Customer-ID: $CUSTOMER_ID" | jq .
|
||||
|
||||
# Test list customers (admin)
|
||||
echo "5. Testing list customers..."
|
||||
curl -s -X GET "$BASE_URL/api/admin/customers" | jq .
|
||||
fi
|
||||
|
||||
echo "Testing completed!"
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
1. **Authentication**: Currently using a simple header-based authentication (`X-Customer-ID`). In production, this should be replaced with proper JWT token validation.
|
||||
|
||||
2. **Timestamps**: All timestamps are Unix timestamps (int64) for consistency.
|
||||
|
||||
3. **Validation**: All requests are validated using govalidator with custom validation rules.
|
||||
|
||||
4. **Error Handling**: All errors return consistent JSON responses with appropriate HTTP status codes.
|
||||
|
||||
5. **CORS**: The server is configured to allow all origins for development. Configure properly for production.
|
||||
@@ -1,276 +0,0 @@
|
||||
# Implementation Summary: HTTP Server and Dependency Injection
|
||||
|
||||
## ✅ Completed Implementation
|
||||
|
||||
### 1. HTTP Server Initialization
|
||||
|
||||
**File**: `cmd/web/main.go`
|
||||
- ✅ Initialized Echo v4 HTTP server
|
||||
- ✅ Configured server with proper middleware stack
|
||||
- ✅ Added health check endpoint (`/health`)
|
||||
- ✅ Implemented structured logging for all requests
|
||||
- ✅ Added CORS configuration for cross-origin requests
|
||||
- ✅ Configured server to listen on configured host and port
|
||||
|
||||
### 2. Dependency Injection Chain
|
||||
|
||||
**Complete DI Chain Implemented**:
|
||||
```
|
||||
MongoDB Connection Manager → Repositories → Services → Handlers → HTTP Server
|
||||
```
|
||||
|
||||
**Components**:
|
||||
- ✅ **MongoDB Connection Manager** (`pkg/mongo/connection.go`)
|
||||
- ✅ **Customer Repository** (`internal/customer/repository.go`)
|
||||
- ✅ **Customer Service** (`internal/customer/service.go`)
|
||||
- ✅ **Customer Handler** (`internal/customer/handler.go`)
|
||||
- ✅ **HTTP Server** (`cmd/web/main.go`)
|
||||
|
||||
### 3. Middleware Stack
|
||||
|
||||
**Implemented Middleware**:
|
||||
1. ✅ **Recover** - Panic recovery
|
||||
2. ✅ **RequestID** - Unique request identification
|
||||
3. ✅ **Logger** - Request logging
|
||||
4. ✅ **CORS** - Cross-origin resource sharing
|
||||
5. ✅ **Custom Logging** - Structured request logging with timing
|
||||
|
||||
### 4. API Endpoints
|
||||
|
||||
**Customer Endpoints**:
|
||||
- ✅ `POST /api/customers/login` - Customer login
|
||||
- ✅ `POST /api/customers/refresh-token` - Token refresh
|
||||
- ✅ `GET /api/customers/profile` - Get profile (protected)
|
||||
- ✅ `PUT /api/customers/profile` - Update profile (protected)
|
||||
- ✅ `PUT /api/customers/change-password` - Change password (protected)
|
||||
- ✅ `POST /api/customers/device-token` - Add device token (protected)
|
||||
- ✅ `DELETE /api/customers/device-token` - Remove device token (protected)
|
||||
- ✅ `POST /api/customers/logout` - Logout (protected)
|
||||
|
||||
**Admin Endpoints**:
|
||||
- ✅ `POST /api/admin/customers/register` - Register customer (admin)
|
||||
- ✅ `GET /api/admin/customers` - List customers (admin)
|
||||
- ✅ `GET /api/admin/customers/:id` - Get customer by ID (admin)
|
||||
- ✅ `PUT /api/admin/customers/:id/status` - Update customer status (admin)
|
||||
- ✅ `GET /api/admin/customers/device-tokens` - Get all device tokens (admin)
|
||||
|
||||
**System Endpoints**:
|
||||
- ✅ `GET /health` - Server health status
|
||||
|
||||
### 5. Configuration Management
|
||||
|
||||
**File**: `cmd/web/config.yaml`
|
||||
- ✅ Server configuration (host, port, timeouts)
|
||||
- ✅ Database configuration (MongoDB URI, pool settings)
|
||||
- ✅ Logging configuration (level, format, file rotation)
|
||||
- ✅ Auth configuration (JWT settings)
|
||||
- ✅ CORS configuration
|
||||
|
||||
### 6. Error Handling
|
||||
|
||||
**Implemented**:
|
||||
- ✅ Consistent JSON response format
|
||||
- ✅ Proper HTTP status codes
|
||||
- ✅ Validation error handling
|
||||
- ✅ Structured error logging
|
||||
- ✅ Graceful error recovery
|
||||
|
||||
### 7. Logging System
|
||||
|
||||
**Features**:
|
||||
- ✅ Structured logging with fields
|
||||
- ✅ Request/response logging with timing
|
||||
- ✅ Error logging with context
|
||||
- ✅ File rotation based on size and age
|
||||
- ✅ Configurable log levels
|
||||
|
||||
### 8. Build and Deployment
|
||||
|
||||
**Files Created**:
|
||||
- ✅ `Makefile` - Build and run commands
|
||||
- ✅ `test_server.sh` - Test script
|
||||
- ✅ `HTTP_SERVER_SETUP.md` - Comprehensive documentation
|
||||
- ✅ `API_EXAMPLES.md` - API usage examples
|
||||
|
||||
## 🏗️ Architecture Compliance
|
||||
|
||||
### Clean Architecture Principles
|
||||
- ✅ **Separation of Concerns** - Clear layer separation
|
||||
- ✅ **Dependency Inversion** - Depend on interfaces, not implementations
|
||||
- ✅ **Single Responsibility** - Each component has a single purpose
|
||||
- ✅ **Open/Closed Principle** - Easy to extend without modification
|
||||
|
||||
### Domain-Driven Design
|
||||
- ✅ **Domain Entities** - Customer entity with business rules
|
||||
- ✅ **Aggregates** - Customer as aggregate root
|
||||
- ✅ **Repositories** - Data access abstraction
|
||||
- ✅ **Services** - Business logic encapsulation
|
||||
- ✅ **Value Objects** - DeviceToken, Gender, etc.
|
||||
|
||||
### Go Best Practices
|
||||
- ✅ **Package Structure** - Flat domain structure
|
||||
- ✅ **Error Handling** - Explicit error handling
|
||||
- ✅ **Interface Design** - Repository and service interfaces
|
||||
- ✅ **Configuration** - Environment-based configuration
|
||||
- ✅ **Logging** - Structured logging with context
|
||||
|
||||
## 🔧 Technical Implementation
|
||||
|
||||
### Database Layer
|
||||
- ✅ **MongoDB Connection Manager** - Connection pooling and management
|
||||
- ✅ **Repository Pattern** - Data access abstraction
|
||||
- ✅ **Index Management** - Automatic index creation
|
||||
- ✅ **Transaction Support** - Proper transaction handling
|
||||
|
||||
### Business Logic Layer
|
||||
- ✅ **Service Layer** - Business logic encapsulation
|
||||
- ✅ **Validation** - Input validation with govalidator
|
||||
- ✅ **Password Hashing** - bcrypt for secure password storage
|
||||
- ✅ **Token Generation** - Secure token generation for authentication
|
||||
|
||||
### Presentation Layer
|
||||
- ✅ **HTTP Handlers** - Request/response handling
|
||||
- ✅ **Middleware** - Cross-cutting concerns
|
||||
- ✅ **CORS** - Cross-origin resource sharing
|
||||
- ✅ **Authentication** - Basic authentication structure
|
||||
|
||||
## 📊 Performance Features
|
||||
|
||||
### Optimizations
|
||||
- ✅ **Connection Pooling** - MongoDB connection pooling
|
||||
- ✅ **Request Logging** - Performance monitoring
|
||||
- ✅ **Error Recovery** - Graceful error handling
|
||||
- ✅ **Resource Management** - Proper cleanup and resource management
|
||||
|
||||
### Monitoring
|
||||
- ✅ **Health Check** - Server health monitoring
|
||||
- ✅ **Request Metrics** - Request timing and status
|
||||
- ✅ **Error Tracking** - Structured error logging
|
||||
- ✅ **Performance Logging** - Request duration tracking
|
||||
|
||||
## 🔐 Security Features
|
||||
|
||||
### Implemented
|
||||
- ✅ **Input Validation** - Comprehensive request validation
|
||||
- ✅ **Password Security** - bcrypt password hashing
|
||||
- ✅ **CORS Configuration** - Cross-origin request handling
|
||||
- ✅ **Error Sanitization** - No sensitive data exposure
|
||||
|
||||
### Planned (TODO)
|
||||
- 🔄 **JWT Authentication** - Token-based authentication
|
||||
- 🔄 **Rate Limiting** - Request rate limiting
|
||||
- 🔄 **HTTPS** - SSL/TLS encryption
|
||||
- 🔄 **Input Sanitization** - XSS protection
|
||||
|
||||
## 🧪 Testing and Quality
|
||||
|
||||
### Build System
|
||||
- ✅ **Go Modules** - Proper dependency management
|
||||
- ✅ **Makefile** - Build automation
|
||||
- ✅ **Test Scripts** - Automated testing
|
||||
- ✅ **Documentation** - Comprehensive documentation
|
||||
|
||||
### Code Quality
|
||||
- ✅ **Error Handling** - Comprehensive error handling
|
||||
- ✅ **Logging** - Structured logging throughout
|
||||
- ✅ **Validation** - Input validation at all layers
|
||||
- ✅ **Documentation** - Clear code documentation
|
||||
|
||||
## 🚀 Deployment Ready
|
||||
|
||||
### Prerequisites
|
||||
- ✅ **MongoDB** - Database server
|
||||
- ✅ **Go 1.23+** - Runtime environment
|
||||
- ✅ **Configuration** - Environment configuration
|
||||
|
||||
### Build Commands
|
||||
```bash
|
||||
# Build the server
|
||||
make build
|
||||
|
||||
# Run the server
|
||||
make run
|
||||
|
||||
# Run tests
|
||||
make test
|
||||
|
||||
# Clean build artifacts
|
||||
make clean
|
||||
```
|
||||
|
||||
### Docker Support
|
||||
- ✅ **Dockerfile** - Container configuration
|
||||
- ✅ **Docker Compose** - Multi-service deployment
|
||||
- ✅ **Build Commands** - Docker build automation
|
||||
|
||||
## 📈 Scalability Considerations
|
||||
|
||||
### Architecture Benefits
|
||||
- ✅ **Modular Design** - Easy to add new domains
|
||||
- ✅ **Interface-Based** - Easy to swap implementations
|
||||
- ✅ **Stateless Design** - Horizontal scaling ready
|
||||
- ✅ **Connection Pooling** - Database connection optimization
|
||||
|
||||
### Future Enhancements
|
||||
- 🔄 **Caching Layer** - Redis integration
|
||||
- 🔄 **Message Queue** - RabbitMQ integration
|
||||
- 🔄 **Search Engine** - Elasticsearch integration
|
||||
- 🔄 **Monitoring** - Prometheus metrics
|
||||
|
||||
## 🎯 Success Metrics
|
||||
|
||||
### Functional Requirements
|
||||
- ✅ **HTTP Server** - Fully functional HTTP server
|
||||
- ✅ **Dependency Injection** - Complete DI chain implemented
|
||||
- ✅ **API Endpoints** - All customer management endpoints
|
||||
- ✅ **Database Integration** - MongoDB integration complete
|
||||
- ✅ **Error Handling** - Comprehensive error handling
|
||||
- ✅ **Logging** - Structured logging system
|
||||
|
||||
### Non-Functional Requirements
|
||||
- ✅ **Performance** - Optimized for performance
|
||||
- ✅ **Security** - Basic security measures implemented
|
||||
- ✅ **Maintainability** - Clean, well-documented code
|
||||
- ✅ **Scalability** - Architecture supports scaling
|
||||
- ✅ **Testability** - Easy to test and validate
|
||||
|
||||
## 🔄 Next Steps
|
||||
|
||||
### Immediate Tasks
|
||||
1. **Authentication** - Implement JWT token validation
|
||||
2. **Testing** - Add comprehensive unit and integration tests
|
||||
3. **Documentation** - Add API documentation (Swagger)
|
||||
4. **Monitoring** - Add metrics and monitoring
|
||||
|
||||
### Future Enhancements
|
||||
1. **Additional Domains** - Add tender, company, bid domains
|
||||
2. **Advanced Features** - File upload, notifications, search
|
||||
3. **Production Ready** - SSL, rate limiting, monitoring
|
||||
4. **Microservices** - Split into microservices if needed
|
||||
|
||||
## 📝 Documentation
|
||||
|
||||
### Created Files
|
||||
- ✅ `HTTP_SERVER_SETUP.md` - Server setup and configuration
|
||||
- ✅ `API_EXAMPLES.md` - API usage examples
|
||||
- ✅ `IMPLEMENTATION_SUMMARY.md` - This summary
|
||||
- ✅ `test_server.sh` - Test script
|
||||
- ✅ Updated `Makefile` - Build automation
|
||||
|
||||
### Code Documentation
|
||||
- ✅ **Inline Comments** - Clear code documentation
|
||||
- ✅ **Function Documentation** - Go doc comments
|
||||
- ✅ **Architecture Documentation** - System design docs
|
||||
- ✅ **API Documentation** - Endpoint documentation
|
||||
|
||||
## 🎉 Conclusion
|
||||
|
||||
The HTTP server has been successfully initialized with proper dependency injection following Clean Architecture principles. The implementation includes:
|
||||
|
||||
- **Complete DI Chain**: MongoDB → Repositories → Services → Handlers → HTTP Server
|
||||
- **Full API Coverage**: All customer management endpoints implemented
|
||||
- **Production Ready**: Proper error handling, logging, and configuration
|
||||
- **Scalable Architecture**: Easy to extend with new domains and features
|
||||
- **Comprehensive Documentation**: Complete setup and usage documentation
|
||||
|
||||
The server is ready for development and can be easily extended with additional domains and features as needed.
|
||||
@@ -1,301 +0,0 @@
|
||||
# HTTP Server Setup and Dependency Injection
|
||||
|
||||
## Overview
|
||||
|
||||
The Tender Management API server has been successfully initialized with proper dependency injection following Clean Architecture principles. The server uses Echo v4 as the HTTP framework and implements a complete dependency injection chain.
|
||||
|
||||
## Architecture
|
||||
|
||||
### Dependency Injection Chain
|
||||
|
||||
```
|
||||
MongoDB Connection Manager
|
||||
↓
|
||||
Repositories
|
||||
↓
|
||||
Services
|
||||
↓
|
||||
Handlers
|
||||
↓
|
||||
HTTP Server (Echo)
|
||||
```
|
||||
|
||||
### Components
|
||||
|
||||
1. **MongoDB Connection Manager** (`pkg/mongo/connection.go`)
|
||||
- Manages database connections and pooling
|
||||
- Provides connection to repositories
|
||||
|
||||
2. **Repositories** (`internal/customer/repository.go`)
|
||||
- Data access layer
|
||||
- Implements repository pattern
|
||||
- Handles database operations
|
||||
|
||||
3. **Services** (`internal/customer/service.go`)
|
||||
- Business logic layer
|
||||
- Implements use cases
|
||||
- Depends on repositories
|
||||
|
||||
4. **Handlers** (`internal/customer/handler.go`)
|
||||
- HTTP request/response handling
|
||||
- Input validation
|
||||
- Depends on services
|
||||
|
||||
5. **HTTP Server** (`cmd/web/main.go`)
|
||||
- Echo v4 server with middleware
|
||||
- Route registration
|
||||
- Server lifecycle management
|
||||
|
||||
## Server Features
|
||||
|
||||
### Middleware Stack
|
||||
|
||||
1. **Recover** - Panic recovery
|
||||
2. **RequestID** - Unique request identification
|
||||
3. **Logger** - Request logging
|
||||
4. **CORS** - Cross-origin resource sharing
|
||||
5. **Custom Logging** - Structured request logging
|
||||
|
||||
### Endpoints
|
||||
|
||||
#### Health Check
|
||||
- `GET /health` - Server health status
|
||||
|
||||
#### Customer Endpoints
|
||||
- `POST /api/customers/login` - Customer login
|
||||
- `POST /api/customers/refresh-token` - Token refresh
|
||||
- `GET /api/customers/profile` - Get profile (protected)
|
||||
- `PUT /api/customers/profile` - Update profile (protected)
|
||||
- `PUT /api/customers/change-password` - Change password (protected)
|
||||
- `POST /api/customers/device-token` - Add device token (protected)
|
||||
- `DELETE /api/customers/device-token` - Remove device token (protected)
|
||||
- `POST /api/customers/logout` - Logout (protected)
|
||||
|
||||
#### Admin Endpoints
|
||||
- `POST /api/admin/customers/register` - Register customer (admin)
|
||||
- `GET /api/admin/customers` - List customers (admin)
|
||||
- `GET /api/admin/customers/:id` - Get customer by ID (admin)
|
||||
- `PUT /api/admin/customers/:id/status` - Update customer status (admin)
|
||||
- `GET /api/admin/customers/device-tokens` - Get all device tokens (admin)
|
||||
|
||||
## Configuration
|
||||
|
||||
### Server Configuration (`config.yaml`)
|
||||
|
||||
```yaml
|
||||
server:
|
||||
host: "0.0.0.0"
|
||||
port: 8081
|
||||
timeout: 30s
|
||||
read_timeout: 10s
|
||||
write_timeout: 10s
|
||||
```
|
||||
|
||||
### Database Configuration
|
||||
|
||||
```yaml
|
||||
database:
|
||||
mongodb:
|
||||
uri: "mongodb://localhost:27017"
|
||||
name: "tender_management"
|
||||
timeout: 10s
|
||||
max_pool_size: 100
|
||||
```
|
||||
|
||||
## Running the Server
|
||||
|
||||
### Prerequisites
|
||||
|
||||
1. **MongoDB** - Must be running locally or accessible
|
||||
2. **Go 1.23+** - Required for compilation
|
||||
3. **Configuration** - `config.yaml` must be present
|
||||
|
||||
### Build and Run
|
||||
|
||||
```bash
|
||||
# Build the server
|
||||
go build -o bin/web ./cmd/web
|
||||
|
||||
# Run the server
|
||||
./bin/web
|
||||
```
|
||||
|
||||
### Development
|
||||
|
||||
```bash
|
||||
# Run with hot reload (if using air)
|
||||
air
|
||||
|
||||
# Or run directly
|
||||
go run ./cmd/web
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
||||
### Health Check
|
||||
|
||||
```bash
|
||||
curl http://localhost:8081/health
|
||||
```
|
||||
|
||||
Expected response:
|
||||
```json
|
||||
{
|
||||
"status": "healthy",
|
||||
"time": 1703123456,
|
||||
"version": "1.0.0"
|
||||
}
|
||||
```
|
||||
|
||||
### Customer Registration
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/admin/customers/register \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"full_name": "John Doe",
|
||||
"username": "johndoe",
|
||||
"email": "john@example.com",
|
||||
"mobile": "+1234567890",
|
||||
"password": "securepassword123",
|
||||
"national_id": "123456789",
|
||||
"gender": "male"
|
||||
}'
|
||||
```
|
||||
|
||||
## Logging
|
||||
|
||||
The server implements structured logging with the following features:
|
||||
|
||||
- **Request Logging** - All HTTP requests are logged with timing
|
||||
- **Error Logging** - Errors are logged with context
|
||||
- **Structured Fields** - Logs include relevant metadata
|
||||
- **File Rotation** - Logs are rotated based on size and age
|
||||
|
||||
### Log Configuration
|
||||
|
||||
```yaml
|
||||
logging:
|
||||
level: "info"
|
||||
format: "json"
|
||||
output: "file"
|
||||
file:
|
||||
path: "./logs/app.log"
|
||||
max_size: 100
|
||||
max_backups: 5
|
||||
max_age: 30
|
||||
compress: true
|
||||
```
|
||||
|
||||
## Security Features
|
||||
|
||||
### CORS Configuration
|
||||
|
||||
```go
|
||||
middleware.CORSWithConfig(middleware.CORSConfig{
|
||||
AllowOrigins: []string{"*"}, // Configure for production
|
||||
AllowMethods: []string{http.MethodGet, http.MethodPost, http.MethodPut, http.MethodDelete, http.MethodOptions},
|
||||
AllowHeaders: []string{echo.HeaderOrigin, echo.HeaderContentType, echo.HeaderAccept, echo.HeaderAuthorization},
|
||||
})
|
||||
```
|
||||
|
||||
### Authentication (TODO)
|
||||
|
||||
- JWT token validation
|
||||
- Role-based access control
|
||||
- Token refresh mechanism
|
||||
|
||||
## Error Handling
|
||||
|
||||
### HTTP Status Codes
|
||||
|
||||
- `200` - Success
|
||||
- `201` - Created
|
||||
- `400` - Bad Request
|
||||
- `401` - Unauthorized
|
||||
- `404` - Not Found
|
||||
- `409` - Conflict
|
||||
- `422` - Validation Error
|
||||
- `500` - Internal Server Error
|
||||
|
||||
### Response Format
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Operation successful",
|
||||
"data": {},
|
||||
"meta": {}
|
||||
}
|
||||
```
|
||||
|
||||
## Monitoring
|
||||
|
||||
### Health Check
|
||||
|
||||
The `/health` endpoint provides basic server status:
|
||||
|
||||
- Server status
|
||||
- Current timestamp
|
||||
- Version information
|
||||
|
||||
### Request Metrics
|
||||
|
||||
Each request is logged with:
|
||||
|
||||
- HTTP method
|
||||
- Request path
|
||||
- Response status
|
||||
- Processing duration
|
||||
- User agent
|
||||
- Remote IP
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
1. **Authentication Middleware** - Implement JWT validation
|
||||
2. **Rate Limiting** - Add request rate limiting
|
||||
3. **Metrics** - Add Prometheus metrics
|
||||
4. **Tracing** - Add distributed tracing
|
||||
5. **API Documentation** - Add Swagger/OpenAPI docs
|
||||
6. **Testing** - Add comprehensive test suite
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **MongoDB Connection Failed**
|
||||
- Ensure MongoDB is running
|
||||
- Check connection URI in config
|
||||
- Verify network connectivity
|
||||
|
||||
2. **Port Already in Use**
|
||||
- Change port in config.yaml
|
||||
- Kill existing process using the port
|
||||
|
||||
3. **Permission Denied**
|
||||
- Ensure write permissions for log directory
|
||||
- Check file permissions
|
||||
|
||||
### Debug Mode
|
||||
|
||||
To enable debug logging, change the log level in config.yaml:
|
||||
|
||||
```yaml
|
||||
logging:
|
||||
level: "debug"
|
||||
```
|
||||
|
||||
## Dependencies
|
||||
|
||||
### Core Dependencies
|
||||
|
||||
- `github.com/labstack/echo/v4` - HTTP framework
|
||||
- `go.mongodb.org/mongo-driver` - MongoDB driver
|
||||
- `github.com/google/uuid` - UUID generation
|
||||
- `golang.org/x/crypto/bcrypt` - Password hashing
|
||||
- `github.com/asaskevich/govalidator` - Input validation
|
||||
|
||||
### Development Dependencies
|
||||
|
||||
- `github.com/stretchr/testify` - Testing framework
|
||||
- `go.uber.org/zap` - Logging framework
|
||||
@@ -1,313 +0,0 @@
|
||||
# Swagger API Documentation Setup
|
||||
|
||||
This document explains how to use and maintain the Swagger API documentation for the Tender Management Backend.
|
||||
|
||||
## 📚 Overview
|
||||
|
||||
The API documentation is generated using [Swag](https://github.com/swaggo/swag) and served using [echo-swagger](https://github.com/swaggo/echo-swagger). The documentation provides an interactive interface to explore and test all API endpoints.
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
### 1. Generate Documentation
|
||||
|
||||
```bash
|
||||
# Generate Swagger documentation
|
||||
make docs
|
||||
|
||||
# Or manually
|
||||
swag init -g cmd/web/main.go -o cmd/web/docs
|
||||
```
|
||||
|
||||
### 2. Start Server with Documentation
|
||||
|
||||
```bash
|
||||
# Build and run with documentation
|
||||
make run-docs
|
||||
|
||||
# Or manually
|
||||
make build
|
||||
./bin/web
|
||||
```
|
||||
|
||||
### 3. Access Documentation
|
||||
|
||||
Open your browser and navigate to:
|
||||
- **Swagger UI**: http://localhost:8081/swagger/index.html
|
||||
- **Health Check**: http://localhost:8081/health
|
||||
|
||||
## 📋 Available Endpoints
|
||||
|
||||
### 🔐 Authentication
|
||||
- `POST /api/customers/login` - Customer login
|
||||
- `POST /api/customers/refresh-token` - Refresh access token
|
||||
|
||||
### 👤 Customer Profile (Protected)
|
||||
- `GET /api/customers/profile` - Get customer profile
|
||||
- `PUT /api/customers/profile` - Update customer profile
|
||||
- `PUT /api/customers/change-password` - Change password
|
||||
|
||||
### 📱 Device Management (Protected)
|
||||
- `POST /api/customers/device-token` - Add device token
|
||||
- `DELETE /api/customers/device-token` - Remove device token
|
||||
|
||||
### 👥 Admin Operations (Admin Protected)
|
||||
- `POST /api/admin/customers/register` - Register new customer
|
||||
- `GET /api/admin/customers` - List customers
|
||||
- `GET /api/admin/customers/{id}` - Get customer by ID
|
||||
- `PUT /api/admin/customers/{id}/status` - Update customer status
|
||||
|
||||
## 🛠️ Development
|
||||
|
||||
### Adding New Endpoints
|
||||
|
||||
1. **Add Swagger Annotations** to your handler functions:
|
||||
|
||||
```go
|
||||
// @Summary Endpoint summary
|
||||
// @Description Detailed description
|
||||
// @Tags tag-name
|
||||
// @Accept json
|
||||
// @Produce json
|
||||
// @Security BearerAuth
|
||||
// @Param param-name param-type param-required "param description"
|
||||
// @Success 200 {object} response.APIResponse{data=YourResponseType} "Success description"
|
||||
// @Failure 400 {object} response.APIResponse "Error description"
|
||||
// @Router /api/endpoint [method]
|
||||
func (h *Handler) YourHandler(c echo.Context) error {
|
||||
// Your handler implementation
|
||||
}
|
||||
```
|
||||
|
||||
2. **Regenerate Documentation**:
|
||||
|
||||
```bash
|
||||
make docs
|
||||
```
|
||||
|
||||
### Swagger Annotation Examples
|
||||
|
||||
#### Basic GET Endpoint
|
||||
```go
|
||||
// @Summary Get resource
|
||||
// @Description Get a resource by ID
|
||||
// @Tags resources
|
||||
// @Accept json
|
||||
// @Produce json
|
||||
// @Param id path string true "Resource ID"
|
||||
// @Success 200 {object} response.APIResponse{data=ResourceResponse}
|
||||
// @Failure 404 {object} response.APIResponse
|
||||
// @Router /api/resources/{id} [get]
|
||||
```
|
||||
|
||||
#### POST with Request Body
|
||||
```go
|
||||
// @Summary Create resource
|
||||
// @Description Create a new resource
|
||||
// @Tags resources
|
||||
// @Accept json
|
||||
// @Produce json
|
||||
// @Param resource body CreateResourceForm true "Resource data"
|
||||
// @Success 201 {object} response.APIResponse{data=ResourceResponse}
|
||||
// @Failure 400 {object} response.APIResponse
|
||||
// @Router /api/resources [post]
|
||||
```
|
||||
|
||||
#### Protected Endpoint
|
||||
```go
|
||||
// @Summary Protected endpoint
|
||||
// @Description This endpoint requires authentication
|
||||
// @Tags resources
|
||||
// @Accept json
|
||||
// @Produce json
|
||||
// @Security BearerAuth
|
||||
// @Success 200 {object} response.APIResponse
|
||||
// @Failure 401 {object} response.APIResponse
|
||||
// @Router /api/protected [get]
|
||||
```
|
||||
|
||||
## 📁 File Structure
|
||||
|
||||
```
|
||||
cmd/web/
|
||||
├── main.go # Main application entry point
|
||||
├── bootstrap.go # Server initialization
|
||||
└── docs/ # Generated Swagger documentation
|
||||
├── docs.go # Generated docs
|
||||
├── swagger.json # OpenAPI specification
|
||||
└── swagger.yaml # OpenAPI specification (YAML)
|
||||
|
||||
internal/customer/
|
||||
├── handler.go # HTTP handlers with Swagger annotations
|
||||
├── form.go # Request/response forms
|
||||
└── ...
|
||||
|
||||
pkg/response/
|
||||
└── response.go # Standard API response types
|
||||
```
|
||||
|
||||
## 🔧 Configuration
|
||||
|
||||
### Swagger Configuration
|
||||
|
||||
The main Swagger configuration is in `cmd/web/docs.go`:
|
||||
|
||||
```go
|
||||
// @title Tender Management API
|
||||
// @version 1.0.0
|
||||
// @description This is the API documentation for the Tender Management System.
|
||||
// @host localhost:8081
|
||||
// @BasePath /api/v1
|
||||
// @securityDefinitions.apikey BearerAuth
|
||||
// @in header
|
||||
// @name Authorization
|
||||
```
|
||||
|
||||
### Server Configuration
|
||||
|
||||
The Swagger endpoint is registered in `cmd/web/bootstrap.go`:
|
||||
|
||||
```go
|
||||
// Add Swagger documentation endpoint
|
||||
e.GET("/swagger/*", echoSwagger.WrapHandler)
|
||||
```
|
||||
|
||||
## 🧪 Testing
|
||||
|
||||
### Using the Test Script
|
||||
|
||||
```bash
|
||||
# Run the test script
|
||||
./test_swagger.sh
|
||||
```
|
||||
|
||||
This script will:
|
||||
1. Build the application
|
||||
2. Start the server
|
||||
3. Display all available endpoints
|
||||
4. Provide access URLs
|
||||
|
||||
### Manual Testing
|
||||
|
||||
1. **Start the server**:
|
||||
```bash
|
||||
make run-docs
|
||||
```
|
||||
|
||||
2. **Access Swagger UI**:
|
||||
- Open http://localhost:8081/swagger/index.html
|
||||
- Explore and test endpoints interactively
|
||||
|
||||
3. **Test Health Check**:
|
||||
```bash
|
||||
curl http://localhost:8081/health
|
||||
```
|
||||
|
||||
## 📝 Response Types
|
||||
|
||||
### Standard Response Structure
|
||||
|
||||
All API responses follow this structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"message": "Operation successful",
|
||||
"data": {
|
||||
// Response data
|
||||
},
|
||||
"meta": {
|
||||
// Pagination metadata (if applicable)
|
||||
},
|
||||
"error": {
|
||||
// Error details (if applicable)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Error Response
|
||||
|
||||
```json
|
||||
{
|
||||
"success": false,
|
||||
"message": "Error message",
|
||||
"error": {
|
||||
"code": "ERROR_CODE",
|
||||
"message": "Detailed error message",
|
||||
"details": "Additional details"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🔐 Authentication
|
||||
|
||||
### Bearer Token Authentication
|
||||
|
||||
Most endpoints require Bearer token authentication:
|
||||
|
||||
1. **Login** to get access token:
|
||||
```bash
|
||||
curl -X POST http://localhost:8081/api/customers/login \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"email": "user@example.com", "password": "password"}'
|
||||
```
|
||||
|
||||
2. **Use the token** in subsequent requests:
|
||||
```bash
|
||||
curl -X GET http://localhost:8081/api/customers/profile \
|
||||
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
|
||||
```
|
||||
|
||||
## 🚨 Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **Documentation not updating**:
|
||||
```bash
|
||||
make clean
|
||||
make docs
|
||||
make build
|
||||
```
|
||||
|
||||
2. **Swagger annotations not recognized**:
|
||||
- Ensure annotations are directly above the function
|
||||
- Check for syntax errors in annotations
|
||||
- Verify import paths are correct
|
||||
|
||||
3. **Server won't start**:
|
||||
- Check if port 8081 is available
|
||||
- Verify MongoDB connection
|
||||
- Check configuration files
|
||||
|
||||
### Debug Commands
|
||||
|
||||
```bash
|
||||
# Check if swag is installed
|
||||
swag --version
|
||||
|
||||
# Generate docs with verbose output
|
||||
swag init -g cmd/web/main.go -o cmd/web/docs --parseDependency
|
||||
|
||||
# Check generated files
|
||||
ls -la cmd/web/docs/
|
||||
```
|
||||
|
||||
## 📚 Additional Resources
|
||||
|
||||
- [Swag Documentation](https://github.com/swaggo/swag)
|
||||
- [Echo Swagger](https://github.com/swaggo/echo-swagger)
|
||||
- [OpenAPI Specification](https://swagger.io/specification/)
|
||||
- [Swagger UI](https://swagger.io/tools/swagger-ui/)
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
When adding new endpoints:
|
||||
|
||||
1. Add comprehensive Swagger annotations
|
||||
2. Include all possible response codes
|
||||
3. Provide meaningful examples
|
||||
4. Test the documentation in Swagger UI
|
||||
5. Update this documentation if needed
|
||||
|
||||
## 📄 License
|
||||
|
||||
This documentation is part of the Tender Management Backend project.
|
||||
@@ -1,177 +0,0 @@
|
||||
# ✅ Swagger API Documentation Successfully Implemented
|
||||
|
||||
## 🎉 Implementation Complete
|
||||
|
||||
The Swagger API documentation has been successfully implemented for the Tender Management Backend with comprehensive handler function comments.
|
||||
|
||||
## 📋 What Was Accomplished
|
||||
|
||||
### 1. ✅ Dependencies Added
|
||||
- `github.com/swaggo/echo-swagger` - Echo Swagger integration
|
||||
- `github.com/swaggo/swag/cmd/swag` - Swagger documentation generator
|
||||
- `github.com/swaggo/files` - Swagger UI files
|
||||
|
||||
### 2. ✅ Swagger Configuration
|
||||
- Added main Swagger annotations to `cmd/web/main.go`
|
||||
- Configured API metadata (title, version, description, contact info)
|
||||
- Set up security definitions for Bearer token authentication
|
||||
- Defined API tags for organization
|
||||
|
||||
### 3. ✅ Handler Function Documentation
|
||||
All customer handler functions now have comprehensive Swagger annotations:
|
||||
|
||||
#### 🔐 Authentication Endpoints
|
||||
- `POST /api/customers/login` - Customer login with credentials
|
||||
- `POST /api/customers/refresh-token` - Refresh access token
|
||||
|
||||
#### 👤 Customer Profile Endpoints (Protected)
|
||||
- `GET /api/customers/profile` - Get customer profile
|
||||
- `PUT /api/customers/profile` - Update customer profile
|
||||
- `PUT /api/customers/change-password` - Change password
|
||||
|
||||
#### 👥 Admin Endpoints (Admin Protected)
|
||||
- `POST /api/admin/customers/register` - Register new customer
|
||||
- `GET /api/admin/customers` - List customers with pagination
|
||||
- `GET /api/admin/customers/{id}` - Get customer by ID
|
||||
|
||||
### 4. ✅ Server Integration
|
||||
- Added Swagger route to HTTP server (`/swagger/*`)
|
||||
- Integrated with Echo framework
|
||||
- Configured proper middleware
|
||||
|
||||
### 5. ✅ Documentation Generation
|
||||
- Generated comprehensive API documentation
|
||||
- Created interactive Swagger UI
|
||||
- Produced OpenAPI specification (JSON/YAML)
|
||||
|
||||
## 🚀 How to Use
|
||||
|
||||
### 1. Start the Server
|
||||
```bash
|
||||
# Build and run with documentation
|
||||
make run-docs
|
||||
|
||||
# Or manually
|
||||
make build
|
||||
./bin/web
|
||||
```
|
||||
|
||||
### 2. Access Documentation
|
||||
- **Swagger UI**: http://localhost:8081/swagger/index.html
|
||||
- **Health Check**: http://localhost:8081/health
|
||||
- **API JSON**: http://localhost:8081/swagger/doc.json
|
||||
|
||||
### 3. Regenerate Documentation
|
||||
```bash
|
||||
# Regenerate after adding new endpoints
|
||||
make docs
|
||||
|
||||
# Or manually
|
||||
swag init -g cmd/web/main.go -o cmd/web/docs
|
||||
```
|
||||
|
||||
## 📊 Current API Endpoints
|
||||
|
||||
### Available in Swagger Documentation:
|
||||
1. `POST /api/customers/login` - Customer authentication
|
||||
2. `POST /api/customers/refresh-token` - Token refresh
|
||||
3. `GET /api/customers/profile` - Get profile (protected)
|
||||
4. `PUT /api/customers/profile` - Update profile (protected)
|
||||
5. `PUT /api/customers/change-password` - Change password (protected)
|
||||
6. `POST /api/admin/customers/register` - Register customer (admin)
|
||||
7. `GET /api/admin/customers` - List customers (admin)
|
||||
8. `GET /api/admin/customers/{id}` - Get customer by ID (admin)
|
||||
|
||||
## 🔧 Technical Details
|
||||
|
||||
### Swagger Annotations Used
|
||||
- `@Summary` - Brief endpoint description
|
||||
- `@Description` - Detailed endpoint description
|
||||
- `@Tags` - API grouping
|
||||
- `@Accept` - Request content type
|
||||
- `@Produce` - Response content type
|
||||
- `@Security` - Authentication requirements
|
||||
- `@Param` - Request parameters
|
||||
- `@Success` - Success responses
|
||||
- `@Failure` - Error responses
|
||||
- `@Router` - Endpoint path and method
|
||||
|
||||
### Response Types Documented
|
||||
- `response.APIResponse` - Standard API response structure
|
||||
- `customer.CustomerResponse` - Customer data response
|
||||
- `customer.AuthResponse` - Authentication response
|
||||
- Error responses for all HTTP status codes
|
||||
|
||||
### Security Implementation
|
||||
- Bearer token authentication
|
||||
- Protected endpoints require valid JWT
|
||||
- Admin endpoints require admin privileges
|
||||
|
||||
## 🧪 Testing Results
|
||||
|
||||
### ✅ Server Status
|
||||
- MongoDB connection: ✅ Working
|
||||
- HTTP server: ✅ Running on port 8081
|
||||
- Swagger UI: ✅ Accessible
|
||||
- Health endpoint: ✅ Responding
|
||||
|
||||
### ✅ Documentation Features
|
||||
- Interactive API testing: ✅ Available
|
||||
- Request/response examples: ✅ Included
|
||||
- Authentication support: ✅ Configured
|
||||
- Error documentation: ✅ Complete
|
||||
|
||||
## 📁 File Structure
|
||||
|
||||
```
|
||||
cmd/web/
|
||||
├── main.go # Main app with Swagger config
|
||||
├── bootstrap.go # Server setup with Swagger route
|
||||
└── docs/ # Generated documentation
|
||||
├── docs.go # Swagger docs
|
||||
├── swagger.json # OpenAPI spec
|
||||
└── swagger.yaml # OpenAPI spec (YAML)
|
||||
|
||||
internal/customer/
|
||||
├── handler.go # HTTP handlers with Swagger annotations
|
||||
├── form.go # Request/response forms
|
||||
└── ...
|
||||
|
||||
pkg/response/
|
||||
└── response.go # Standard API response types
|
||||
```
|
||||
|
||||
## 🎯 Next Steps
|
||||
|
||||
### For Developers
|
||||
1. **Add New Endpoints**: Follow the annotation pattern in `handler.go`
|
||||
2. **Update Documentation**: Run `make docs` after changes
|
||||
3. **Test in Swagger UI**: Use the interactive interface
|
||||
4. **Maintain Examples**: Keep request/response examples current
|
||||
|
||||
### For API Consumers
|
||||
1. **Explore APIs**: Use Swagger UI for interactive testing
|
||||
2. **Authentication**: Use Bearer token for protected endpoints
|
||||
3. **Error Handling**: Check documented error responses
|
||||
4. **Pagination**: Use documented pagination parameters
|
||||
|
||||
## 🏆 Success Metrics
|
||||
|
||||
- ✅ All handler functions documented
|
||||
- ✅ Interactive API testing available
|
||||
- ✅ Authentication properly configured
|
||||
- ✅ Error responses documented
|
||||
- ✅ Request/response examples included
|
||||
- ✅ Server running successfully
|
||||
- ✅ Documentation accessible via web interface
|
||||
|
||||
## 📚 Resources
|
||||
|
||||
- **Swagger UI**: http://localhost:8081/swagger/index.html
|
||||
- **API Documentation**: See `SWAGGER_SETUP.md`
|
||||
- **Test Script**: Use `./test_swagger.sh`
|
||||
- **Makefile**: Use `make docs` and `make run-docs`
|
||||
|
||||
---
|
||||
|
||||
**Status**: ✅ **COMPLETE** - Swagger API documentation successfully implemented with comprehensive handler function comments.
|
||||
Reference in New Issue
Block a user