How sai-shashank-2005/intelligent-intranet-retrieval-system works
1. What this repo is
- A small, monolithic PHP intranet application called IIRS (Intelligent Intranet Retrieval System).
- It combines document/link search for employees with search auditing for security monitoring.
- There is no sign of separate microservices or an external search engine; the app appears to be server-rendered PHP + database.
2. Primary runtime boundary
- The application runs behind a standard PHP-capable web server on an internal network.
- Browser requests hit PHP entry points, which render HTML and query the database.
- The app is designed to be offline/private: all data stays inside the corporate environment.
3. User-facing pages
- index.php is likely the main landing/search page.
- search.php handles search execution and result display.
- logs.php is the security/admin view for reviewing recorded searches.
- These pages are the main navigation points for two user groups: employees and security staff.
4. Shared presentation layer
- components/navbar.php, components/footer.php, and components/search-card.php indicate a reusable server-side UI composition pattern.
- assets/css/style.css and assets/js/script.js provide the shared styling and client-side behavior.
- The UI is likely assembled on the server with small reusable fragments rather than a client-side SPA.
5. Search flow
- A user enters a query in the browser.
- The search request is processed in PHP, likely in search.php, and matched against records stored in the database.
- The README says the search includes basic normalization such as plural handling, so the backend likely adjusts terms like “forms” to “form” before querying.
6. Result model
- Search results are rendered using components/search-card.php, which suggests each result is presented as a card-style item.
- The indexed content appears to be internal company documents, forms, and links, not arbitrary web pages.
- This implies the database acts as the application’s search corpus.
7. Security logging subsystem
- Every search query is logged, including IP address and device-related information according to the README.
- This logging is part of the application’s security value proposition: it supports detection of suspicious reconnaissance patterns.
- logs.php is the boundary for reviewing this telemetry, likely reserved for security staff or admins.
8. Database layer
- db.php is the database connection/configuration boundary used by the PHP pages.
- config.php likely contains app settings or constants shared across the application.
- database/setup.sql initializes the schema, and database/update_1.sql indicates at least one schema/data migration has been applied.
9. Data flow between subsystems
- Browser → PHP page (index.php / search.php) → MySQL database → rendered HTML response.
- Separately, the search request also writes an audit record to the database for later inspection in logs.php.
- This means the same database supports both search retrieval and security observability.
10. Deployment and ops
- deploy.sh suggests a simple server-side deployment workflow.
- The README describes copying the repo to a web root, importing SQL, and updating DB credentials.
- That points to a straightforward internal deployment model: code + schema + config, not containerized or cloud-native infrastructure.
11. Important architectural boundary
- The app is split into three clear concerns:
- Presentation: PHP page templates and shared components
- Search/business logic: query handling, normalization, result formatting
- Persistence/audit: database tables for searchable content and logs
- This separation is modest but clear enough to diagram as a classic server-rendered MVC-like PHP app.
12. What is not present
- No evidence of external APIs, SaaS dependencies, message queues, background workers, or a separate indexing pipeline.
- No sign of front-end framework complexity; the app appears intentionally lightweight and internal.
- The architecture is therefore centered on a single PHP application with a relational database backend.
Main entry points: search.php Search · index.php Home · setup.sql Schema setup · logs.php Logs
Components 15
Presentation
Server-rendered pages and shared UI fragments.
- Home · Landing page and search entry point.
index.php - Navbar · Shared top navigation component.
components/navbar.php - Footer · Shared page footer component.
components/footer.php - Result card · Reusable search result rendering.
components/search-card.php - Styles · Shared application styling.
assests/css/style.css - Script · Client-side behavior for the UI.
assests/js/script.js
Search & audit
Query handling, normalization, and logging flows.
Persistence
Database schema and access layer.
- Config · Shared application constants and settings.
config.php - DB access · Database connection boundary used by pages.
db.php - Schema setup · Initial database tables and seed structure.
database/setup.sql - Update script · Database update and schema evolution script.
database/update_1.sql - Content store · Internal documents, forms, and links indexed for search.
- Audit log · Recorded searches with IP and device metadata.
Other components
- Deploy · Simple internal deployment workflow.
deploy.sh
Connections 25
- Home → Navbar: uses · Main page composes shared navigation.
- Home → Footer: uses · Main page composes shared footer.
- Home → Styles: loads · Landing page uses shared styling.
- Home → Script: loads · Landing page uses client-side behavior.
- Home → Search: submits · Search form routes into query handling.
- Search → DB access: queries · Search execution reads from the database.
- Search → Content store: searches · Matches queries against internal content records.
- Search → Audit log: writes · Audits each search request.
- Search → Result card: renders · Results are presented with reusable cards.
- Search → Navbar: uses · Search page composes shared navigation.
- Search → Footer: uses · Search page composes shared footer.
- Search → Styles: loads · Search page uses shared styling.
- Search → Script: loads · Search page uses client-side behavior.
- Search → Config: reads · Uses application settings and constants.
- Logs → DB access: queries · Log review reads audit records from the database.
- Logs → Audit log: reads · Displays recorded search telemetry.
- Logs → Navbar: uses · Log view composes shared navigation.
- Logs → Footer: uses · Log view composes shared footer.
- DB access → Schema setup: depends on · Connection layer assumes initialized schema.
- Schema setup → Content store: defines · Schema creates the searchable content tables.
- Schema setup → Audit log: defines · Schema creates audit logging tables.
- Update script → Schema setup: evolves · Update script extends the base schema.
- Deploy → DB access: configures · Deployment updates database credentials and wiring.
- Deploy → Schema setup: imports · Deployment includes database setup.
- Deploy → Home: publishes · Deployment places the PHP app into web root.