How carlamndz/inventarioitu works
1. What this repository is
- This repo is a system blueprint + deployment skeleton for an inventory platform called “Ecosistema de Inventario Seguro”.
- The architecture is split into a web application, two separate data stores, LDAP-based authentication, and Kubernetes deployment artifacts.
2. Main user-facing subsystem: app/
- app/ is the Node.js + Express application labeled in the README as inventario-web.
- It acts as the central entry point for users to consult inventory information.
- Architecturally, this is the only application layer exposed on the listed application port: 3000.
3. Data persistence is intentionally split by domain
- The repo uses two databases for two different kinds of data:
- db/sqlserver/ for location and assignment data (ubicacion-db, port 1433).
- db/mongodb/ for hardware/component inventory data (inventario-db, port 27017).
- This is an important boundary: the system is not storing everything in one database; relational and document data are separated by responsibility.
4. Relational data flow: SQL Server
- SQL Server holds the structured inventory metadata: lab location, assigned machines, and related relational entities.
- From the README, this is the data source for where a computer is and who/what it is assigned to.
- If drawing the architecture, place SQL Server on the “inventory location/assignment” path only.
5. Document data flow: MongoDB
- MongoDB stores the hardware details of the computers: components and other semi-structured inventory attributes.
- This suggests the app queries MongoDB for machine internals while querying SQL Server for organizational placement.
- The split indicates a hybrid persistence model rather than a single normalized schema.
6. Authentication boundary: LDAP / Active Directory
- ldap/ represents the OpenLDAP side of the architecture, exposed as ldap-service on port 389.
- The README states authentication is against Active Directory/LDAP, so the web app likely relies on LDAP for login and identity validation.
- In the diagram, LDAP should be shown as an external identity provider / auth subsystem, separate from the business data stores.
7. Kubernetes is the deployment and isolation layer
- k8s/ contains manifests for each subsystem:
- k8s/frontend/
- k8s/sqlserver/
- k8s/mongodb/
- k8s/ldap/
- k8s/network-policies/
- This means the platform is designed to run as multiple isolated Kubernetes workloads, not a monolith.
- network-policies/ is especially relevant: it implies explicit traffic restrictions between components.
8. Security and segmentation are first-class concerns
- The presence of Kubernetes NetworkPolicies plus a separate LDAP service indicates the repo is designed for controlled east-west traffic.
- Likely intent: the frontend can reach only the required databases and LDAP, and the databases should not be publicly reachable.
- For an architecture diagram, show restricted internal service-to-service communication, not an open flat cluster network.
9. Documentation and diagrams live separately
- docs/ is reserved for supporting documentation and diagrams.
- Since the repo itself currently contains mostly placeholders, the repository structure is acting as a project scaffold for the final system design and deployment assets.
10. Current repository state
- The tree shows mostly .gitkeep files, so the repository is currently structural rather than fully populated.
- The architecture should therefore be drawn from the README’s intended design: a frontend + LDAP auth + dual-database backend, all deployed in Kubernetes.
11. End-to-end request path
- The most likely flow is:
- User accesses inventario-web
- The app authenticates against LDAP/Active Directory
- The app reads location/assignment data from SQL Server
- The app reads hardware/component data from MongoDB
- This is the key data flow to emphasize in a diagram.
12. Technology footprint that materially affects architecture
- Runtime/app layer: Node.js + Express
- Datastores: SQL Server and MongoDB
- Identity: OpenLDAP / Active Directory
- Platform: Docker + Kubernetes, with Minikube + Calico mentioned in the README
- Security tooling/networking: GUFW and Kubernetes network policies
13. How to draw the system boundary
- Treat the repository as one logical system with four internal services:
- web app
- SQL Server
- MongoDB
- LDAP
- Surround them with a Kubernetes cluster boundary and show the user entering only through the web app.
- Keep LDAP and both databases as internal dependencies rather than user-facing endpoints.
Main entry points: app inventario-web · README.md README · network-policies Network policies · sqlserver Location DB
Components 12
Runtime services
User-facing app, identity, and the two separated data stores.
- inventario-web · Express application that serves as the central entry point for inventory queries.
app - Location DB · Relational store for location and assignment data.
db/sqlserver - Inventory DB · Document store for hardware and component inventory details.
db/mongodb - LDAP service · Identity subsystem used for authentication and directory lookups.
ldap
Kubernetes deployment
Manifests and network policy scaffolding for isolated workloads.
- Frontend manifests · Kubernetes deployment assets for the web application.
k8s/frontend - SQL manifests · Kubernetes deployment assets for the SQL Server workload.
k8s/sqlserver - Mongo manifests · Kubernetes deployment assets for the MongoDB workload.
k8s/mongodb - LDAP manifests · Kubernetes deployment assets for the LDAP workload.
k8s/ldap - Network policies · Traffic segmentation rules controlling east-west access between workloads.
k8s/network-policies
Reference material
Repository documentation and supporting notes.
Other components
- User · Person accessing the inventory system.
Connections 17
- User → inventario-web: uses · End users reach the system through the web application.
- inventario-web → LDAP service: authenticates · Login and identity validation happen against LDAP/Active Directory.
- inventario-web → Location DB: reads location · The app queries relational inventory placement and assignment data.
- inventario-web → Inventory DB: reads hardware · The app queries document-based component and machine details.
- Frontend manifests → inventario-web: deploys · Kubernetes resources define the web application workload.
- SQL manifests → Location DB: deploys · Kubernetes resources define the SQL Server workload.
- Mongo manifests → Inventory DB: deploys · Kubernetes resources define the MongoDB workload.
- LDAP manifests → LDAP service: deploys · Kubernetes resources define the LDAP workload.
- Network policies → inventario-web: restricts · Network policies constrain access to the application workload.
- Network policies → Location DB: restricts · Network policies constrain access to the SQL Server workload.
- Network policies → Inventory DB: restricts · Network policies constrain access to the MongoDB workload.
- Network policies → LDAP service: restricts · Network policies constrain access to the LDAP workload.
- README → inventario-web: describes · The README defines the intended application architecture.
- README → Location DB: describes · The README documents the relational data boundary.
- README → Inventory DB: describes · The README documents the document-store data boundary.
- README → LDAP service: describes · The README documents the authentication boundary.
- Docs → README: supports · Documentation space complements the main system description.